分布式事务

目前，业内解决分布式事务问题，主要采用如下两套方案：

• 基于TCC的事务框架

概念：TCC的全称是（Try-Confirm-Cancel）。TCC又可以被称为两阶段补偿事务，第一阶段try只是预留资源，第二阶段要明确的告诉服务提供者，这个资源你到底要不要，对应第二阶段的confirm/cancel，用来清除第一阶段的影响，所以叫补偿型事务。

缺点：对代码的侵入性很大。每套业务逻辑都要按try（请求资源）、confirm（操作资源）、cancel（取消资源），拆分为三个接口。

• 消息队列

一致性：额外增加一张事件表，再起一个定时程序扫描事件表，发现一个状态为'UNFINISHED'的事件，就进行封装为消息，发送到消息中间件，然后将状态改为'FINISHED'。

幂等性：在消费者端，也维护一个带主键的表，一旦出现重复消费，则在事务里直接报出主键冲突错误，从而保证了幂等性。

关于两种方案的选型，如果是同步调用A服务、B服务，要么一起成功、要么一起失败，这时候就应该选择TCC事务框架，如果是异步调用，即调用A服务后，不管B服务的执行结果就直接返回，采用消息队列更适合。
具体可参考下面两篇博客：
利用消息队列处理分布式事务
分布式事务之TCC事务模型