作者： Jellybean 原文来源：https://tidb.net/blog/61c1921c

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

前言

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 后的稳定版，相信它一定可以给到你足够的惊喜！