原文来源：https://tidb.net/blog/c71227fc

作者： 靳献旗   DBA   张帆   RD

1. 背景

“818 全球汽车夜 ” 是由汽车之家与湖南卫视联手打造的汽车行业顶级盛典，今年已经成功举办两届。本年度 ”818 全球超级车展” 由 “网上车展”、“超级合伙人嘉年华”、“车模大赛”、“行业峰会” 等一些列精彩活动逐步拉开序幕，并在 ”818 全球汽车夜 ” 达到高峰，为 8 月的汽车行业带来了一场购车盛宴。

2. 业务场景

作为 ”818 全球汽车夜 ” 最重要的一个环节，”818 晚会 ” 台网互动项目包含了一元秒杀车、抽奖、摇红包等业务环节，参与用户数以百万，晚会期间系统并发峰值达数十万，活动发出奖品、红包等数百万，更因每轮秒杀、摇奖等活动时间短，流量集中，以及业务场景涉及到对账核销，对系统设计提出了很高的要求。

3. 为什么选择 TiDB

业务场景如此，数据持久层的选型在系统设计中显的更为重要，因此我们基于以下原因采用了 TiDB 两地三中心的方案作为底层存储。

• 跨城级高可用

两地三中心架构，即生产数据中心、同城灾备中心、异地灾备中心的高可用容灾方案。在这种模式下，两个城市的三个数据中心互联互通，如果一个数据中心发生故障或灾难，其他数据中心可以正常运行并对关键业务或全部业务实现接管。相比同城多中心方案，两地三中心具有跨城级高可用能力，可以应对城市级自然灾害。

• 实时 HTAP

提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎，TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。利用 TiFlash 解决了实时大屏展示的问题。

• 一键水平扩容或者缩容

得益于 TiDB 存储计算分离的架构的设计，可按需对计算、存储分别进行在线扩容或者缩容，扩容或者缩容过程中对应用运维人员透明。

• 兼容 MySQL 5.7 协议和 MySQL 生态

兼容 MySQL 5.7 协议、MySQL 常用的功能、MySQL 生态，应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB。提供丰富的数据迁移工具帮助应用便捷完成数据迁移。

• 良好口碑和经验

用户产品中心在汽车之家是最早使用 TiDB 的 BU，早期将核心业务论坛回复从 SQL SERVER 迁移到了 TiDB，将车主价格从 MySQL 迁移到了 TiDB。具备迁移，使用，优化经验，且积累了良好的口碑。

4. 集群架构

4.1 架构简介

两地三中心架构，即生产数据中心、同城灾备中心、异地灾备中心的高可用容灾方案。在这种模式下，两个城市的三个数据中心互联互通，如果一个数据中心发生故障或灾难，其他数据中心可以正常运行并对关键业务或全部业务实现接管。相比同城多中心方案，两地三中心具有跨城级高可用能力，可以应对城市级自然灾害。TiDB 分布式数据库通过 Raft 算法原生支持两地三中心架构的建设，并保证数据库集群数据的一致性和高可用性。而且因同城数据中心网络延迟相对较小，可以把业务流量同时派发到同城两个数据中心，并通过控制 Region Leader 和 PD Leader 分布实现同城数据中心共同负载业务流量的设计。

4.2 集群信息

818 期间我们使用的国内一线云厂商高速云主机部署 TiDB 集群 ，云主机分布在云 C 区、H 区、G 区，多 IDC 部署。TiDB 集群两地三中心架构相关组件如下，五副本

| 模块名称 | 版本信息 | 数量 || ——- | —— | – || TiDB | v4.0.3 | 10 || PD | v4.0.3 | 5 || TiKV | v4.0.3 | 10 || TiFlash | v4.0.3 | 2 || TiCDC | v4.0.3 | 4 || MySQL | 5.7.25 | 1 |

说明

• TiDB、PD、TiKV 不再赘述，这里介绍一下 TiFlash 和 TiCDC

• TiFlash 是 TiDB HTAP 形态的关键组件，它是 TiKV 的列存扩展，在提供了良好的隔离性的同时，也兼顾了强一致性。列存副本通过 Raft Learner 协议异步复制。我们利用 TiFlash 解决统计分析类的 SQL，实时展示在大屏。

• TiCDC 是一款通过拉取 TiKV 变更日志实现的 TiDB 增量数据同步工具，具有将数据还原到与上游任意 TSO 一致状态的能力，同时提供开放数据协议 (TiCDC Open Protocol)，支持其他系统订阅数据变更。使用 TiCDC 将 TiDB 集群数据实时同步至下游的 MySQL 数据库，作为故障应急的备份，实现业务容灾能力的提升。TiCDC 数据同步的延迟在秒级别，很好地满足了线上促销类业务的实时性要求。

• MySQL 作为 TiDB 集群的应急，降级之用，实现业务容灾能力的提升。

4.3 集群架构

TiDB+TiFlash+TiCDC 整体架构图如下图所示

5. 测试

台网互动项目前期我们根据自己的业务场景分别对 3.0.16、4.0.1、4.0.2、4.0.3 两地三中心方案做了充分测试，测试过程中遇到一个问题和 Bug，在 PingCAP 小伙伴的帮助下都及时的得到了解决。

5.1 测试工具

测试过程中我们使用了 Sysbench 和业务模拟程序，因为 Sysbench 不具备重连功能，对于一些测试场景无法满足。

5.2 测试内容

818 晚会持续 3 个小时，因此我们根据实际业务场景制定了测试方案，主要测试项如下

5.3 测试结果

详细测试结果不再列出，主要测试结论如下：

无论是单节点故障，还是 IDC 级别的故障，都可以保证集群在 30 秒左右恢复，继续提供业务，满足业务需求。

5.4 测试总结

测试过程中遇到一些问题和 Bug，这里简单总结一下

• 现象：关闭 IDC2 模拟 IDC 故障时，再将五副本降为三副本，会导致集群几分钟不可用

      原因：因为 IDC2 故障时，此时操作副本配置从 5 变成 3，这个时候如果 PD 还没感知到 IDC2 故障，可能出现下发删除正常副本的命令，导致三个正常的副本会删掉两个，然后因为有两个副本 down 了，所以导致 region 不可用。

      解决办法：当 IDC2 故障后，先通过 pd-ctl 将 IDC2 TiKV 实例设置为 offline，然后将 5 副本调整为 3 副本时候，PD 就知道不会误删除 online 的 region，就不会出现读写请求因为 region is unavailable 导致不可用问题。

• 现象：设置调度参数 store-balance-rate 后，导致 pd 不断重启，导致集群不可用

      原因：触发 bug 导致，新版本已取消此参数

• 现象：将三副本调整为五副本不生效

      原因：开启 enable-placement-rules 后不兼容，目前五副本和此特性不兼容

• 现象：测试期间 TPS 在 15K 左右

      原因：主要瓶颈在磁盘，优化磁盘挂载参数后，TPS 可以达到 60K

      解决办法：优化磁盘挂载参数 mount 参数改为 rw,noatime,nodiratime,nodelalloc,journal_checksum,journal_async_commit,nobarrier,commit=60,data=writeback,inode_readahead_blks=4096

请注意根据实际业务情况修改，是否可接受。

• 现象：建表时主键使用了 AUTO_RANDOM 特性，压测时集群依然存在热点，导致集群 TPS 很低，业务响应超时

      原因：起初建表时表结构使用的是自增 ID 作为主键，虽然后来将自增主键改造为了 AUTO_RANDOM，但是数据还是老数据，ID 依然比较集中，导致 Update 主键产生热点。

      解决办法：清空测试数据，重新生成新数据后，热点问题解决，业务超时消失。

• 现象：TiCDC 的 CheckPoint 不平稳，呈现跳跃式

      原因：目前 TiCDC 的 CheckPoint 触发方式有两种，一种是达到一定时间进行 CheckPoint ，一种是达到设置的 max-txn-row 值进行 CheckPoint，而我们创建任务时设置的比较大，为 10000，导致了 CheckPoint 不平稳，呈现跳跃式

      解决办法：创建 TiCDC 任务时，根据下游 MySQL 处理能力设置，这里设置为 2000 后，CheckPoint 相对比较平稳，TiCDC 的延迟也减小了

6. 818 晚会期间表现

818 晚会期间，TiDB 集群表现良好，为秒杀、摇奖、红包等场景提供全方位的数据保障。

• 通过使用 TiFlash 将面板实时统计 SQL 由 0.5s 提高到 0.01s

• TiCDC 向下游 MySQL 同步延迟平均在 2 秒左右

• TiDB 集群 SQL 99 响应时间在 20ms 以下，9000 多个连接

7. 总结与展望

TiDB 两地三中心的方案具备很多优点：

• 五副本，多 IDC 部署，金融级高可用

• 实时 HTAP ，一站式解决 OLTP 和 OLAP 业务

• 一键水平扩容或者缩容

• TiCDC 高可用，低延迟，支持大规模集群

在测试 TiDB 两地三中心期间和使用过程中也发现一些小问题，相信这些问题官方在不久的将来都会得到解决，也希望 TiDB 越来越好。

• 同一类 SQL 在 TiFlash 上响应时间不稳定

业务压测期间，发现同一类 SQL 在 TiFlash 上会产生多个执行计划，导致响应时间不稳定

• TiCDC 对于单表的并发处理不足

业务压测期间，发现 TiCDC 对于单表的处理能力不足，导致单表延迟时间可能达到分钟级。这个问题是由于单表需要集中排序，所以如果单表吞吐非常大的分布式集群，这个问题很难彻底解决，研发也在尽量优化这个问题。

• TiCDC 任务分配不均衡

创建 TiCDC 任务时，如果是按照表级别创建的任务，可能会导致建的任务全部分配到同一个 Capture 上，尽管部署了多个 Capture。这个问题可以通过在一个 changefeed 下创建多个表来解决，同一个 changefeed 下的表可以自动均衡。

8. 感谢

818 晚会的完美举行和台网项目重保的顺利实施，离不开李坤、李仲舒、赵一霖、杨非、韦万等 PingCAP 小伙伴在测试过程中的帮助和建议，及时的解决了测试过程中遇到的问题和 Bug，并亲临 818 全球超级车展指挥中心现场，为 818 全球汽车夜保驾护航。