TiDB 多业务合并新玩法

作者： 田帅萌 7 原文来源：https://tidb.net/blog/3a7745c8

一、背景

TiDB 在 v8 版本进一步加强了 resource control 和分布式框架的能力。基于之前的 placement rule in sql，我们可以推出 TiDB 新的解决方案。

比如机票业务：分为国内机票 / 国际机票 / 机票营销，如果每个子业务都需要一套 TiDB 集群。就会造成集群数据量多，服务器存在浪费的情况。

如果使用 resource control+placement rule in sql 的方案，可以进一步减少集群数量，减少人工运维成本，减少服务器数量。

对核心业务性能无影响，理由：指定了 TiKV 存储数据的物理节点，从而实现核心和非核心业务进行了物理隔离。

非核心业务使用 resource control 能力进行隔离，也避免了突发慢查询 SQL 影响集群。

无论是本地机房，或者同城三中心的部署默认，一样适用此方案。

二、方案架构图

1、placement rule 实现重要业务存储层彻底隔离 + 数据冷热分离；

2、resource control 实现次要的一些业务的相对隔离；

3、用分布式框架来实现并行任务（DDL、数据备份恢复、统计信息收集、TTL 管理等），对业务进一步提供稳定性保障的同时，还可以提供给业务进行 RDS 查询使用。

数据存放使用说明：

1、热数据区域 1，存放重点业务 A 数据；

2、热数据区域 2，存放相对次要业务 B、C、D、E 业务数据；

3、冷数据区域 1，存放所有业务 A、B、C、D、E 业务冷数据；

三、技术实现参考

1、label 设计参考

针对不同的 TiKV 设置 labels，分别设置 核心、非核心、其他的标签

核心（业务 A）：bussiness-a

非核心（业务 B、C、D、E）：bussiness-b

其他（业务 A、B、C、D、E）：bussiness-all 

2、创建并绑定放置策略

2.1、使用 CREATE PLACEMENT POLICY 语句创建放置策略：

在该语句中：

PRIMARY_REGION=“bussiness-a” 选项代表 Raft leader 被放置在 region 标签为 bussiness-a 的节点上。

REGIONS=“bussiness-a” 选项代表 Raft followers 被放置在 region 标签为 bussiness-a 的节点上。

更多可配置的放置选项和对应的含义，请参考放置选项。

2.2、db 层设置

默认情况下，直接 create table，数据即在对应策略的库下对应的 tikv 实例上。如：

如果想将该表数据放到其他策略的 tikv-server 实例下面，也可使用 CREATE TABLE 或者 ALTER TABLE 将放置策略绑定至表或分区表，这样就在表或分区上指定了放置策略：

PLACEMENT POLICY 为全局作用域，不与任何数据库表结构相关联。因此，通过 CREATE TABLE 指定放置策略时，无需任何额外的权限。

2.3、查看放置策略

要查看某条已创建的放置策略，可以使用 SHOW CREATE PLACEMENT POLICY 语句：

在 test 里面创建的表 默认属于 myplacementpolicya 规则

2.4、策略创建说明

在上面所介绍的业务背景下，应创建 3 个策略。

策略 1: 其中的 tikv-server 只存放业务 A 下的所有数据；

策略 2: 其中的 tikv-server 存放业务 B、C、D、E 下的所有数据；

策略 3: 用来将业务 A、B、C、D、E 所有的业务数据进行冷热分离（如超过 3 年数据存放在 hdd 盘上的 tikv-server 中）

实现逻辑图

3、设置 resource control 资源隔离

核心 DB 由于存放在独立的 tikv 节点，并且 tidb-server 也是独立的，无需给核心 DB 做资源隔离。

其他的 DB 是需要资源隔离，可以使用 resource control 进行隔离。

资源隔离采用 RU, 可以理解更细力度的资源统计。

Request Unit (RU) 是 TiDB 对 CPU、IO 等系统资源的统一抽象的计量单位，用于表示对数据库的单个请求消耗的资源量。请求消耗的 RU 数量取决于多种因素，例如操作类型或正在检索或修改的数据量。

四、总结

该方案特点如下：

1、在计算层，使用不同的 tidb-server 进行彻底的计算资源的隔离。并且也可以根据不同的业务重要级别配置不同的计算资源。如有任务系统 A 配置 3 台 16C64G 资源的机器部署 tidb-server 使用，业务 B、C、D、E 使用 4 台 8C32G 资源的机器部署 tidb-server，后台任务（DDL、数据备份恢复、统计信息收集、TTL 管理等）使用 3 台 8C8G 资源的机器部署 tidb-server，进一步确保业务稳定性；综合来看，根据业务重要等级，可以在计算层彻底的做到计算资源的隔离，也可以做到计算资源的共享；

2、在存储层，最重要的业务系统 A 单独享用 6 台 16C64G nvme ssd 盘的存储资源。业务 B、C、D、E 共同享用 6 台 16C64G nvme ssd 盘的存储资源。业务 A、B、C、D、E 所有业务的冷数据（如超过三年）共同享用 4 台 8C16G 的 hdd 盘的存储资源。综合来看，可以根据业务重要等级，可以在存储层彻底的做到计算资源的隔离，也可以做到存储层资源的共享；

3、在另一方面，可以在架构下，依据需求扩容 tiflash 节点，轻易的进行跨业务之间的数据关联分析，对外提供数据服务能力，而告别传统的 dblink 技术的使用；

4、随着越来越多的业务合并到一套集群，整体的硬件资源会越来越节省，完全可以作为 op 版本下的 dbaas 来使用；

5、随着业务的增加，可以按需扩展，完全无需做过多的资源评估工作，TiDB 极致的弹性能力提供了很好的体验；

6、该使用方式，不只是带来服务器数量的降本，同时也可极大降低运维负担。

采用这套方案，满足核心业务的资源使用情况。还能减少服务器硬件的使用和大幅降低了集群数量和维护成本。即使出现服务器宕机的情况，依然不会对其他业务造成影响。

就拿国内机票业务线举例，核心的独立集群，非核心的共享集群。非核心的集群没有采用资源隔离的手段，非常容易发生慢查询 SQL 影响整个集群，故障面容易被扩大。

如果采用 placement rule in sql+resource control 可以实现资源的完全隔离，那么可以进行集群整合。从而实现降低了成本，并且对业务无影响。