TiDB v7.1.0 跨业务系统多租户解决方案

导读

本文介绍了 TiDB 数据库的资源管控技术，并通过业务测试验证了效果。资源管控技术旨在解决多业务共用一个集群时的资源隔离和负载问题，通过资源组概念，可以限制不同业务的计算和 I/O 资源，实现资源隔离和优先级调度，提高系统利用率和稳定性。

业务背景

随着业务对 TiDB 的使用不断扩大和深入，在多业务共用一个集群的情况下，相信不少用户也遇到过不同负载之间相互影响的问题。在之前的版本里，TiDB 也在尝试不同的方法来缓解或解决这类问题。比较典型的例子就是通过引入 TiFlash 列存组件，在存储引擎层面区分 TiKV 上的在线处理事务和在 TiFlash 上的分析型任务，在存储层物理隔离不同的负载。这种架构优化有很多的好处，但如果业务都是需要访问 TiKV 才能得到结果的场景，就没办法来处理。

我们线上十几个生产集群，考虑成本、运维等问题都是多业务共用一个集群，在我们尽可能将 TP 业务和 AP 业务分离部署的前提下，通常还是会遇到下面的问题：

• 当一个业务处于高峰期时，会过多占用别的业务使用的资源，进而影响别的业务正常运行。
  • 我们希望能保护不同业务的资源持有情况，保证业务能分配到基本的运行资源而不被挤兑。
• 当集群中的重要业务处于低谷值时，有较多的剩余资源，如果我们能把错峰的业务引进来就可以充分使用资源，可以降本增效。但这要求错峰运行的业务需要能得到控制，其他时候不会占用过多资源。
• 当集群遇到临时的问题 SQL 引发的性能问题时，只能停掉 SQL 。
  • 我们更希望不是干掉它的执行，而是临时限制它资源消耗，允许它缓慢运行，但又不会影响集群其他业务。

在这样的业务痛点背景下 TiDB v7.1.0 提出了资源管控技术，我们第一时间跟进该技术，并尝试探讨解决融合系统中多租户资源使用的隔离方案。

TiDB 资源管控技术

资源管控技术（Resource Control）可以在负载剧烈变化时保证服务质量，同时提供了数据库的多租户隔离能力，能够有效地降低数据库运行成本。

原理说明

TiDB 资源管控特性提供了两层资源管理能力，包括在 TiDB 层的流控能力和 TiKV 层的优先级调度的能力。将用户绑定到某个资源组后，TiDB 层会根据用户所绑定资源组设定的配额对用户的读写请求做流控，TiKV 层会根据配额映射的优先级来对请求做调度。通过流控和调度这两层控制，可以实现应用的资源隔离，满足服务质量 (QoS) 要求。

• TiDB 流控：TiDB 流控使用令牌桶算法做流控。如果桶内令牌数不够，而且资源组没有指定 BURSTABLE 特性，属于该资源组的请求会等待令牌桶回填令牌并重试，重试可能会超时失败。
• TiKV 调度：可以为资源组设置绝对优先级 (PRIORITY)，不同的资源按照 PRIORITY 的设置进行调度，PRIORITY 高的任务会被优先调度。如果没有设置 PRIORITY，TiKV 会将资源组的 RU_PER_SEC 取值映射成各自资源组读写请求的优先级，并基于各自的优先级在存储层使用优先级队列调度处理请求。

TiDB 资源管控技术利用资源组 (Resource Group) 将集群划分为多个逻辑单元，每个资源组都能限制其所需的计算和 I/O 资源。当集群有空闲资源时，通过特定设置可以允许一部分资源组超越其限制，充分利用集群资源。它基本上解决了在多种业务合并后，造成资源争抢的问题，保证了业务的稳定性。如下是该技术的一个概念图：

Resource Control 是基于 TiDB 的流控和 TiKV 的调度功能来完成的。同时 BURSTABLE 功能允许其超过资源组的约束配额，使其可以保证服务正常运行。

管理方式

资源管控引入了资源组(Resource Group)的概念，通过设置“用户”和“资源组” 的对应关系，把