作者： 有猫万事足原文来源：https://tidb.net/blog/26695303

前言

在我的设想里面，我应该不会这么早用到这个特性，原因很简单，整个 TiDB 集群根本不涉及多租户的使用场景。应该说目前 TiDB 集群中的用户就 2 个：dmuser 用户负责把上游 mysql 写入流量接入 tidb 集群；biuser 只有只读权限配置到了 metabase 里面，给 metabase 查询用。即便是我要用到这个特性，也应该是在有一天真的使用 tidb 集群替换上游的多套 mysql 之后。那个时候是个典型的多租户使用场景。然而，首先让我对这个特性感兴趣的原因是 RU。

RU

资源管控的基本单位是 RU。https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control#%E4%BB%80%E4%B9%88%E6%98%AF-request-unit-ru

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

如果让我说 RU 好在哪里，首先就好在 RU 是抽象的。

看看我这个 4 核 8g 乞丐版集群的监控吧。

接入上游 mysql 写入流量后，cpu 一直不怎么高，除非执行大表的导入。但 tikv 的内存一直不低，tikv 内存超 80% 的告警一直在。所以我干脆设置了一个长达 1 年的静默期忽略了它。io 图的单位不是百分比，我看对应的数值很难评估当前 io 离极限有多远。

那问题来了，当老板问我，我准备上游再切 10 台同样 mysql 进 TiDB 集群，你的集群能抗的住吗？

我该怎么回答他呢？这 3 项指标有高有低，甚至有些本菜鸡都没有量化的标准。我敢说——行，放马过来；或者：不行，得加钱吗？

以上这个情况是我不能接受的。

经过抽象的 RU 却可以解决我的问题。我现在已经接入了 10+ 套上游的 mysql 写入流量。

因为 dmuser 基本都是写入操作，我只要进入资源管控界面，看下预估的 oltp_write_only RU 是多少，再看看当前的 RU 是多少就可以回答老板的问题了。

对于我这种非专业人士，我不需要关注 cpu，内存，io。这些太专业，太具体。也许有朝一日，我可以成为大佬靠这些指标来更加准确的评估集群的负载，但不是现在。

资源管控界面显示，预估 oltp_write_only RU 是 3w6，当前是 800. 我可明确的告诉老板，再来 10 套绝对没有问题。

非专业人士使用预估 oltp_write_only RU/oltp_read_only RU，再结合当前实际的 RU 消耗量，来评估集群的读写负载，可能是比 cpu，内存，io 这些更加直观的。

正是在这种对比下，我才确认当前的 TiDB 集群负载很低——即便某些节点内存占用高。

那下一个问题就是这个 oltp_write_only RU 的评估准确吗？

尝试通过负载校准

通过负载校准 RU 需要一定的负载。

想想我之前一导入大表，tikv 就轮流挂的 ’ 盛况 ’。来点负载根本不是事，安排。

于是在我执行了一个大表导入后，

校准的值比预估高一些

但是付出的代价也是触目惊心的

负载校准的值是比实际要高一些，不过从 tikv 的表现来看，它更像是在警告我，最好不要跑到这么高的 RU。

听人劝吃饱饭，改。

给 dmuser 添加资源管控

tikv 的内存告警一直是让我觉得战战兢兢的原因。而 tikv 也经常用实际行动告诉我，4 核 8g 这个乞丐版的配置对 tikv 来说是不靠谱的。

经过上面的测试，我决定还是按照预估的数字 36000RU 来设置 dmuser 这个偏向写的用户的 RU 上限，负载校准后的值是比这个高，但代价是不稳定，这就没有办法采纳了。

CREATE RESOURCE GROUP max_write_rg RU_PER_SEC = 36000 PRIORITY = MEDIUM;

BURSTABLE 参数不采用。原因同样是集群的稳定，我怕临时 BURSTABLE 一下，tikv 又挂了。

绑定 dmuser 到这个资源组。

ALTER USER dmuser RESOURCE GROUP max_write_rg;

因为绑定后只对新建会话有用，干脆重启一下角色为 tidb 的节点

tiup cluster restart <cluster_name> -R tidb

再执行导入，4 核 8g 的配置，cpu 最高也就在 350% 左右徘徊，不会再跑到 380% 以上去了。

执行导入的时候对读取任务也没有任何影响。

可以看到导入开始，写流量和读流量就变成两条平行线。中途有读取进来的时候，读流量会快速越过写流量，但写流量不会有任何抖动。有序，多么美妙。

在导入期间的 database time 拆解如下：

可以看到 dm 大表导入任务相关的 replace 和 commit 耗时明显变长。其他读取相关的操作时间也变长了一些，但绝对在可以接受的范围内。delete 和 update 耗时也在可以接受的范围，说明其他进入到 sync 环节的 dm 同步任务并没有受到显著的影响。

既然看上去稳定多了，就该浪一点了。

上一篇完成了生成列的改造，上游 10+ 个库的日志表都需要全部重新导一遍。7.1 版本之前我反复提醒：大表的导入 task 最好是错开执行，那现在就多起几个大表的导入 task 看看。把 task 中的 pool-size 调回默认值。不特别关注该参数设置。起多个 task。观察 tikv 一直稳定运行，再也没有发生 tikv 轮流挂的情况。

事实上，自从将 dmuser 加入资源管控之后，即使是我这个乞丐版的 4 核 8g 配置的 tikv 也再没有挂过。一直稳定运行到现在。

资源管控的问题

从我粗浅的认知来说：资源管控的问题在于，读写 RU 不能分开限制

从某种程度上，我觉得资源管控对我的系统稳定性的贡献这么大，完全是因为在当前这个场景下，我的读写用户是完全分离的。我可以根据 oltp_write_only 估算的 RU 数量给 dmuser 设置资源组。我还可以根据 oltp_read_only 估算的 RU 数量给 biuser 设置资源组。这两个组都能确保各自 RU 的用量不会超过他们各自实际行为的上限。哪怕我能看到如下这个提示信息，

而实际使用过程中，集群的稳定，确实是被资源管控有力的保证了。

但如果以后从 mysql 完全转向 TiDB，情况就会变得复杂，每个游戏服执行的是读写混合负载。当前集群读写 RU 并不均衡，读只有 7000，而写是 3w6000.我估计到时候我只能设置一个 7000RU 的资源组取读写这两者的最小值，作为混合负载的用户的资源组。当然这个判断是武断的，因为我的集群实际已经是生产系统了，我也没想出更好的混合负载测试方案。这方面我还要多学习其他大佬的资源组设置方式。

后记

从 4 月开始有想法，到目前基本改造完成，对数据库再无任何数据获取死角。大部分统计都可以在 10s 以内获得结果——在没有资源上 tiflash 的情况下。如果业务人员对这个结果有任何疑问，只要慢慢去掉聚合的维度和聚合的函数，就可以直接追踪到原始记录。这个上钻 / 下钻的过程是流畅的。因为不会影响上游生产环境，可以大胆的鼓励业务人员在数据中探索。从 mysql 迁移到 TiDB 的过程也是愉快的。全部使用 4 核 8g 来组成这个集群，也来我自己对于分布式系统的一个根深蒂固的认知。即，分布式系统从诞生的第一天起，就不是为了让更大马才能拉更大的车。它从诞生的第一天起，解决的问题就是蚂蚁如何咬死象。虽然有点运气的因素——7.1 版本恰好发布了资源管控特性，保证了集群资源不足时的稳定性。但这也同时证明了，TiDB 是一个好的分布式系统。好的分布式系统就应该能应付这种情况。TiDB 证明了自己。也证明了我的选择没有错。