TiDB 7.1 多租户在中泰证券中的应用

本文详细介绍了中泰证券在系统国产化改造项目中采用 TiDB 多租户技术的实施过程。文章分析了中泰证券数据库系统现状以及引入 TiDB 资源管控技术的必要性，探讨了 TiDB 多租户的关键特性，并阐述了在实际应用中的具体操作步骤。通过该技术的应用，中泰证券有效降低了运维成本，提升了开发效率。 文章强调了 TiDB 多租户在证券企业中的应用优势，特别突出了其在资源观测、复用、可配置性等方面的价值。

项目背景

中泰证券股份有限公司（原名齐鲁证券有限公司）成立于 2001 年 5 月，是国内排名前 20 的全国大型综合性券商，在全国 28 个省市自治区设有 45 家分公司、280 多家证券营业部，员工 9000 多人，控股中泰期货、中泰资本、中泰金融国际、中泰资管、中泰创投、齐鲁股权交易中心、万家基金，形成了证券、期货、基金、投资等各项业务齐头并进的发展格局。

受国际环境影响，在国家政策的大力支持下，系统国产化开始在全国范围内加速落地。中泰证券在系统国产化改造项目中，使用 TiDB 和国产化操作系统、芯片，提升自主可控能力。

中泰科技研发部目前使用两套 TiDB 集群，将多套业务系统进行集合。TiDB 集群版本号均为 V7.1。按照业务系统服务对象的不同，分别承载对外和对内客户业务。基于 TiDB 对大表的支持性更友好，无需分库分表，复杂 SQL 的性能提升明显，TiDB 的弹性扩缩容，简单易运维操作。这些，都毫无疑问地降低了运维成本、提升了开发效率。但是这两套集群都是多套业务系统共用，因此，非常需要资源管控技术，确保每一个业务系统都拥有独立的资源池。

TiDB 多租户介绍

TiDB 6.6 首次引入资源管控（Resource Control，简称：RC）特性，并在 TiDB 7.0 进行了优化和增强。该技术利用资源组 (Resource Group) 限制每个资源组所能使用的计算和 IO 资源，同时创造性的引入 burst （可超用）属性，当集群有空闲资源时，允许资源组超越限制，实现资源的充分利用。

这个特性满足了目前一些企业的需求，也可以顺带解决了部分用户的痛点：

1. 业务系统间影响和干扰?：某个业务系统的非预期负载变化会影响其他业务系统的正常运行。
2. 分析业务对交易的影响?：对资源需求较高的数据分析或批量作业会影响其他业务系统的响应时间。
3. 运维操作对资源的消耗?：数据备份、统计信息收集等后台任务可能会影响服务质量。

具体应用和实施

以下文章内容中的数据均基于生产环境做过修改，不是真实数据，仅供参考。

3.1 资源评估

打开 Dashboard 页面，在左侧菜单列表中找到 Resource Manager，在 Estimate Capacity 中 根据标准测试类型进行资源评估。

3.2 应用绑定 RU

通过梳理数据库中的业务用户，确定哪些用户是属于哪些业务系统，方便后面将不同的资源组与不同的用户绑定。

执行以下 SQL 为业务 A、业务 B、以及管理员绑定 Resource Control 和 RU。业务 A 和业务 B 同属于 TP 系统，业务重要性较高，对 sql 查询速度和效率都有一定的要求，对慢查询容忍性较低。所以对业务 A 和业务 B 的资源分配优先级要高一些，并且允许资源超用（BURSTABLE），应对前端业务流量的突增。而管理员账户日常主要用来做数据库管理相关的工作，很少或者不涉及业务 SQL，所以资源分配优先级较低，可以先设置成允许资源超用。

初步绑定都设置 BURSTABLE 属性确保每个业务都有充足 RU 可以使用，避免资源不足情况而无法观察到某个业务真实 RU 消耗情况。

-- 创建A资源组
CREATE RESOURCE GROUP IF NOT EXISTS a_rg RU_PER_SEC=180000 PRIORITY=HIGH BURSTABLE;
-- 创建B资源组
CREATE RESOURCE GROUP IF NOT EXISTS b_rg RU_PER_SEC=90000 PRIORITY=HIGH BURSTABLE;
.....
-- 创建管理员查询资源组
CREATE RESOURCE GROUP IF NOT EXISTS admin_rg RU_PER_SEC=20000 BURSTABLE;
?
-- 为不同业务系统用户绑定资源组
-- 将A资源组绑定到A业务系统用户上
ALTER USER a_user RESOURCE GROUP a_rg;
-- 将B资源组绑定到B业务系统用户上
ALTER USER b_user RESOURCE GROUP b_rg;
.....
-- 将管理资源组绑定到系统管理用户上
ALTER USER admin_user RESOURCE GROUP admin_rg;

3.3 观察应用 RU 使用情况

完成绑定后 ，TiDB 可以实时统计到各个业务消耗的资源情况。生产运行一段时间后，需要观察业务实际消耗 RU， 完成后续调整。

依然是去 Dashboard 页面，在左侧菜单列表中找到 Resource Manager。这个页面较之前业务系统用户没有绑定 RU 之前，多了一个 Configuration 模块。可以在这里模块清晰的观察到每个资源组的详细信息。

继续在 Resource Manager 页面中找到 Metrics 模块，观察 RU 的使用情况（建议观察时间区域尽可能长，以得到更全面的 RU 消耗情况），如下图所示。

将这个曲线和上面 Configuration 模块的 RU 信息对照，查看是否需要进行 RU 调整。调整语句如下：

-- A业务系统最高消耗 17000 RU ，建议绑定 25000 RU ，预留一定 Buffer ，由于总体资源充足设置 BURSTABLE 属性确保业务有足够资源
alter resource group a_rg RU_PER_SEC=25000 PRIORITY=HIGH BURSTABLE;
?
-- B业务系统最高消耗 14000 RU ，建议绑定 20000 RU ，预留一定 Buffer ，由于总体资源充足设置 BURSTABLE 属性确保业务有足够资源
ALTER RESOURCE GROUP b_rg RU_PER_SEC = 20000  BURSTABLE;
?
-- 设置管理员查询资源组，不设置 BURSTABLE 属性，降低管理员执行 Slow Query 时对集群影响
alter resource group admin_rg RU_PER_SEC=10000;

RU 使用收益

由于目前 TiDB 服务器资源充足，并且各个业务系统的峰值谷值都具有同一性，每个业务系统的重要程度也差不多。所以 TiDB 这个多租户特性带来的价值主要体现在资源的可观测性和可配置性上。

在资源可观测性上?：有了 RU，结合 Dashboard，可以清楚的观察到每个业务系统使用了多少资源，TiDB 整个集群资源是否充足，是否需要添加资源。

在资源可配置性上?：TiDB 多租户最重要的能力是在资源繁忙时实现资源控制，后续继续迁移新业务导致资源不足且临时没有服务器添加到集群的场景下可以在线解除 BURSTABLE 属性，给业务设置合适的 RU 大小来实现资源控制。此能力可以在线调整，对业务几乎无感知。在资源不足的极端场景下，能够控制不同用户的资源消耗，保证各业务系统的资源隔离性，用户可以安心使用 TiDB 多租户能力。

结语

大部分企业会给 TiDB 集群预留充足资源，此时利用 BURSTABLE 属性实现资源观测和资源复用；小部分企业无法给 TiDB 集群预留充足资源，此时可以在线修改多租户配置并实现资源控制。

目前，在证券企业中，许多业务系统跑在不同的 MySQL 集群上面。随着 MySQL 5.7 生命周期结束以及 IT 基础设施国产化改造的推进，把存量的多套 MySQL 集群归集到一套 TiDB 集群成为一个理想的解决方案。通过 TiDB 的资源管控特性，多个业务能够共享一套集群，实现资源的有效利用。对比传统多租户方案，TiDB 多租户除了基础资源控制能力以外还提供了更强大的资源复用能力、资源可观测性、在线可配置性、在线限流等能力。可以更好降低整体硬件成本、减少多集群运维成本、观测资源池使用率。