月活超 1.1 亿，用户超 4 亿，你也在用的「知乎」是如何在超大规模 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 在知乎实践的那些事

多云多活方案实践

第一个分享的实践是“多云多活”。

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

TiDB 的官方文档其实提供了很多种多云多活方案：

第一种是基于 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，都出现过不可用的故障情况。后面在讲到数据库发展的时候，也会讲到多云多活是未来必须要去解决和发展的方向。

数据库的稳定性建设

然后再讲一下我们做的数据库稳定性建