数据库｜TiDB v7.1.0：精准资源分配，实现数据流畅运行！

简介

TiDB v7.1.0 版本是2023年首发的 LTS （Long-Term Support Release）版本，带来了一些令人瞩目的新功能和改进。其中最显著的是Resource Control(资源管控) 功能，在此之前作为实验特性加入了 v6.6.0 版本，现在在 v7.1.0 版本正式 GA。

资源管控功能的 GA 标志着 TiDB 在资源管理方面迈出了重要的一步，为用户提供了更好的灵活性和可用性。通过利用这一功能，用户可以更好地规划和管理他们的 TiDB 集群，以适应不断变化的业务需求。用户可以在该功能的支持下更好地管理和组织他们的业务，确保各个业务之间相互独立，提高整体系统的稳定性。

使用场景

功能讲解

一、TiDB的流控

什么是流控？在数据库当中，流控是指在高并发场景下，为了保证数据库的稳定性和可靠性，对访问数据库的请求进行限制和控制的一种机制，在Resource Control特性里，对TiDB做流控是采取的令牌桶算法实现的。

什么是令牌桶算法 ？令牌桶算法是一种基于令牌的流量控制算法，可以用来平滑的去限制流量和请求的达速率，从而免受突发流量和攻击的影响。在一段时间内为用户或客户端分配一个令牌桶，每个令牌表示允许进行一次请求或数据包的传输。当用户需要发送请求时，需要从令牌桶中获取一个令牌，如果令牌桶没有令牌，则无法发送请求。同时，令牌桶会以一定的速率往令牌桶中添加新的令牌，从而控制请求的到达速率，保护系统免受突发流量的冲击。优点就是可以平滑地调节流量和请求的到达速率，有效避免了系统过载和崩溃的问题。

开关控制参数（系统变量）：

tidb_enable_resource_control

```
MySQL [(none)]> SHOW VARIABLES LIKE "tidb_enable_resource_control";
+------------------------------+-------+
| Variable_name | Value |
+------------------------------+-------+
| tidb_enable_resource_control | ON |
+------------------------------+-------+
```

二、TiKV的优先级调度

什么是TiKV的优先级调度？当开启 TiKV 调度特性后，TiKV 会根据每个存储组的RU_PER_SEC 值来映射每个存储组的读写请求优先级。在存储层使用优先级队列进行调度，以确保高优先级的请求优先处理，进而提高整体数据服务的响应速度和吞吐量。

什么是Request Unit（RU）？RU是TiDB中对系统资源的抽象单位，目前RU的话包括了CPU、IOPS、IO带宽三个指标，RU背后的实际资源使用情况与工作负载的资源消耗有很大关系，也与我们计算RU的公式中的系数有关，因此RU配额会随着工作负载的不同而变化，计算公式如下：

开关控制参数（TiKV配置文件参数）：

resource-control-enabled

```
MySQL [(none)]> SHOW CONFIG WHERE NAME LIKE "resource-control.enabled";
+------+-----------------------+--------------------------+-------+
| Type | Instance | Name | Value |
+------+-----------------------+--------------------------+-------+
| tikv | 192.168.146.132:20160 | resource-control.enabled | true |
| tikv | 192.168.146.130:20160 | resource-control.enabled | true |
| tikv | 192.168.146.131:20160 | resource-control.enabled | true |
+------+-----------------------+--------------------------+-------+
```

功能体验

一、集群配置信息

``` Cluster type: tidb Cluster name: tidb-test Cluster version: v7.1.0 Deploy user: tidb SSH type: builtin Dashboard URL: http://192.168.146.130:2379/dashboard Grafana URL: http://192.168.146.130:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 192.168.146.130:9093 alertmanager 192.168.146.130 9093/9094 linux/x86_64 Up /home/tidb/tidb-cluster/tidb-data/alertmanager-9093 /home/tidb/tidb-cluster/tidb-deploy/alertmanager-9093 192.168.146.130:3000 grafana 192.168.146.130 3000 linux/x86_64 Up - /home/tidb/tidb-cluster/tidb-deploy/grafana-3000 192.168.146.130:2379 pd 192.168.146.130 2379/2380 linux/x86_64 Up|UI /home/tidb/tidb-cluster/tidb-data/pd-2379 /home/tidb/tidb-cluster/tidb-deploy/pd-2379 192.168.146.131:2379 pd 192.168.146.131 2379/2380 linux/x86_64 Up|L /home/tidb/tidb-cluster/tidb-data/pd-2379 /home/tidb/tidb-cluster/tidb-deploy/pd-2379 192.168.146.132:2379 pd 192.168.146.132 2379/2380 linux/x86_64 Up /home/tidb/tidb-cluster/tidb-data/pd-2379 /home/tidb/tidb-cluster/tidb-deploy/pd-2379 192.168.146.130:9090 prometheus 192.168.146.130 9090/12020 linux/x86_64 Up /home/tidb/tidb-cluster/tidb-data/prometheus-8249 /home/tidb/tidb-cluster/tidb-deploy/prometheus-8249 192.168.146.130:4000 tidb 192.168.146.130 4000/10080 linux/x86_64 Up - /home/tidb/tidb-cluster/tidb-deploy/tidb-4000 192.168.146.131:4001 tidb 192.168.146.131 4001/10081 linux/x86_64 Up - /home/tidb/tidb-cluster/tidb-deploy/tidb-4000 192.168.146.132:4002 tidb 192.168.146.132 4002/10082 linux/x86_64 Up - /home/tidb/tidb-cluster/tidb-deploy/tidb-4000 192.168.146.130:20160 tikv 192.168.146.130 20160/20180 linux/x86_64 Up /home/tidb/tidb-cluster/data1/tidb-data/tikv-20160 /home/tidb/tidb-cluster/data1/tidb-deploy/tikv-20160 192.168.146.131:20160 tikv 192.168.146.131 20160/20180 linux/x86_64 Up /home/tidb/tidb-cluster/data1/tidb-data/tikv-20160 /home/tidb/tidb-cluster/data1/tidb-deploy/tikv-20160 192.168.146.132:20160 tikv 192.168.146.132 20160/20180 linux/x86_64 Up /home/tidb/tidb-cluster/data1/tidb-data/tikv-20160 /home/tidb/tidb-cluster/data1/tidb-deploy/tikv-20160 ```

二、确认开启资源管控特性

```
MySQL [(none)]> SHOW CONFIG WHERE NAME LIKE "%resource-control%";
+------+-----------------------+--------------------------+-------+
| Type | Instance | Name | Value |
+------+-----------------------+--------------------------+-------+
| tikv | 192.168.146.132:20160 | resource-control.enabled | true |
| tikv | 192.168.146.130:20160 | resource-control.enabled | true |
| tikv | 192.168.146.131:20160 | resource-control.enabled | true |
+------+-----------------------+--------------------------+-------+
MySQL [(none)]> SHOW VARIABLES LIKE "%tidb_enable_resource_control%";
+------------------------------+-------+
| Variable_name | Value |
+------------------------------+-------+
| tidb_enable_resource_control | ON |
+------------------------------+-------+
```

三、创建资源组，并绑定用户

```
CREATE RESOURCE GROUP IF NOT EXISTS app1 RU_PER_SEC = 200;
CREATE RESOURCE GROUP IF NOT EXISTS app2 RU_PER_SEC = 300;
CREATE RESOURCE GROUP IF NOT EXISTS app3 RU_PER_SEC = 400;
ALTER USER app1 RESOURCE GROUP app1;
ALTER USER app2 RESOURCE GROUP app2;
MySQL [(none)]> SELECT * FROM INFORMATION_SCHEMA.RESOURCE_GROUPS;
+---------+------------+----------+-----------+
| NAME | RU_PER_SEC | PRIORITY | BURSTABLE |
+---------+------------+----------+-----------+
| app1 | 200 | MEDIUM | NO |
| app2 | 300 | MEDIUM | NO |
| app3 | 400 | MEDIUM | NO |
| default | UNLIMITED | MEDIUM | YES |
+---------+------------+----------+-----------+
```

四、使用sysbench进行压测

```
（1）总共三个库，app_schema1 \ app_schema2 \ app_schema3 构建相同数据命令：
sysbench --config-file=config oltp_point_select --tables=5 --table-size=1000000 prepare
（2）读写使用三个用户分别压测三个库：
sysbench --config-file=config oltp_point_select --tables=5 --table-size=1000000 --db-ps-mode=auto --rand-type=uniform run
```

五、观察监控指标

2、运行中途更改RU值的监控指标

我们可以通过监控数据清晰地看到，资源管控的特性在这个过程中发挥了重要作用。不论是在运行前配置，还是在运行过程中临时调整，都能够有效地将资源使用率（RU）控制在我们设定的配额范围内。

这种资源管控的能力使我们能够更好地规划、优化和管理系统的资源，以确保其在高效运行的同时，保持良好的性能和用户体验。

命令简介

```
（1）指定时间对实际负载查看RU容量
CALIBRATE RESOURCE START_TIME '2023-04-18 08:00:00' END_TIME '2023-04-18 08:20:00';
（2）指定WORKLOAD查看RU容量，TPCC默认
CALIBRATE RESOURCE;
（3）创建资源组 CREATE RESOURCE GROUP IF NOT EXISTS appn RU_PER_SEC = 500 BURSTABLE PRIORITY = HIGH;
appn = 资源组名
RU_PER_SEC = 每秒限额
BURSTABLE = 允许超额
PRIORITY = 优先级（LOW|MEDIUM|HIGH） 默认MEDIUM
（4）查看资源组 SELECT * FROM INFORMATION_SCHEMA.RESOURCE_GROUPS;
（5）创建用户并绑定资源组 CREATE USER 'usr1'@'%' IDENTIFIED BY '123' RESOURCE GROUP rg1;
（6）将已有用户绑定到资源组 ALTER USER usr2 RESOURCE GROUP rg2;
（7）删除资源组 DROP RESOURCE GROUP IF EXISTS rg1;
这里需要注意，删除资源组需要先将绑定的用户去掉
（8）会话级别绑定资源组 SET RESOURCE GROUP rg1;
（9）语句级别绑定资源组 SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t limit 10;
（10）查看用户所绑定的资源组 SELECT USER,User_attributes FROM mysql.user WHERE USER = 'usr1';
```

总结