数据库，交易系统中最核心依赖，数据持久化属于最核心服务。
随着互联网的普及，大流量高并发的场景越来越多，7*24的交易系统对高可用要求越来越高，同时在“数据为王”大环境下，交易数据最终通过数据库进行持久化存储，数据库成为整个系统最终重要服务，不能出一点问题，尤其核心P0系统哪怕瞬间的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消息无丢失。
数据库的连接数是宝贵且有限，凡是连接数据库的系统，不可能无限进行机器扩容支持流量的增长，同时数据库支持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操作转换为逐笔流水数据的持久化操作，再异步消费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操作切换到创建流水数据的操作；
以上数据库弱依赖的技术方案更适用于数据偏流水式的交易系统，随技术迭代和业务发展，技术方案也层出不穷并不断迭代创新，欢迎大家跟我们研发团队交流沟通，共同进步。