第三方数据延迟取不出来 TiDB 在丰巢核心支付平台百亿级数据的深度实践
专业出黑
“
这次我们选择支付平台来作为迁移到 TiDB 上的业务，就是想证明在丰巢所有的 OLTP 业务范畴内，我们是可以 All in TiDB 的。它对于丰巢的意义就在于，可以长期规划丰巢的数据库的选型和资源的投入，避免数据库产品使用的分裂和无效资源的投入。
”
丰巢第一次在生产环境实际使用 TiDB，是在 2018 年，其场景是每天产生一亿条以上数据的推送平台，当时我们还发了一篇文章，被 官方收录《》。这次，因为实际的项目需要，我们选择了 QPS 和数据一致性要求更高的支付平台，作为第二个迁移到 TiDB 上的项目。由于丰巢的所有支付，都会通过该平台产生，所以其稳定性和性能，都是重中之重了，而这次的迁移之旅，也就特别的漫长和曲折。
1. 支付平台现状及问题
在迁移 TiDB 之前，丰巢支付平台全部运行于 MySQL 之上，其基本情况如下：
这在互联网行业，是很常规而古典的方案了，虽然够用，但是遇到复杂情况时，其实会有很多瓶颈点，详情如下：
这些问题是丰巢的支付平台实际发生过的问题，相信其它用 MySQL 分库分表作为解决方案的中小型公司，都会遇到类似问题。尤其是异构数据库的问题，因为支付平台对于所有的订单和交易等信息按照用户 id 进行了分库分表的操作，这就使得一些基本的常规查询请求（非用户 id 维度），通过 MySQL 数据库无法提供服务，我们便添加了一套 集群提供这样的服务。在同时使用 MySQL 和 的过程中，数据延时和数据不一致的问题经常就会跳出来让我们难受一下。
2. TiDB 的优势
为了寻求更好的解决方案，让支付平台更加稳健，我们再次把目光投向了 TiDB，尝试做为支付平台的核心解决方案。相比于 MySQL，其优势如下：
基于这样的优势，加上我们对 TiDB 团队和实力的了解，加上之前推送平台的迁移经验，我们坚定的开始了迁移之路。
3. 迁移之路
3.1 标准步骤方案
在支付平台迁移之初，我们就提出了 TiDB 迁移的标准化方案，支付平台在迁移的过程中，除了部分步骤是需要反复执行之外，大体上都是按照标准化方案来走的。
如上图所示，我们没有采用先切读流量到 TiDB 集群和双写的方案，而是直接切换到 TiDB 之上。这主要是基于以下的几点原因：
3.2 数据同步方案
数据库迁移从来就不是容易的事情，为了让支付平台的数据，无缝的从 MySQL 迁移到 TiDB，我们制定了如下数据同步策略和框架：
由上图可知，我们的数据同步包括了三种同步机制：
1. 全量同步到 TiDB 集群
借助开源工具 和 公司的工具 来实现，为了不影响 4 个 ， 是从 4 个 slave 进行数据的拉取。因为支付平台的数据总量超过 100 亿，所以这个同步的过程是非常漫长的，要花费几十个小时，由于当时没有使用 DM 这样自动化的同步管理平台，这个过程是痛苦且漫长的。以后有这种类似 MySQL 到 TiDB 的同步需求，我们都会使用 DM 来完成。（注：TiDB Data ，简称 DM，是用于将数据从 MySQL/ 迁移到 TiDB 的工具，详见：）
2. 实时增量同步
使用 公司的 sync 来实时读取 MySQL 的 ，增量同步数据到 TiDB 集群。
3. 数据实时回导到 MySQL
为了让数据实时回导，我们研发了两个工具，来确保完全可靠：
3.3 流量回放方案
在一开始制定的迁移方案中，本来是没有流量录制和回放这个工具的。但是因为第一次迁移失败，就促使我们开发了这样的一个工具：。其目的在于生产环境流量录制和回放，这是至关重要的一个工具。使用 ，我们可以发现如下问题：
从而可以在不正式切换生产的前提下，就能重复发现问题，对我们正式切换成功有很大的帮助。
的整体架构图如下:
它具备下面的 :
一开始本着不重复造轮子的原则，想在开源领域找到一款合适我们的产品。但是经过多番调研，包括 工具，它并不能满足丰巢的实际情况：
为了满足上面 3 个要求，丰巢开始了 的自研之路，我们选择了 开源的() 作为从数据链路层抓包的工具，在这个基础上封装完善了上面提到的功能。基于 工具，我们发现了如下的问题，并进行了修复：
以上列举的问题，都是在使用 流量回放工具，回放暴露出来的问题，前 3 个问题后面会详细的分析。
在实际的迁移过程中，会存在一些特殊的情况，超出了我们的掌控外围之外：例如，业务上新增了表和字段，我们没有办法靠人去对齐这些事情， 最大的价值就是能够覆盖这些业务逻辑的变化。在前面讲述标准化迁移方案里面，正因为有了 等工具的存在，我们才能放心的，不经过灰度直接全量切换到 TiDB。
3.4 灰度发布方案
我们在制定灰度发布方案的时候，一开始在切流量的问题上有一定的讨论：
如果只切读流量的话，主从之间有延迟，很难满足支付平台的数据一致性要求，并且业务上实现也很困难。最后我们选择了同时灰度读写流量到 TiDB 的方案。
如上图所示，支付平台在进行适配灰度发布的过程中，需要具备以下几点的能力：
在支付平台切换 TiDB 的过程中，共灰度发布了四次：
3.5 快速回滚方案
支付平台的回滚方案是建立在 TiDB 到 MySQL 数据同步服务正常的基础之上的，回滚方案按照自动化程度分为两种：人工回滚和自动回滚，其中自动回滚需要借助自研工具 来完成。 这个工具的产生也是源于上次切换的失败，虽然上次切换 TiDB 的过程中，我们做了很多的保障措施，但是在实际问题发生的过程中，因为需要人去判断和操作，所以我们便做了 这个工具，让系统去判断 TiDB 集群是否出现问题了，是否需要把数据库切换回 MySQL。
如上图所示， 的 如下：
4. 迁移的坑
迁移 TiDB 的过程中，不可避免的会遇到一些坑，主要的大坑**如下：
4.1 全量数据迁移后 TiDB 集群停止响应
这个问题是 TiDB 切换过程中遇到最大的一个问题，事后分析主要原因有两个：
1. TiKV 2.1.9 的 Bug
TiKV 的一个已经解决的 bug，我司当时 TiDB 的版本是 2.1.9，当 时遇到了 conf 时，会出现短暂的慢查询现象（连接会被 TiDB 占住一段时间）：PR 链接（）。
PR 更改的核心的代码在TiKV 的 /store/peer.rs 中
当 在 时，会先判断 是否在做 conf ，如果已经做完并判断 conf 的时间间隔，都满足条件后才允许进行 的操作。「TODO: fix the issue in Raft.」这句注释说明了 公司未来会在 Raft 协议层面去解决这个 bug，目前的方法只是临时的解决方案。
2. Nginx 相关问题
nginx 在做 tcp proxy 时，会偶尔出现连接卡死的现象，只有到达超时时间，连接被 kill 后，此连接的业务才会恢复。我司之前使用的是第三方的 le 的模块。后来把 nginx 的版本升级为 1.17.1 并使用 nginx 官方的 模块，此问题也解决了。
4.2 SQL 执行突然变慢
在使用 进行流量回放的过程中，有一天早上所有的语句执行时间全部变慢了，分析发现是没有及时的对于经常使用的相关表做 ，目前 TiDB 在 table 时，还是比较保守，只有三个系统参数：tio、、， TiDB 目前没有定时任务可以让触发 table 的操作。详见代码：/.go。
在这里，建议各位使用 TiDB 的同学在生产环境中一定要有自己的 table 机制。丰巢的做法是写了一个定时服务，每天定时调度支付平台 3 次，此服务支持分布式部署，可以接入多套 TiDB 集群，只要按照配置规则，即可完成指定集群指定表的 操作。
4.3 事务的执行结果与预期不一致
这个是支付业务在 TiDB 集群上并发冲突测试时发现的，这个也是 TiDB 的一个老生常谈的问题，主要原因是TiDB开启了显示事务的自动重试，大家可以通过查看系统变量： 的值来确定 。如果为 on，则表示 TiDB 集群关闭了显示的事务重试机制，目前 TiDB 3.0 版本对于这个值的默认值已经设置为 on 了。关于禁止显示事务重试的代码在 TiDB 的 /.go 中。
4.4 支付业务的定时任务执行失败
这个是使用 回放出来的问题。原因是，支付平台会定期的 某个表中的数据，因为 TiDB 中对于事务操作中的数据量有限制， 数据过多，导致失败。
上面的图来自于 TiDB 的官方文档，TiDB 因为是分布式数据库，所以对于大事务会有比较多的限制，从官方文档来看，我们批量语句是违背了第三或第四条规则。但是一开始实际测试的值与官方文档的值又不一致，我们实际测试 10 万条左右是一个临界值，单表大于 10 万条则删除失败，提示：“9500 - is too large”。为了搞清楚到底是 10 万还是 30 万，我们查阅了 TiDB 的源码，在 store/tikv/2pc.go 这个文件中找到了答案：
kv. 的默认值就是 30 万，并且这个值虽然是在 .go 中设置的，但是没有放开修改权限。我们又进行了一次测试，建了一个表，表的字段个数只有两个，并且都是 类型，最后证明事务中最大的处理行数就是 30 万条。我们之前的测试是因为违反了“键值对总大小不超过 100MB”这条规则。在使用批量插入和批量删除语句时，尽量将大事务变为多个小事务，上生产环境之前，还是要测试一下再实际使用。
5. 优化建议
5.1 任务调度机制
提这个建议主要是因为 table 的需要，上面我们也提到了之前由于 table 不及时，造成数据库的查询语句开始大量变慢的问题。为此我们还专门写了一个定时调度的服务，目前生产环境是每天执行 3 次相关表的 操作。但是写额外的服务，会存在下面几方面的问题：
5.2 回导机制
在反向同步这个领域内，TiDB 的 是支持目标数据库为 MySQL 的，但不支持目标数据库是多个 MySQL 的情况。虽然 DM 系列的组件已经很容易的便把已经分库分表的 MySQL 数据库聚合到了 TiDB 上，但是没有反向实时回导的功能。这个回导机制在刚刚切换的过程中是最后的保底手段，正如 做的事情。
6. 总结
TiDB 是一款非常棒的分布式关系数据库，它的社区活跃度、版本迭代速度、周边产品的完善程度等，都已经做的比较全面了，它在全球范围内有几百个 ，我们丰巢也几次对 TiDB 贡献了源码，后面我们会在内部培养更多的 。
这次我们选择支付平台来作为迁移到 TiDB 上的业务，就是想证明在丰巢所有的 OLTP 业务范畴内，我们是可以 All in TiDB 的。它对于丰巢的意义就在于，可以长期规划丰巢的数据库的选型和资源的投入，避免数据库产品使用的分裂和无效资源的投入。
在支付平台迁移的过程中，我们对于 TiDB 的使用和迁移工具都有了一定程度的积累，对于丰巢所有跑在 MySQL 上的业务，都有信心可以快速的迁移到 TiDB 上来。希望未来能有更多关于 TiDB 的知识和大家一起分享。
