半岛全站app「知乎」是如何在超大规模 TiDB 集群上玩转多云

　　代晓磊，知乎数据库负责人，同时也是 TiDB 社区北京地区组织者，一位有着 13 年数据库从业经验的数据库老兵，对数据库运维及 TiDB 有着丰富的实践经验。在“2024 新年围炉茶会”中，他分享了《TiDB 在知乎实践的那些事》话题，回顾了最近两年知乎 TiDB 实践的最新进展 ，以及对数据库未来发 展方向的个人观点，本文根据代晓磊老师的演讲实录进行整理。

　　知乎应用 TiDB 历史非常久，至今总共部署了 400 多个 TiDB Server 节点， 600 多个 TiKV 节点，数据规模达到 PB 级别。知乎有一个最大的 TiDB 集群有 500 多 TB 的规模，单副本一天能存 30TB 数据，三副本能存将近 100TB 左右。在这种规模下，知乎核心场景中约 30% 的场景都运行在 TiDB 上。

　　从数据库版本来看，目前知乎的 TiDB 集群大概有 80% 处于 TiDB 4.x 版本，有百分之十几在 TiDB 5.4.3 版本，还有少量的 6.5 版本。应用 6.x 版本主要是因为一些新的 feature 吸引我们，比如说热点表、CDC 能力的提升、多云多活的能力等。

　　目前来看，知乎是 TiDB 社区中唯一一家在互联网场景里落地多云多活的。在 2023 年年初的时候，我们就多云多活架构和 PingCAP 内部的产研团队做过一些交流。

　　第一种是基于 TiCDC 的主备集群方案。通过 TiCDC 的 能力能够解决一部分多云多活的需求，相当于使用 MySQL 的 Master and Slave 那种方式来用 TiDB 集群。它能解决一部分需求的原因取决于你对从库的定位，是将它定位为一个灾备库，还是一个只读库，还是承担业务一部分线上流量的库。

　　这种架构的关键点是什么呢？就在于 CDC 的同步能力。在 TiDB 4.x 时，CDC 的同步能力确实有点弱。之前我在上家公司的时候，个人与 PingCAP 做了 TiCDC 这个项目的合作，TiCDC 的一些场景、应用、需求，由我来提，由我去验证。比如早期的 TiCDC 经常容易 OOM，当拉取一个写入量很大的集群时，它对 TiKV 的负载影响在 20%左右，通过跟 CDC 团队一起迭代 + 优化，使得 CDC 对 TiKV 的影响降到 5% 之内。当 TiCDC 向下游 sync 的时候，它还有一些性能瓶颈，比如说 CDC 拉取得快， 但是 sync 到下游比较慢，那 TiCDC 整个内存消耗就比较大，最后就导致 OOM。后来 CDC 做了一些排序后的数据落地到文件中的改造，避免了一些 OOM 的问题 。通过这些优化，TiCDC 逐渐变得稳定可用。

　　还有另 外一种解决方案是自适应集群方案。它是 同一个数据中心里边的一个主备机房，可以通过自适应的方式去做 raft 级别的同步，可以有同城三中心、异地五中心等方式，将 TiDB 的同集群分布在不同 IDC 或者分布到不同云的方案。

　　我们最后选择的方案其实基于 Placement rule 的方案。我们有三个 IDC ，都是采用的某些云厂商的服务。其中有两个在线集群，在线集群集群是可以承担在线读写流量的，每一个集群里都有 TiDB Server 节点、 PD 节点和 TiKV 节点，还有一个灾备集群，基于副本 2-2-1 组成了五副本，通过 placement rule 的方式把副本投放到不同的 IDC，然后再结合 follow read 或者 steal read 的方式去承接在线的这部分流量。实现了任何一个在线机房宕机的时候，整个集群是可用的。最近这一段时间，包括一些大的云厂商，和一些很知名的 APP，都出现过不可用的故障情况。后面在讲到数据库发展的时候，也会讲到多云多活是未来必须要去解决和发展的方向。

　　然后再讲一下我们做的数据库稳定性建设，具体而言也就是 TiDB 的稳定性建设。TiDB 稳定建设其实分了几个方面：

　　可观测能力的提升是解决发现问题和定位问题非常好的方式。可观测性都包括什么呢？一般来说是包括如 metric、trace、log 三点。

　　首先，我来讲一讲 metric。刚来到知乎的时候，我发现监控项非常多，集群版本也很多。你们去看过文档就知道了，一个 TiDB 集群相关的监控项，有差不多 90 多个。每个集群有这么多监控项，每个集群的负载不同，它触发的报警阈 值可能也不同，公司采用同一套模版来渲染监控项目，这样的话，不同负载的集群在同一套报警触发阈值的情况下，就会发现我的手机晚上不断地收到预警信息，晚上根本就睡不着。metric 这个问题如果不解决其实真的很痛苦。

　　首先，我们对各种集群要设定不同的报警阈值，千人千面。不同集群的版本不一样，它的 metric 的表达式也不一样，它的阈值在不同版本也就不一样。你需要动态地去适配，搞成一个配置表，把这些监控项的配置实例化。针对某个集群的这套九十个指标的监控进行实例化；然后是报警配置，你可以做一些报警的聚合。之前的话，报警一发一堆，都是同一个报警。比如说有一个 schema error，这个报警可能同个集群里边有多个人、多个团队都在使用，那这个报警聚合之后就会发一条给到我们。怎么做报警聚合，怎么做报警预置，怎么做报警的定制化，发送不同人，这都是属于在 metric 做的一项。我们通过优化这些阈值报警，从最高时候的 1, 500 个 critical 的报警降到了几十个。这个东西一周几十个的线 天，每天就只有几个。再分分时间段，到晚上的报警也就稍微少一点， DBA 也能睡着觉 了。

　　第二是trace+log一起。trace+log是在 Ti DB 定位问题的时候很好的一个手段。知乎是 all in K8s 的，基于 TiDB operator 去做了一套整体的管控。这套东西对于这一套架构来讲，你要存日志的话，其实你得需要制定一定的 PVC 去绑定相应的 PV。存储需要绑 PV，你的日志也要绑 PV。但是我们日志没有绑 PV，因为数据盘都是给 tikv 用，日志建议用动态云盘，因为价格问题就没有配置。所以，之前日志只会打到 Pod 的 100M 标准输出里边去做轮询。有时候有的集群日志特别大的时候，如果这个日志如果没有持久化到硬盘，它只能保留几分钟，可能是 10 分钟。那 10 分之前发生的一个问题，之后再去排查的时候，就会发现没日志来看了。

　　在跟业务线去开故障复盘会的时候，这个业务就会 argue，“你为什么没有那个日志？”排查不出来问题的时候，因为没有日志这一项可能会附带上故障责任。那这个这时候需要怎么做？我们做了一套 ELK 的体系，就是基于 filebeat 去收集各个日志，包括 TiDB 的 error log、 slow 日志， PD + TiKV 的各种日志。把这些日志收集到 Kafka，其实在 ELK 里，有 logstash 这个软件，通过 lua 来解析日志。但是对于 TiDB 的 slow log 来讲，你需要让某一类的 SQL 通过打水印的方式形成一条 SQL，来进行 slow log 的聚合，基于 lua 实现就比较麻烦了，我们自己写了一套聚合的逻辑来存储这些慢日志。

　　稳定性建设还有一方面是关 于资源隔离。之 前我们做资源隔离的方式比较粗犷。为什么粗犷呢？因为之前采用的方式就是一个大的 TiDB 集群，各个业务线都在集群里创建 database 使用。如果资源隔离做不好的线，进而产生很多的问题。

　　之前的使用方式是大家都混用同一批 TiDB Server。导致的问题是一旦有一些业务使用了大的 SQL，占资源比较大的一些 SQL，就会导致这个集群的稳定性抖动。其实计算资源是可以做隔离的，分别创建不同业务的 tidb server 集群来给不同业务使用，实现了 TiDB Server 这个计算侧的隔离。

　　另外 TiDB 有各种的 SQL 抑制策略。比如说像 Max execution time (最大可执行时间)，就是 DML、Select SQL 一旦超过时间片杀不留，这是一个红线，是非常残暴的一个方式。第二个就是设定 SQL 的一些 quota。你可以通过各种 SQL 的 quota 的设定，让业务 SQL 使用的资源足够小。另外，你还可以搞一些自动化的杀 SQL 的程序，在触发最大可执行时间之前，杀掉你想杀的那些 SQL。类似于 pt-kill 的一些功能，就是杀什么用户的，杀什么类型的 SQL。这些就是稳定性建设里，非常细节的一些方面。

　　那在这种混用集群的情况下，存储测(TiKV)如何做资源隔离？第一种方式就是拆集群，之前混用的集群谁抖动影响别人的就把谁先拆出来，让它自己一个集群，尽量避免核心集群受到影响。之前用得比较粗犷，所有的 S、A、B、 C 级别的业务级别混用，那就需要从部署规划想办法。每个 S 级都单独给它搞一个集群，一个大业务线的 A 级的集群给它搞上三套。所有的 B、C 级以下的全都扔到一个老集群里边随便玩。这套方案涉及到大量 database 迁移，避免一个大集群里面有各种业务级别的数据库存在。做完业务拆分后就可以做 SLA 的承诺了。

　　其实各个业务线都有自己的 SLO 的指标，我们 DBA 是要求 SLA 指标，比如我们承诺 99.95% 的可用性。这个 99.95% 的可用性只赋予 S 级别业务。其他非 S 级的，我只保证 99.9% 的可用性。这样做了集群拆分后，我就敢跟业务去做承诺了，就能够保证自己的 SLA。这也是作为 DBA 这个行业里最核心的一个指标：稳定性是第一位的，哪怕其他事做得再漂亮，今年挂了 3 个 P0 的 DB，你的绩效肯定不好。

　　讲完多云多活和稳定性建设，再来说说知乎这两年在做的一个平台——天穹平台。天穹平台是用来干什么的？其实就是类似于 TiEM 加 TiDB dashboard，我们将它们整合了一下。这东西的好处是什么呢？我们想通过这套平台来管控整个 TiDB 的生命周期，把整个 TiDB 从创建到迁移，到日常运维，到下线的整个生命周期都放在一个平台上，通过点点鼠标的方式来进行运维管控。

　　我们搞了这套东西，把它的源数据一收集，然后去做迁移，去做管控，切 leader，包括查看日志、慢 SQL 报表、杀 SQL、监控、报警，所有东西非常全地整合到一个平台里。DBA 和业务都可以使用这个平台，业务使用平台可以创建集群，可以查看集群的 QPS。比如业务抖动了，看看是不是 TiDB 导致的，那就可以登到这个集群里面看看集群监控。比如我们结合 FinOps ，业务看看 TiDB 的成本怎么样。现在大家都在降本增效，那么你使用的库表有没有已经下线的大库表？有没有使用的资源超出自己预估？因为我们是按 GB 去把资源的费用分摊给业务的，在平台里边可以去调整他的资源的 quot。