关键字：多租户、稳定、低成本、解决方案

前言

TiDB 社区最近在成都举办了社区企业行活动，活动中有老师着重提到他们会把数量达 100+ 的相对低负载、低容量的长尾 MySQL，集中到一个统一的 TiDB 集群管理，可以极大减少数据库/集群的数量，从而大大减轻运维压力，释放有限的DBA人力。这个观点和我前段时间在深圳的社区活动中聊到的话题（深圳社区活动https://asktug.com/t/topic/1022494），主题思想不谋而合。

想要基于 TiDB 构建一个稳定且又高效、又不互相干扰、访问互相独立的多租户业务系统，在老的版本里实现起来会比较困难。好的是从 v7.1.0 开始资源管控成为正式功能，缓解不同工作负载间的资源与存储访问干扰，虽有一些待完善的地方，但是也基本上是实现了多租户的功能。

现如今自从新的 LTS v7.5.0发布之后，新版本带来的异常SQL熔断机制、系统任务（自动收集统计信息、BR备份和恢复、Lightning 导入及在线 DDL）自动识别并设置后台运行、DDL支持暂停等功能，使得多租户访问的集群系统有了很好的提升空间。

在这篇文章里，结合之前的思考我将和大家继续深入探讨一下如何结合这些新特性，构建一个更加稳定告警的多租户系统架构。

HTAP架构

TiDB HTAP 可以满足海量数据的增产需求、降低运维的风险成本、与现有的大数据栈无缝缝合，从而实现数据资产价值的实时变现。主要有下面三种适用场景：

• 混合负载场景

  • 在在线实时分析处理的混合负载场景，使用相同的集群入口，TiDB 可以自动根据业务类型选择不同的处理引擎。

• 实时流处理场景

  • 在实时流处理场景时，TiDB 能实时查询写入数据库的数据，同时可兼顾高并发数据服务与 BI 查询。

• 数据中枢场景

  • TiDB 可以汇聚来自异构数据源的数据，作为数据中枢可以无缝连接数据业务层和数据仓库层，满足不同业务的需求。

经典的TiDB集群拓扑

HTAP同时支持在线事务处理和在线实时分析业务，有诸多优点，这里不详细赘述。不过，HTAP架构在业界看来，主要有三个难点：

• 如何保证数据一致性？
• 如何均衡不同类型的业务负载？
• 如何实现资源隔离？

在基于TiDB部署的 HTAP 集群，如下图所示是一个用得最多的、经典的 TiDB 集群系统。

当一个 TiDB 集群集合了原来上百套 MySQL 业务系统的时候，其访问负载很大概率是多种多样的，不同的负载通过负载均衡层 LB 接入 tidb-server，最终访问集群的服务。

对于数据一致性，底层存储层 TiKV 由可靠的 raft 协议保证数据的强一致性，不同的机器节点之间数据保持强一致，可以说在底层能力上，数据强一致性就是 TiDB 天然基因。

对于不同类型的业务负载，在传统的 TiDB 架构中，确实容易出现混合负载相互干扰的风险。但由于 TiDB 是计算层、存储层、调度层是分层设计，使得各个组件层具有很灵活的部署能力，只要在计算层及 LB 层做出调整，就可以很好解决问题。

负载隔离的集群架构

如下图所示，不同的业务负载使用不同的 LB 入口，不同的 LB 入口 后端又接着不同的 tidb-server 节点，很好地实现了计算层的负载隔离。

对于资源使用隔离的问题，在平时的使用当中，大SQL、尤其是分析类型的 AP 业务SQL，往往是影响集群的最大因素，所以在存储层通过引入列式存储引擎 TiFlash ，直接在物理层面隔离 TP 访问和 AP 流量，二者在存储层物理独立，把影响最大的因素独立了出去，很好得保护了在行存上的、对延迟高度敏感的 TP 访问负载。

高可用容灾架构

如果我们的业务系统有跨机房容灾的需求，也可以很轻松就实现架构的升级。把对应的节点按照一定的分配，如下图，管理员是很方便就实现多中心的高可用容灾架构的。如果用得更加深入一些，结合 Placement Rule in SQL 等特性，可以实现同城两中心、冷热归档存储、三地五中心等多种方案。

可以说到这里，我们也已经能够感受到TiDB很强大、又很灵活扩展的架构优化能力了。单纯从技术上看，这也是我支持 TiDB 的最大原因之一，能让你感受到它具有蓬勃的生命力！

但是这套架构并非完美无瑕，由于是多业务访问，底层还是共用相同的 TiKV 存储层，即其 存储层仍然是跨系统共用的，无法有效隔离。

多租户架构及特性提升

在实践应用中我们可以发现，对传统架构多业务共用一个集群的场景，通常会遇到下面的痛点问题：

• 高峰挤兑

  • 当一个业务处于高峰期时，会过多占用集群资源，影响别的业务。

• 低估过剩

  • 当集群中的重要业务处于低谷值时，有较多的剩余资源。

• 异常放大

  • 当集群遇到临时的问题 SQL 引发的性能问题时，很容易导致某一项资源使用紧张，进而影响整个集群，只能粗暴停掉对应的业务 。

官方其实也很早发现了这样的问题，所以在 v7.1.0 的 LTS 稳定版本里，正式发布了资源管控的功能，实现了多租户的功能特性，这在一定程度上极大缓解了这个问题，详情可以看我之前整理的这篇文章《TiDB v7.1.0 跨业务系统多租户解决方案》。

资源管控的基本原理是对集群拥有的资源，包含CPU、磁盘IO 和网络 IO，统一抽象成可计量的单位Request Unit (RU)，再通过用户绑定资源组（RG），对 RG 限流或调整调度优先级实现对租户资源的管控，从而实现多租户的访问资源隔离。利用这些特性，我们可以：

• 实时在线增加/减少业务租户可用资源。根据市场营销活动随时增加可用资源，活动结束就减少配额，非常灵活。
• 实时在线限制租户业务可用配额。对突发故障，对性能异常的业务加以限制，避免干扰其他业务。
• 实时在线取消租户业务配额限制。突发故障问题得以解决，取消临时限制，业务恢复正常运行。
• 多业务共用一个集群，实现资源错峰使用，提高资源使用率，降低集群数量，缩减硬件成本、管理成本。

根据业务运行动态，实时扩大、缩小、取消限额、加限制等资源使用，极大提高集群资源使用率。

虽然支持对用户、会话、SQL语句（Hint）级别的管控，但对线上运行业务来说，有问题出现时直接禁止一个用户的访问，其 管控粒度还是太大了，这往往要停掉一整块业务，几乎不可能。即便是通过 SQL语句（Hint）级别的方式来管控，但由于要改业务代码、涉及发版等流程，也是过于复杂了。

异常 SQL 熔断/加黑

基于这样的考虑和现实诉求，官方在 v7.2.0 版本里推出来资源管控特性 Runaway Queries。 Runaway Queries 是指执行时间或消耗资源超出预期的查询，在运行时间和资源消耗上有显著特征。系统自动识别和管理资源消耗超出预期的查询，降低突发 SQL 性能问题带来的负面影响，保护复杂工作负载下TiDB系统的稳定性，提高集群的可靠性。

基于SQL执行时长来识别并熔断

如下是我们在做 POC 验证的过程示意图。

资源管控特性 Runaway Queries 基于 SQL 的执行时间的管控，我们主要验证了下面 5 个阶段：

• 阶段1：业务正常运行

  • 业务访问正常，其延迟处于较低的水平上，此时并没有异常SQL出现。

• 阶段2：突发异常SQL出现

  • 这个阶段在模拟统计信息过期、执行计划不准或新上大SQl业务时，集群突然出现异常SQL的情况，此时业务访问 QPS 急剧下降了 81%，99.9% 的延迟极大升高 7 倍以上，业务访问被严重影响，这是我们最不愿意看到的情况。如果放在以前，这个时候大概率只能暂时停止对应的业务访问，以保障集群其他业务的正常服务。

• 阶段3：自动识别异常SQL。限制操作：QUERY_LIMIT=(EXEC_ELAPSED='2s', ACTION=KILL)。

  • 引进了 SQL 熔断功能后，就可以不用停止整个业务了。只需要找到对应的问题SQL，针对这一条或这一类 SQL 设置执行超时时间，系统在遇到后就会直接kill掉，不用过多的人工干预。
  • 经过设置后，业务访问的 QPS 和 延迟都有所好转。但由于系统是等SQL执行到超时了才会去干预，所以问题 SQL 给集群带来的负面影响还是在持续着的。

• 阶段4：持续管控异常SQL。限制操作： QUERY_LIMIT=(EXEC_ELAPSED='2s', ACTION=KILL, WATCH=SIMILAR DURATION='5m')。

  • 为了更好地保护业务，还可以设置一段时间的保护期，这段时间内集群会自动收集问题SQL，遇到相同的 SQL 会直接干掉，而不用等待它执行超时，极大改善集群情况，给业务留够修复的时间。
  • 经过设置后，可以看到 QPS 相比平时正常情况只低了 3%，99.9% 的延迟升高了 3%，可以说基本已经恢复了正常水平！

• 阶段5：业务正常运行

  • 问题SQL修复后，业务重新恢复正常运行状态。

从上面的验证效果来看，系统能 自动识别负面SQL并处置 ，极大地保障系统稳定性、安全性。

基于 SQL 来识别并熔断

上面是基于 SQL 执行时间来识别问题 SQL 的，可能执行很久的 SQL 就是正常的，这里存在误伤的情况。基于异常 SQL 的管控（SQL黑名单）就很好地解决这个问题。v7.3.0引入了手动管理异常SQL的功能，通过指定SQL或Digest ，Query Watch快速识别加黑语句，实现异常业务隔离，保障重要在线业务的稳定性。

如下图：

与前面基于时间识别异常 SQL 的场景类似，这里主要是通过Dashboard+slowlog等识别了问题 SQL 后，人工直接介入处理，加黑并熔断SQL的执行：

• 阶段1：业务正常运行

• 阶段2：突发异常SQL出现

• 阶段3：添加SQL黑名单识别

  • 加黑设置QUERY WATCH ADD RESOURCE GROUP default SQL TEXT EXACT|SIMILAR TO 'select * from Order.order_line limit 100000';

• 阶段4：业务正常运行

系统后台任务

对于非 SQL 类型的系统任务管控，v7.4.0 引入后台任务功能实现。后台任务会被TiKV限制资源的使用，尽量避免对其他前台任务的性能影响。支持管控的后台任务类型：

• ddl：对于 Reorg DDL，控制批量数据回写阶段的资源使用。
• stats：对应手动执行或系统自动触发的收集统计信息任务。
• lightning：使用Lightning 执行导入任务，支持物理和逻辑导入模式。
• br：使用 BR 执行数据备份和恢复。目前不支持 PITR。
• background：指定当前会话的任务类型为 background。

下面针对常用的几个系统任务类型，分析后台任务功能开启后的实际运行效果。

DDL后台执行

大表 DDL 是一个非常消耗资源的操作，后台任务可以控制批量数据回写阶段的资源使用。

• ALTER RESOURCE GROUP default BACKGROUND=(TASK_TYPES='ddl');

调低优先级，限制大表DDL资源消耗 大表加索引场景，缓解对线上业务的负面影响。

Analyze 后台执行

限制 Analyze 资源消耗情况，适用于手动或系统自动收集统计信息任务。

• ALTER RESOURCE GROUP default BACKGROUND=(TASK_TYPES='stats');

调低优先级，限制统计信息收集时的资源使用 减少大表统计信息收集时对集群资源的占用，为更重要的业务省出资源。

Lightning后台任务

Lightning大量数据导入，在执行的时候会消耗大量资源，从而影响在线的高优先级任务的性能。Lightning在导入方式backend="local"。

• 设置后台任务 BACKGROUND=(TASK_TYPES='lightning')

在没有设置 lightning 后台任务的时候，业务访问QPS下降了95%，可以说是干扰非常严重了。开启了后台任务以后，有一定的缓解作用，但影响还是比较大，这一块后续官方应该还会继续优化。

小结

在原有TiDB架构的基础上，官方又不断完善和推出相关的功能特性，其中以Runaway Queries和系统任务设置后台执行为优先推出。根据前面的分析和使用验证，我们可以在下面的应用场景有更好。更优雅的实现方式：

• 可以限制异常SQL对集群资源的使用，尽量避免对其他任务的性能影响。
• 对于大表添加索引DDL、Lightning数据导入、Analyze更新统计信息等系统任务，动态识别和限制资源使用，优先保证集群业务，大大提升集群的稳定性和可靠性。

具体而已，业务应用场景是：

• 自动识别并处理异常 SQL 性能问题，保障重要系统的服务质量。
• 对突发的 SQL 性能问题，在没有立即有效的修复手段时，可以对其限流，减少负面影响。
• 当已知个别 SQL 有安全或性能问题，可以加入黑名单进行限流。
• 通过设置后台任务，可以在任何时段在执行大表添加索引、Lightning导入数据、Analyze等系统任务，不再仅限于业务低估时期执行，大大提高运维管理的便捷性。

更稳定更高效的TiDB多租户系统

依靠资源管控的功能优化，我们在 TiKV 存储层和 TiFLash 列式引擎层实现不同用户的访问资源隔离，不仅能提高集群的资源使用效率，真正在实现降本增效，而且大大提升集群的稳定性、可靠性。

如下图，应用了新特性的多租户系统，我们可以为不同业务分配不同租户资源组管控，并为重要租户允许超额使用和高优先级，优先保证关键业务，同时又可以兼顾其他业务执行，最大程度保证了集群的整体运行效率和吞吐，实现真正的效率最大化。

在这里，结合v7.5版本带来的多租户特性，我们可以很好解决上文提到的几个问题：

• 高峰挤兑：当一个业务处于高峰期时，会过多占用集群资源，可能影响其他共存业务

  • 当前架构能保护不同业务的资源持有情况，保证业务能分配到基本的运行资源而不被挤兑。

• 低谷过剩：当集群中的重要业务处于低谷值时，有较多的剩余资源未被充分使用。

  • 多业务共用集群时，相当于有效引入了错峰运行的业务，充分使用资源，实现降本增效。同时要求业务能得到控制，其他时候不会占用过多资源。

• 异常放大：当集群有突发的异常 SQL 导致性能问题时，影响整个集群，只能停掉对应业务 。

  • 当集群出现负面SQL时，我们可以不用停止业务、也可以不用粗暴地干掉它的执行，而是可以临时限制它的资源消耗，允许它缓慢运行，但又不会影响集群其他业务，对业务和系统更加温和及友好。

架构实现优势

• 节约硬件成本

  • 跨业务混合共用集群，不会相互影响。
  • 减少集群数量，降低部署成本。
  • 错峰使用资源，提升整体利用率。

• 高可扩展

  • 低负载时，繁忙应用可超越限额使用资源， 大大提高系统的可扩展性。

• 灵活管控资源

  • 按需在线实时调整（增加资源、减少、设置上限等）业务资源使用，充分利用资源。
  • 在线限制负面SQL，实现熔断功能，极大保障在线业务。

架构实现劣势

• 复杂度高

  • 系统相对复杂，技术实现较难。
  • 集群管理门槛高。

• 总资源计算不准

  • 资源总量先硬件估计，运行后负载校准再人工调整，易出错。

• 资源精准分配难

  • 人工管理集群资源池，分配策略不好定。

• 资源管控的可视化观测不足

未来展望

• 增加内存管控

  • 将内存资源纳入 RU，进一步优化集群内存使用。

• 支持更多样的方式

  • 目前仅支持RU用量管控，需根据不同场景提供百分比、权重等多种资源限额定义方式。

• 更智能的管控

  • 通过分析历史运行数据，系统产出资源管理的建议报告。
  • 智能生成管控规则自动调控，实现基于 AI 的智能自动化运维。

• 提升易用性

  • 引入和完善图形化管理的方式，进一步提升用户体验，全面提升相关功能的可观测性和易用性。

未来如果要选择一个稳定的 LTS 使用版本，为实现更优雅、稳定和高效的系统架构，我强烈建议大家考虑和验证使用 v7.5 后的稳定版，相信它一定可以给到你足够的惊喜！