TiDB 在汽车之家818台网互动项目中的应用

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、PD、TiKV 不再赘述，这里介绍一下 TiFlash 和 TiCDC

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

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

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

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

5. 测试
   台 网互动项目前期我们根据自己的业务场景分别对3.0.1 6、 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 isunavailable 导致不可用问题。

现象：设置调度参数 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 全球汽车夜保驾护航。