作者：京东科技 杜晓玉

前言

数据库，交易系统中最核心依赖，数据持久化属于最核心服务。

随着互联网的普及，大流量高并发的场景越来越多，7*24 的交易系统对高可用要求越来越高，同时在“数据为王”大环境下，交易数据最终通过数据库进行持久化存储，数据库成为整个系统最终重要服务，不能出一点问题，尤其核心 P0 系统哪怕瞬间的 DB 操作异常可能造成大量异常交易，可能产生致命的问题，所以核心系统弱依赖数据库都是必须考虑的。

数据库弱依赖的整体思路：将最可靠链路再增加上备用链路替换，解决方案主要通过其他存储介质+补偿机制替换同步的 DB 操作，预期效果：数据库出现故障期间也能保证系统运行正常不影响线上业务开展。

本期介绍下实践过的三种解决方案：DB 灾备机制方案、DB 高并发替换方案、财富系统弱依赖 DB 方案。

一、DB 灾备机制方案

日常引发数据库操作出现异常的常见情况：网络链路异常、执行工单导致数据库性能下降、慢 SQL 导致数据库异常等，并且从发现问题到解决往往时间不短，尤其核心交易链路都已无法容忍短时间的异常故障，所以首先考虑增加灾备机制，出现异常时间段内也要保证交易成功率，哪怕可以损失一点性能要求。DB 灾备机制方案是 2016 年接触到并实施第一版弱依赖数据库方案。方案主要思路：DB 操作故障时间段内，通过其他存储介质临时存储数据，并通过 MQ 异步补偿还原 DB 操作，达到最终数据一致性。

图 1 DB 灾备流程

具体改造点：

1.DB 操作增加灾备处理逻辑，出现异常时将数据存储到缓存，并发送 MQ，再通过消费 MQ 异步还原 DB 数据操作；

2.数据查询链路，必须支持先查缓存再查数据库，并且减少外部查询请求；

3.数据库的 DB 操作性能非常好（毫秒级），灾备处理链路同步操作入缓存+MQ 发送，整体性能耗时变高了，需合理设置 MQ 发送超时时间，当时接入团队内部 MQSender 组件，处理发送失败后异步自动重发，提升灾备处理链路的成功率，同时保障了 MQ 消息无丢失。

二、DB 高并发替换方案

数据库的连接数是宝贵且有限，凡是连接数据库的系统，不可能无限进行机器扩容支持流量的增长，同时数据库支持 TPS 也是有上限，例如 Mysql5.6.x 版本建议最大 500~1000 之间，尤其对高性能和高并发的系统来说，在高要求的性能指标下，数据库吞吐量成为支撑大流量的瓶颈，如果通过增加数据库服务器，成本往往也是无法承担。

2018 年有幸参与到 P0 核心交易系统的高可用升级项目，目标将交易系统 tps 提升至 2w 以上，当时 20 台数据库物理机（单机单实例，Mysql 版本 5.6.x），在高性能指标要求下，系统压测 tps 峰值最高可达到 1~1.5w。为达成目标，同时考虑资源成本，项目升级改造方案思路：通过缓存+MQ 组合将数据库操作完全异步化，同时利用 MQ 消费批量拉取策略，批量拉取数据进行 DB 批量操作，减少数据库操作次数提升效率。中间件选择上充分利用缓存组件的高性能、高吞吐、支持连接数更大的优势，保证了高性能同时也解决应用扩容问题。

同时考虑到 MQ 平台上部署其他应用 topic 影响发送性能，搭建单独独享 MQ 集群，保证 MQ 发送的性能要求，多次大促期间 MQ 发送耗时 tp999 都小于 50ms。中间件达到高性能要求后，将 DB 操作替换成同步入缓存+发送 MQ，提升交易链路吞吐量，压测结果也达到 tps>2w+目标。

图 2 DB 高并发替换

具体改造点：

1.交易链路中 DB 操作全为 insert，无 update，满足了异步化后 DB 操作可进行批处理；

2.搭建单独 MQ 平台，保证了 MQ 发送性能，同时接入团队内部 MQSender 组件，处理发送失败的异步自动重发，保证整体链路的成功率；

3.缓存组件，本身具备高吞吐量并且可快速扩容，异步化后交易链路吞吐量大幅提升。同时缓存接入 R2M、JIMDB 双缓存，针对不同机房设置主从操作，例如金融机房同步主操作 R2M，异步操作 JIMDB，性能最优。双缓存机制防止单个缓存组件出现故障后可快速切换，保证整体链路成功率；

4.异步化后通过 MQ 消费还原 DB 操作，通过合理设置 MQ 拉取策略，批量进行 DB 操作，减少 DB 操作提升效率；同时增加异步化延迟的 UMP 监控，监控从交易发起到异步入库完整链路耗时，可直观异步化后 MQ 消费能力，便于动态调整；

5.减少外部系统的查询诉求，统一以交易完成消息进行触达扭转，必要查询请求全部查缓存，上游要具备查询异常时重试机制。

三、财富系统弱依赖 DB 方案

财富交易系统参考以上两版方案，并结合自身交易场景多、交易链路长、数据状态多情况。基于此设计出一版以流水数据驱动交易数据扭转的方案，大概思路：交易链路少变动，交易数据的 DB 操作不变动，增加中转层将交易链路 DB 操作转换为逐笔流水数据的持久化操作，再异步消费 MQ 还原交易数据的 DB 操作，通过将新增中转层做到弱依赖 DB，达到整个交易链路弱依赖 DB。结合系统的流量现状，查询流量大交易流量 TPS 未达上万，当下主要目标加强交易链路的健壮性。

流水数据持久化的操作：并行执行 DB 入库、入缓存，二者其一操作成功则直接返回成功，并异步发送补偿操作的 MQ，如果 DB 出现故障期间缓存操作正常也可保证系统运行正常，不影响线上业务开展。例如消费场景的弱依赖 DB 改造，正常收到交易请求后，首先业务校验+防重幂等>创建订单>扣减用户份额>更新订单状态，将创建订单、更新订单状态的操作改造为创建两笔流水数据的操作，交易链路不进行大的改造前提下，通过将流水数据持久化做到弱依赖 DB，这样交易过程中即使 DB 出现故障时只要缓存组件正常运行即可保障消费交易正常完成，再通过异步消费 MQ 还原创建订单、更新订单的操作。方案落地后得到了很好的验证，曾经历过数据库因执行大的变更工单导致数据库出现性能故障，消费交易链路不受影响，保证业务正常运行和用户体验。

图 3 财富系统弱依赖 DB 方案

具体改造点：

1.中转层流水数据持久化核心操作：并行执行 DB 的 insert 操作、入缓存，二者其一操作成功则直接返回成功，并异步发送补偿操作的 MQ；

2.消费 MQ 异步还原交易库的 DB 操作时，通过数据中状态位保证 MQ 消费的顺序执行；

3.流水库和缓存的双向同步，如果流水库或缓存出现故障时，异步进行相互补偿存储，目前流水库存储全量流水数据。

4.交易链路主要改造两点：一、防重幂等以流水数据为准，流水数据查询是合并缓存和 DB 数据后返回；二、交易数据调用 DB 操作切换到创建流水数据的操作；

总结

以上数据库弱依赖的技术方案更适用于数据偏流水式的交易系统，随技术迭代和业务发展，技术方案也层出不穷并不断迭代创新，欢迎大家跟我们研发团队交流沟通，共同进步。