分布式事务消息中心TMC

系统原理

     贷款和理财是51信用卡目前最主要的业务。金融相关的应用，往往对数据的一致性有着较高的要求，通常对DB的操作都是用事务来保障。但是在分布式的环境下，要保持事务的一致性从来都不是一件容易的事，传统通过两阶段、三阶段提交方式实现的XA事务由于代价太高，性能损失太大，在互联网公司中并不常用，而更常用的是实现最终一致性，即系统允许短暂的不一致，但是最终能达到一致的状态。

 

     51信用卡金融研发团队之前对跨微服务的调用就有一些方法，在执行业务逻辑前先插一张状态日志表，在执行成功后更新日志表里的状态，如果有中途失败的交易，后续也可以通过扫描日志表进行更正。TMC做的事就是业务里做的逻辑抽象独立出来，让业务专注于业务开发，无需再自己维护状态。下面简述其原理:

     两个事务运行在不同的进程上，为了平衡上下游系统压力差、削峰填谷都会使用MQ。但是直接使用MQ并不能实现分布式事务，下面举个例子说明:

     假设两个独立账务系统A和B，A要向B转100块钱，直接使用MQ的如下图所示:

 

 

     操作分四个步骤

1.    系统A更新DB，扣减100元

2.    publish一条消息进MQ

3.    MQ将消息发给系统B

4.    系统B更新DB，加100元

 

     分布式系统，任何一个环节都有可能失败，下面一一分析:

①   步骤1A更新DB前挂了，无影响，因为还没扣钱

②   更新DB后投进MQ前挂掉，消息丢了，100块不知道去哪了

③   A成功写进MQ，但是MQ这时候挂了，同样消息丢了

④   MQ成功投递给B，但是B写进DB之前B挂掉，同样100块不知道去哪了

⑤   B成功写进DB，B系统加100块，这种情况正常

 

     因此要实现分布式事务，就是要考虑消息在各个环节中都不丢，任一系统在挂掉的情况下，都能保证能够把消息找回来，并且流程还能够继续下去。

 

     下面开始介绍我们的实现方案，为了记录状态，我们引入了一个中间人，即TMC（TransactionMessage Center），示意如下图:

 

 

 

     现在的步骤如下：

1.    系统A publish一条消息给TMC

2.    TMC在DB