DBA 减负捷径：拍个 CT 诊断集群热点问题 | TiDB 4.0 新特性前瞻（一）

作者：郑向升，骆迪安，施闻轩

古代，医者看病讲究「望、闻、问、切」，通过病人的外部综合表现对病症做出判断。现代，CT 的发明使得人们可以使用 X 光穿透身体各组织内部，将整体的情况以图像的方式展现出来，医生可以根据这个信息快速地排查问题。CT 的出现不仅将诊断的效率提升到了新的高度，也给客观描述身体状态提供了一个标准，是医学史上重要的里程碑。

一个工作中的 TiDB 集群如果只有个别节点非常繁忙，而其他节点相对比较空闲，我们就称这个集群存在热点（问题）。TiDB 作为一个分布式数据库，虽然会自动且动态的进行数据的重新分布以到达尽可能的均衡，但是有时候由于业务特性或者业务负载的突变，仍然会产生热点，这时候往往就会出现性能瓶颈。

在 TiDB 4.0 版本之前，如果我们要诊断集群中的读写热点问题，一般也需要经过「望、闻、问、切」，通过集群的对外表现逐渐摸清热点问题所在：

• 检查各组件 CPU 和 IO 是否均衡；

• 根据集群热区域列表逐一检查热点表；

• 通过表进一步分析业务逻辑查看热点成因；

• ……

整个过程比较繁琐，涉及到不同的工具和组件，需要一定的学习成本，而且整个结果也很不直观。

Google 在 Bigtable 的云服务中提供了一个可视化的工具：Key Visualizer，它可以优雅的解决热点排查的问题。在 4.0 版本中 TiDB 也实现了 Key Visualizer 功能。现在，我们可以很轻松地给集群拍个 “CT”，快速直观地观察集群整体热点及流量分布情况，如下图所示：

一个集群中只有少数节点在卖力工作，其他节点在划水，这个现象听上去像是 TiDB 的 bug，其实不然，它是一种 feature 🙃。正经地说，大多数情况下热点的出现是业务读写模式不能很好地适配分布式的场景的结果。

例如，如果 90% 的流量都在读写一小块数据，那么这就是一个典型的热点，因为 TiDB 架构上一行数据会由一个 TiKV 节点进行处理，而不是所有节点都能用于处理这一行数据。因而，如果大多数业务流量都在频繁访问某一行数据，那么大多数业务流量最终都会由某一个 TiKV 节点来处理，最终这个 TiKV 机器的性能就成为了整个业务的性能上限，无法通过增加更多机器来提高处理能力。

由于 TiDB 实际上是以 Region（即一批相邻数据）为单位划分处理，因此除了上述场景以外还有更多会产生热点的场景，如使用自增主键连续写入相邻数据导致的写入表数据热点、时间索引下写入相邻时间数据导致的写入表索引热点等，在这里就不一一介绍了，感兴趣的同学可以阅读 TUG 社区上的文章《TiDB 热点问题详解》。

由前文描述可知，热点的本质是大多数读写流量都只涉及个别 Region，进而导致集群中只有个别 TiKV 节点承载了大部分操作。TiDB Key Visualizer 将所有 Region 的读写流量按时间依次展示出来，使用颜色明暗表示读写流量的多少，以热力图的方式呈现。热力图使用户能对集群内 Region 热度情况快速地一窥究竟，直观了解集群中热点 Region 在哪里及其变化趋势，如下图所示：

图片说明：

1. 热力图的纵轴 Y 表示集群里面的 Region，横跨 TiDB 集群上所有数据库和数据表，横轴 X 表示时间；

2. 颜色越暗（cold）表示该区域的 Region 在这个时间段上读写流量较低，颜色越亮（hot）表示读写流量越高，即越热。

用户也可以控制只显示读流量或写流量。以上面这个图为例，它的下半部分有六条明显的亮色线条，表明各个时刻都有 6 个左右的 Region（或相邻 Region）读写流量非常高。用户将鼠标移到亮色线条处，即可知道这个大流量 Region 属于什么库什么表。

如图所示，热力图颜色均匀或者深色和亮色混合良好，说明读取或写入在时间和 Region 空间范围上都分布得比较均衡，说明访问压力均匀地分摊在所有的机器上。这种负载是最适合分布式数据库的，也是我们最希望见到的。

如图所示，热力图在 X 轴（时间）上表现出明暗交替，但 Y 轴（Region）则比较均匀，说明读取或写入负载具有周期性的变化。这种情况可能出现在周期性的定时任务场景，如大数据平台每天定时从 TiDB 中抽取数据。一般来说可以关注一下使用高峰时期资源是否充裕。

如图所示，热力图包含几个明亮的条纹，从 Y 轴来看条纹周围都是暗的，这表明，明亮条纹区域的 Region 具有很高的读写流量，可以从业务角度观察一下是否符合预期。例如，所有业务都要关联一下用户表的话，势必用户表的整体流量就会很高，那么在热力图中表现为亮色区域就非常合理。需要注意的是，TiKV 自身拥有以 Region 为单位的热点平衡机制，因此涉及热点的 Region 越多其实越能有利于在所有 TiKV 节点上均衡流量。换句话说，明亮条纹越粗、数量越多则意味着热点越分散、更多的 TiKV 能得到利用；明亮条纹越细、数量越少意味着热点越集中、热点 TiKV 越显著、越需要 DBA 介入并关注。

如图所示，热力图中某些区域突然由暗色变为了亮色。这说明在短时间内这些 Region 数据流量突然增加。例如，微博热搜或者秒杀业务。这种时候，需要 DBA 依据业务关注流量突变是否符合预期，并评估系统资源是否充足。值得注意的是，和第 3 点一样，明亮区域 Y 轴方向的粗细非常关键，明亮区域如果非常细，说明短时间内突然增加大量流量，且这些流量都集中到了少量 TiKV 中，这就需要 DBA 重点关注了。

如图所示，热力图显示了明亮的斜线，表明读写的 Region 是连续的。这种场景常常出现在带索引的数据导入或者扫描阶段。例如，向自增 ID 的表进行连续写入等等。图中明亮部分对应的 Region 是读写流量的热点，往往会成为整个集群的性能问题所在。这种时候，可能需要业务重新调整主键，尽可能打散以将压力分散在多个 Region 上，或者选择将业务任务安排在低峰期。