作者： angryart 原文来源： https://tidb.net/blog/ad24240a

多租户是什么

有语云，食在广州，玩在杭州，死在柳州，广东人除了天上飞的飞机不吃，地上走的坦克不吃，其它的什么都吃，广州作为省市，吃方面更为极致，它汇集了广府、潮汕、客家的各种特色和口味。一年一度的美食盛宴，广州为四方来客准备了万人宴席，但是万人宴席如何面对成万上亿的中国吃货呢？

一个笨方法是先入先出，通过先入者得到座席，吃完后先出去的方式，但是很快就出现问题 。有些客人是长服务，他提前就点了一堆的东西 ，结果只分配了他们5个座席，他们只能默默的吃，占住位置不释放。另外资源分配也有类似的问题，最后发生所有的座席满员，其它的人只能等待。可怜短服务需求的人，有些人不远万里过来只为吃一粒牛肉丸，有些人只为了吃一个叉烧包。因为愚蠢程序的设计，结果等着等着，活生生饿死，造成系统大面积瘫痪。

**解决问题之道 是加强资源调度管理，IT界引引入了多租户的管理方法。**业界有两个渐为成熟的管理方法， 一个是capacity 调度方法 ，一个是fair调度方法，capacity 把资源按比例分配给各个队列，队列下面再划分二层队列，并添加严格的管理制度防止用户或队列独占资源，而fair则是按照公平的原则把资源分给各资源组，力保每一个用户都在进行中。

通俗的话表达，capacity Scheduler就是根据资源适配业务，按比例划分长服务50%、中服务30%、短服务20%，这样长服务得到更多资源吃饭，吃完就走，短服务因为是吃一碗糖水，占平台的资源不多，吃完就走。fair Scheduler则按标签权重划分划分，而且在算法上会关怀短服务以及那些优先高的任务，这样它们快速完成任务资源释放，后面平台可以服务更多的用户。

数据库的多租户

业界应用实践capacity Scheduler和fair Scheduler的产品有YARN，YARN是hadoop2推出来的资源管理调度框架，沉浸多年，技术上已经非常成熟，估计OceanBase的开发就是借鉴了很多YARN的特性，OceanBase开源后本身就有多租户功能，创建一段OB多租户示例如下

创建15个CPU，3G内存的资源单位unitfish
obclient [oceanbase]> CREATE RESOURCE UNIT unitfish MAX_CPU 15, MEMORY_SIZE '3G', MAX_IOPS 1280,LOG_DISK_SIZE '10G',
 MIN_IOPS=1024;
Query OK, 0 rows affected (0.015 sec)
​
资源单位unitfish绑定资源池poolfish
​
obclient [oceanbase]> CREATE RESOURCE POOL poolfish UNIT = 'unitfish', UNIT_NUM = 1,ZONE_LIST = ('zone1');
Query OK, 0 rows affected (0.025 sec)
​
资源池poolfish绑定租户tenantfish
obclient [oceanbase]> create tenant tenantfish resource_pool_list=('poolfish'), charset=utf8mb4, 
replica_num=3, zone_list('zone1'), primary_zone=RANDOM, locality='F@zone1' 
set variables ob_compatibility_mode='mysql', ob_tcp_invited_nodes='%';
Query OK, 0 rows affected (24.164 sec)

OceanBase的资源管控是三步走的过程。

第一步定义资源单元 ，资元单元声明里面最少可以占用多少资源，最多可以占用多少资源。

第二步声明资源池 ，指定资源单元 以及相关 单元数量，两者乘积就是资源池所有的性能。

第三步就是资源池绑定租户 ，并指定租户与数据副本的映射关系。

OceanBase资源管控策略意图很明显，第一步先声明一个细粒度的资源，足够小以后可以按照业务的需求个性化组装， 第二步可以组合成功的资源规格可以满足业务的需求，一般这是完成与业务绑定了。

OceanBase的资源管控策略与capacity Scheduler、fair Scheduler不一样， TiDB的创新方式也与OceanBase的不一样。

TiDB的资源管控核心理念是RU**,Request Unit (RU) 是 TiDB 对 CPU、IO 等系统资源的统一抽象的单位**, 目前包括 CPU、IOPS 和 IO 带宽三个指标。这三个指标的消耗会按照一定的比例统一到 RU 单位上。

区别于OB的细粒度管控方式，TiDB通过PRIORITY和BURSTABLE对资源争夺进行管控，如果发生资源恶性竞争，优先满足PRIORITY高的资源组，如果发生资源闲置，打上BURSTABLE的资源组允许当它处理空闲时其它资源组使用它的资源。

TiDB的资源组除了能够绑定租户，也能绑定会话，语句。不过，笔者认为最有特色的是 根据实际负载估算容量 。

capacity Scheduler的资源管控策略基于集群硬件部署按照比例的方式笼切去切分，OceanBase的资源管控策略则是基于硬件部署的精确个数去划分，前提是必须知道服务器有多少个CPU，CPU是什么规格属性，才能灵活分配资源，属于 硬件配置校准 的方式。

现在TiDB的 根据实际负载估算容量 可以忽略服务器软硬件的情况，通过业务负载知道预判该租户可以使用多少资源。技术原理与openGauss的AI4DB的类似，openGauss实现数据库自治运维管理，通过采集CPU、内存、硬盘的工作指标状态，保存在时序promethous里面，定期汇聚合并，通过dbmind分析数据库的运维参数，从而得出哪些参数需要调整优化。

与openGauss不同，TiDB不需要额外安装组件、服务、时序数据库，这个比较省心。不过启用 根据实际负载估算容量 会占用TiDB额外的计算消耗。

实验环境

操作系统	CentOS Linux release 7.6.1810
CPU	8核 Intel(R) Xeon(R)
内存	16

以下创建三个资源组，其中RG1是100，RG2是500，RG3是2000，如下。选 用sysbench以及chbenchmark做压力均衡的测试。

​
CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 100 ;
CREATE RESOURCE GROUP IF NOT EXISTS rg2 RU_PER_SEC = 500;
CREATE RESOURCE GROUP IF NOT EXISTS rg3 RU_PER_SEC = 2000 PRIORITY = HIGH BURSTABLE;
​
CREATE USER 'sysbench1'@'%' IDENTIFIED BY '123456' RESOURCE GROUP rg1;
CREATE USER 'sysbench2'@'%' IDENTIFIED BY '123456' RESOURCE GROUP rg2;
CREATE USER 'chbench1'@'%' IDENTIFIED BY '123456' RESOURCE GROUP rg3;
​
#  sysbench1绑定rg1
#  sysbench2绑定rg2 
#  chbench1绑定rg3 
​
​
grant all privileges on   chbenchmark.*  to  chbench1;
grant all privileges on   chbenchmark.*  to  sysbench1;
grant all privileges on   chbenchmark.*  to  sysbench2;
​

测试资源隔离

以sysbench做基准，分别以sysbench1和sysbench2执行相同一个任务，如下。期望 500RU的sysbench2会比100RU的sysbench1快。

sysbench   /usr/share/sysbench/oltp_read_only.lua  --mysql-user=sysbench1 --mysql-password='123456' 
--mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark --tables=4 --table_size=1000 
--threads=4 --time=3000 --report-interval=10   run
​
sysbench   /usr/share/sysbench/oltp_read_only.lua  --mysql-user=sysbench2 --mysql-password='123456' 
--mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark --tables=4 --table_size=1000 
--threads=4 --time=3000 --report-interval=10   run
​
sysbench1的结果如下
​
[ 10s ] thds: 4 tps: 23.49 qps: 378.07 (r/w/o: 330.69/0.00/47.38) lat (ms,95%): 204.11 err/s: 0.00 reconn/s: 0.00
[ 20s ] thds: 4 tps: 19.90 qps: 319.62 (r/w/o: 279.82/0.00/39.80) lat (ms,95%): 211.60 err/s: 0.00 reconn/s: 0.00
[ 30s ] thds: 4 tps: 19.80 qps: 316.92 (r/w/o: 277.32/0.00/39.60) lat (ms,95%): 211.60 err/s: 0.00 reconn/s: 0.00
​
​
sysbecn2的结果如下
​
[ 10s ] thds: 4 tps: 110.17 qps: 1766.70 (r/w/o: 1545.95/0.00/220.75) lat (ms,95%): 95.81 err/s: 0.00 reconn/s: 0.00
[ 20s ] thds: 4 tps: 100.80 qps: 1613.18 (r/w/o: 1411.57/0.00/201.61) lat (ms,95%): 42.61 err/s: 0.00 reconn/s: 0.00
[ 30s ] thds: 4 tps: 99.29 qps: 1587.17 (r/w/o: 1388.59/0.00/198.58) lat (ms,95%): 43.39 err/s: 0.00 reconn/s: 0.00

结论，满足预期目标，sysbench2因为RU值大，所以同样任务，sysbench2比sysbench1快。

测试资源抢夺

以sysbench做基准，先运行chbench1的oltp_write_only任务10分钟后，再陆续挂起sysbench1和sysbench2的oltp_read_only任务，最后以chbench1的身份再运行一个oltp_read_only任务

期望目标

• chbench1的oltp_read_only任务中途插入，凭借PRIORITY = HIGH 可以获得较多的资源
• chbench1的oltp_write_only任务结束后，因为BURSTABLE资源释放，sysbench1和sysbench2的oltp_read_only任务的计算速度提升，chbench1的oltp_read_only任务也有所提升。

1.首先运行chbench1的oltp_write_only任务
sysbench   /usr/share/sysbench/oltp_write_only.lua  --mysql-user=chbench1 --mysql-password='123456' 
--mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark --tables=4 --table_size=1000 
--threads=4 --time=3000 --report-interval=10   run
​
2.运行sysbench1的oltp_read_only任务
sysbench   /usr/share/sysbench/oltp_read_only.lua  --mysql-user=sysbench1 --mysql-password='123456' 
--mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark --tables=4 --table_size=1000 
--threads=4 --time=3000 --report-interval=10   run
​
3.运行sysbench2的oltp_read_only任务
sysbench   /usr/share/sysbench/oltp_read_only.lua  --mysql-user=sysbench2 --mysql-password='123456' 
--mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark --tables=4 --table_size=1000 
--threads=4 --time=3000 --report-interval=10   run
​
​
4.运行chbench1的oltp_read_only任务
sysbench   /usr/share/sysbench/oltp_read_only.lua  --mysql-user=chbench1 --mysql-password='123456' 
--mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark --tables=4 --table_size=1000 
--threads=10 --time=3000 --report-interval=10   run

chbench1的oltp_write_only开始任务运行后，系统约占200RU。10分钟后追加的sysbench1的oltp_read_only任务和sysbench2的oltp_read_only任务，chbench1的oltp_write_only任务依然是200RU,而sysbench1、sysbench2的系统RU分别是100和150。 14:00之前的时间线，chbench1、sysbench1、sysbench2分别是200RU、100RU、150RU.

最后插入chbench1的oltp_read_only任务，chbench1升到500以上的RU，平均值接近550RU。而sysbench1和sysbench2并没有任何变化，依然是100和150左右徘徊。 14:00到14:30的时间线，chbench1、sysbench1、sysbench2分别是500、100RU、150RU.

chbench1的oltp_write_only任务结束后，sysbench1仍然占系统的100RU，oltp_write_only资源释放后， 而sysbench2迅速从原来的150RU升到接500RU，而chbench1的oltp_read_only任务速度有了质量的提升，飙升到2500RU。 14:30到14:45的时间线，chbench1、sysbench1、sysbench2分别是2500、100RU、500RU.

14:45后，sysbench1和sysbench2任务结束后，chbench1的RU进一步急升。 14:45之后的时间线，chbench1是3000RU

结论，chbench1、sysbench1、sysbench2三者竞争，优先满足chbench1的资源需求，sysbench2与chbench1竞夺，自己只占有150的RU。 chbench1拥有优先权，可以继续给chbench1添加任务。在chbench1的部分资源释放后，可以提供给sysbench2使用。

测试资源耗尽

以chbenchmark做基准，通过chbench1和sysbench对集群发起HTAP的压力测试，机器预先加载有tpc-h数据，期望平台会对客户提交的不合理要求截断，并提示报警。

​
/root/.tiup/components/bench/v1.12.0/tiup-bench ch --host 192.168.10.13 -Usysbench1 -p123456 -P4000 
--warehouses 1 run -D chbenchmark -T 1000 -t 50 --time 60m
​
​
​
/root/.tiup/components/bench/v1.12.0/tiup-bench ch --host 192.168.10.13 -Uchbench1 -p123456 -P4000 
--warehouses 2 run -D chbenchmark -T 10000 -t 50 --time 60m
​

sysbench1的执行过程中报错，提示failed Error 8252: Exceeded resource group quota limitation，整体系统依然在运行，没有对租户采取强硬措施处理。

chbench1的执行过程中没有报错，系统在持续满足它的资源需求，没有对租户采取强硬措施处理，直到系统不胜负荷，wait使用100%，swap使用100%。

结论，面对chbench1和sysbench1的不合理要求，系统没有把它强行掐断，结果恶性循环导致系统资源消耗殆尽。

通过负载校准

2379监控界面的负载校准必须要持续一段的压力才能出结果，技术原理它是按时序采集压测数据，根据对系统访问，算出平台应该调成多大RU负载。

笔者设了密集的频发的压力测试，经过系统计算后结果是8536RH，相对原来的硬件推荐的14886RU要少。选用8536RH比起14886RU　更合理。

/root/.tiup/components/bench/v1.12.0/tiup-bench ch --host 192.168.10.13 -Uchbench1 -p123456 -P4000 
--warehouses 2 run -D chbenchmark -T 10000 -t 50 --time 60m
​
​
​
​
sysbench   /usr/share/sysbench/oltp_read_only.lua  --mysql-user=sysbench1 --mysql-password='123456' 
--mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark 
--tables=4 --table_size=1000 --threads=4 --time=3000 --report-interval=10   run
​
sysbench   /usr/share/sysbench/oltp_read_only.lua  --mysql-user=sysbench2 --mysql-password='123456' 
--mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark 
--tables=4 --table_size=1000 --threads=4 --time=3000 --report-interval=10   run

结论，负载校准相对硬件配置校准的极限负荷，表现更真实，更贴近资源的分配。

总结

多租户管理充分利用了资源 ，面对百万来宾，不需要摆百万宴席，也不需要假设性十万宴席，通过科学有效的现代化管理手段 ，万人宴席就好。

资源隔离是多租户必备的基本能力 ，每个租户分配的资源不一样，才能有序进行工作。

资源抢夺是多租户的核心处理能力 ，当出现竞争的时候，保障VIP食客先吃，低级别的用户也可以吃一部分。VIP食客户快速吃完抂，再腾资源出来，整体协调共进。

资源耗尽是多租户最想避免发生的事情 ，目前资源管控都是通过cgroup技术实现的，本质也是线程管控的。估计这里的测试chbechmark的线程并发有关系，里面有执行tpc-h的昂贵执行，跨越管控，最后发生资源耗尽。

通过负载校准是未来的技术趋势 ，与数据库AI有关，根据真实的业务负荷提供调整数据库建议参数，目前AI在TiDB的应用是租户资源调整，以后还会有很多增长空间。

笔者只知道国产数据库中，只有OceanBase有多租户功能，TiDB直至7.1才推出成熟的资源管控手段 ，来的迟，但是没有晚，亮点让人耳目一新，TiDB7.1的 硬件配置校准 继承传统的资源管控策略，按照工程师的熟悉习惯对服务器配置规格分配资源，同时也在 负载校准 提供了新的手段，通过人工智能识别数据库的最佳参数。

相对OB的大而周全，TiDB是小而精致。OB新建用户，都必须绑定租户，绑定租户需要三步走，三步走之前必须算好我应该划分多少个CPU、多少内存。 而TiDB假设你没有多租户的需求，那么你直接新建用户，不需要你强制绑定资源组。这样一对比，TiDB的多租户显得锦上添花了！