分布式事务解决方案

一、最终一致性（业务方自己实现）

 

系统A：

1.系统A增加消息表

2.系统A准备一个后台程序，读取消息表的发送失败消息，不断重试

 

系统B：

1.增加判重表，记录处理成功的消息ID和消息中间件对应的offset

 

优点：保证消息不丢失、不重复，实现系统A和B的最终一致性

缺点：增加了表和后台任务，增加开发负担

 

 

 

 

 

 

二、事务状态表+调用方重试+接收方幂等

 

1.调用方维护一张事务状态表，每次调用前落盘一条事务流水

2.后台任务，扫描状态表，根据状态来判断是否重新调用

3.后台任务重试多次仍然不成功，就为状态表加一个error状态，通过人工介入干预

4.系统ABC根据全局的事务ID做幂等操作

 

 

 

 

三、对账

 

最终一致性、tcc、事务状态表，这些方法都太重，一个简单的方法是对账

 

全量对账：定时任务，对比两个数据库

增量对账：

定时任务

基于消息中间件：每一次业务操作都抛出消息到消息中间件

 

 

 

 

 

四、妥协方案：弱一致性+基于状态的补偿

既要满足高并发、又要达到一致性，鱼和熊掌不可兼得。

可以利用业务的特性，采用一种弱一致的方案。

 

 

方案1: 先扣库存，后创建订单

方案2:先创建订单，后扣库存

 

数据不一致，如何补偿？

库存系统每扣一次，就生成一条流水记录，初识状态是“占用”，等订单支付成功，把状态改成"释放"

通过比对 库存系统的"占用又没有释放的库存流水" 与 订单系统的未支付的订单

就可以回收这些库存，同时把对应订单取消

 

 

 

 

五、妥协方案：重试+回滚+报警+人工修复

 

根据上面的方案1

先扣库存，后创建订单，如果订单创建失败，重试，重试不成功，就回滚库存的扣减，回滚也失败，就发报警进行人工干预修复。

只要日志流水记录的完整，人工肯定可以修复。

这种办法虽然很丑陋但是很实用。