好又贷-分布式系统事务一致性解决方案

执行数据库回滚

跨行转账结束

执行出款

失败

第二阶段执行本地事物

跨行转账开始

执行投递消息

成功

是否成功

检查本地消息表

入款处理

MQ（非事务消息）性能和吞吐量是优于使用关系型数据库消息表的方案。如果MQ自身和业务都具有高可用性，理论上是可以满足大部分的业务场景的。不过在没有充分测试的情况下，不建议在交易业务中直接使用。

已消费

MQ（事务消息）各大知名的电商平台和互联网公司，几乎都是采用类似的设计思路来实现“最终一致性”的。这种方式适合的业务场景广泛，而且比较可靠。不过这种方式技术实现的难度比较大。目前主流的开源MQ（ActiveMQ、RabbitMQ、Kafka）均未实现对事务消息的支持，所以需二次开发或者新造轮子。比较遗憾的是，RocketMQ事务消息部分的代码也并未开源，需要自己去实现。

执行出款操作数据库

第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。

确认消息是否成功

出款

执行入款

出款凭证插入本地消息表

出款-本地事务

通知入款

RocketMQ第一阶段发送Prepared消息时，会拿到消息的地址

RocketMQ会定期扫描消息集群中的事物消息，这时候发现了Prepared消息，它会向消息发送者确认，钱到底是减了还是没减呢？如果减了是回滚还是继续发送确认消息呢？RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。

本地消息表关系型数据库的吞吐量和性能方面存在瓶颈，频繁的读写消息会给数据库造成压力。所以，在真正的高并发场景下，该方案也会有瓶颈和限制的。

入款-本地事务

未消费