👆 立即咨询 TiDB 企业版 👆
资源管控技术（Resource Control）是 TiDB 7.0 版本中优化提升的重要能力之一，不仅可以在负载剧烈变化时，保证服务质量，同时提供了数据库的多租户隔离能力，能够有效地降低数据库运行成本，帮助企业节省信息化管理开支，提升企业的竞争力。
本文集合了三个资源管控的测试与实践案例，希望帮助读者更好地在优化数据库性能的同时，实现成本和效率的提升。
TiDB 资源管控的对撞测试
以及最佳实践架构
背景
TiDB 7.1 引入资源管控，面对存算分离架构的挑战，通过提高用户密度降成本，抑制业务干扰，避免集群抖动。本文探讨动态环境下如何优化资源管理和架构设计，以最大化资源管控效能。
资源管控验证指标
● OLTP vs OLTP 是否存在相互影响情况，包括业务层（TPS、QPS、duration）；
● OLTP vs OLAP 是否存在相互影响情况，包括业务层（TPS、QPS、duration）
● OLAP vs OLAP 是否存在相互影响情况，包括业务层（TPS、QPS、duration）
环境介绍
最小化部署 3 PD，3 TiDB，3 TiKV
● TiDB 节点：混合部署 PD 和 TiDB，共享监控与管理系统，保证计算节点负载均衡。
● TiKV 节点：单机多实例部署，每个实例在部署 TiKV 时都做了资源隔离，当 TiKV 节点跑满时，最多用到 16c。
实验设计
TiDB 是存算分离的分布式数据库，多种不同类别的 SQL 难免会集中到一个 TiDB 的计算节点上，而数据库中我们分为 OLTP 类业务和 OLAP 类业务。
● 基本场景：
● 压力来自相同的计算节点
● 压力来自不同的计算节点
● 设计压测样例：
● 验证目标：确保 TiDB 和 TiKV 资源（CPU、内存、网络）不达饱和，以防性能受损。
● 基线数据：收集无负载时的 QPS 和 P95 响应时间，用于后续性能对比。
● 资源管控策略：为每个用户分配独立资源组，实现 1 对 1 绑定，确保资源充分利用。
● TiDB 租户和资源组对应关系：
● 压测样例：
实验结论
实验结果显示，资源管控在 TiDB 中有效隔离了不同业务类型的资源使用，提高了系统稳定性。
在相同资源管控组内，不同用户执行 SQL 时未超出设定的 RU 值，而不同资源管控组在不同计算节点上的 QPS 和 P95 响应时间基本一致，但在相同节点上会相互影响。
OLTP 与 OLAP 混合执行时，P95 响应时间有所下降，尤其是当 OLAP 业务 RU 较少时影响更明显。OLAP 业务在不同计算节点上效率更高，且 TiFlash 的加入对查询效率影响不大。最佳实践建议通过架构优化，如使用 VIP 隔离计算资源和 RU 限制存储 IO，以进一步提升系统性能和稳定性。
点击此处丨阅读原文
金融企业区域集中库
的设计构想和测试验证
导读
本文讨论金融企业采用 TiDB 构建区域集中库，实现 MySQL 节点融合，推动标准化部署和统一运维，测试验证了成本效益和服务质量优势，为金融数据库架构优化提供实践指导。
区域集中库的框架设想
● 部署建设阶段：基于业务高峰评估可能导致资源浪费和配置发展不同步，而配置碎片化则阻碍了团队标准化和知识管理。
● 生产运行阶段：设计阶段主键缺失导致同步延迟和高可用性问题，业务重复订阅造成资源浪费，而复杂的数据库复制链路增加了管理成本并限制了数据价值的深入挖掘。
数据库整合场景测试
资源管控：
Request Unit (RU) 是对 CPU、IO 等系统资源的统一抽象的计量单位，用于表示对单个请求消耗的资源量。请求消耗的 RU 数量取决于多种因素，例如操作类型或正在检索或修改的数据量。
● 集群资源的评估
● 不同规格 RU 对联机交易的影响
● 资源组 BURSTABLE 属性对调度的影响
● 在线调整 RU 对联机交易的影响
读写分离：
在 MySQL 架构中，为防止对业务主交易造成影响，将从库用于数据抽取、异步检查等只读场景。区域集中库也需要实现等同于读写分离的隔离效果，分布式数据库配置 Learner 角色，只参与同步数据而不参与多数派投票。使用 Placement Rules 将 33 节点的 TiKV 实例标签配置为 Learner 数据副本，监控中对应实例的 Leader 数量为 0，只同步数据，不响应交易的读写请求。
● 会话的读写分离
● 物理备份的读写分离
业务管理：
多业务整合的场景中，不仅需要关注资源开销，还需要关注数据库的业务管理特性，比如 SQL 黑名单、细粒度监控、连接标识等，提升管理员的运维效率。
● SQL 黑名单功能
● 业务会话标识功能
● 细粒度监控功能
区域集中库的优势和使用设想
区域集中库是将数据库整合落地在数据库层，通过标准化部署和细粒度资源配置，得到更高的服务可用性、规格弹性和资源利用率。
综合各个能力项对比结果，评估区域集中库在建设和运行成本、服务质量上均具有较大的优势。
通过区域集中库的建设整合，将简化数据库能力分层模型。
通过区域集中库的建设，实现数据库部署架构的收敛。在此基础上，可进一步对业务数据操作行为的采集和分析，有利于生产运行向智能化转型。
点击此处丨阅读原文
基于资源管控+TiCDC
实现多业务融合容灾测试
背景
金融机构趋向融合多业务系统至单一分布式数据库集群，利用多租户和资源管控技术，以节约成本、简化运维并确保高可用性。采用主备集群方案实现容灾，按业务等级设定年度或周期性容灾演练。为减少影响，追求数据库支持单个租户的精细容灾切换能力。
TiDB 资源管控及 TiCDC 概要
● 资源管控：TiDB 通过流控和优先级调度实现资源管控，确保应用资源隔离和服务质量。数据库资源池划分为多个资源单元（RU），以统一计量 CPU、IO 等资源消耗，与其他多租户方案相比，TiDB 资源管控更细致且灵活。
● TiCDC：
TiCDC 作为 TiDB 的增量数据同步工具，能够捕获上游 TiKV 的数据变更，并将这些变更以有序行级形式同步至下游，支持跨区域多集群的数据高可用性和容灾，确保灾难情况下的主备数据一致性。
构建基于资源管控 + TiCDC
的多业务融合容灾测试
TiDB 通过 RU 资源管控和 TiCDC 实时同步，支持多业务共享资源和跨集群容灾，实现单个租户级容灾切换而不干扰其他租户。
测试过程如下：
准备集群环境：搭建 2 套相同节点数的 TiDB 测试环境，命名为 tidb-A 和 tidb-B，并分别安装部署 TiCDC 组件。
创建用户并绑定资源组：分别在两套集群中创建 3 个用户 (userA、userB、userC) 及 3 个资源组 (rgA、rgB、rgC)，用户和资源组一一绑定。分别使用不同用户在数据库中创建各自的 database，分别为 sbtest_a、sbtest_b、sbtest_c，它们代表不同业务系统的后台数据库。
创建同步链路：创建 3 条 TiCDC 同步链路 (changefeed)，分别为 sbtest_a (集群 A ) -> sbtest_a (集群 B) 、sbtest_b (集群 A ) -> sbtest_b (集群 B ) 、sbtest_c (集群 A ) -> sbtest_c (集群 B ) 。
模拟业务：运行 3 套 sysbench 测试，模拟 3 个业务场景。第 1 套 sysbench 测试使用 userA 用户连接到集群 A 的 sbtest_a，第 2 套 sysbench 测试使用 userB 用户连接到集群 A 的 sbtest_b，第 3套 sysbench 测试使用 userC 用户连接到集群 A 的 sbtest_c。
查看各资源组 RU 使用情况，可以看到都按照之前设置的1000 RU、2000 RU、3000 RU 使用到最大上限，且未出现超用的情况。
验证数据一致性：停止 sysnbech 模拟测试，使用 sync-inspector 检验两边集群数据是否一致。
切换单个同步链路：模拟切换单个同步链路，选择 sbtest_c (集群 A) -> sbtest_c (集群 B)。首先需要停止 sbtest_c 上的业务并移除（或暂停）当前同步链路，其次重新构建反向同步链路 sbtest_c (集群 B) -> sbtest_c (集群 A)，最后将模拟业务连接切换到集群 B 上。
删除正向同步链路：
搭建反向同步链路：
验证数据一致性：重新启动 sbtest_c 上的业务并写入集群 B，运行一段时间后停止并验证切换后的 sbtest_c 两边数据是否一致，同时也验证原来的同步链路 sbtest_a 和 sbtest_b 数据是否仍然保持一致性同步。
总结
本文验证了 TiDB 资源管控和 TiCDC 同步工具在多业务融合及容灾方案中的应用，通过资源分组和独立同步链路实现业务间的资源隔离和同步互不干扰，满足了金融机构对多业务融合、高容灾能力及单体应用容灾切换的需求。
点击此处丨阅读原文
👇 立即咨询 TiDB 企业版 👇
