分布式事务解决方案

一、2PC（二阶段提交）

两阶段协议将分布式事务分为两部分：准备阶段和提交阶段，包含两种角色：事务管理器（协调者 可以理解为jvm或网站等发起者）和资源管理器（参与者 可以理解为数据库），准备和提交阶段均由事务管理器发起。图片来源

事务提交：

事务回滚：

如图所示，第一阶段事务管理器向各个数据库发送预提交请求询问其是否满足执行事务的条件，如果满足条件资源管理器则发出就绪回复并锁定资源（执行事务），这个阶段做了除提交事务外的所有事情。
如果所有资源管理器都满足执行条件（执行成功），则事务管理器发出提交命令。
如果存在资源管理器不满足条件（执行失败），事务管理器命令其他资源管理器回滚，释放资源。

缺陷：
性能问题：在资源管理器锁定资源过程中，各个资源管理器节点处于阻塞状态，要等待所有资源管理器回应且事务管理器提交命令才会释放资源。

丢失数据（脑裂）：如果事务管理器发出的提交命令由于网络波动等原因部分资源管理器未收到，则会存在数据不一致。

易故障：一旦事务管理器发生故障，事务执行到一阶段后，事务管理器挂了，资源管理器将无法进行处理，资源可能一直被占用。

二、3PC（三阶段提交）

三阶段提交是对二阶段提交的改进，引入超时机制并将2PC中的第一阶段分为两个部分：询问阶段和准备阶段。
询问阶段：事务管理器向资源管理器询问是否满足执行条件，资源管理器只需回答是否并不执行事务等操作。如果在询问阶段任意参与者返回不能执行操作的结果，则事务管理器向资源管理器发送中止,请求若超时则也终止。
准备阶段: 如果在询问阶段所有参与者都返回可以执行操作，则协调者向参与者发送预执行请求，
然后参与者写redo和undo日志，执行事务操作但是不提交操作；如果在询问阶段任意参与者返回不能
执行操作的结果，则协调者向参与者发送中止请求。
提交阶段：和2PC相同。也有超时，一旦超时，则协调者和参与者都会继续提交事务，默认为成功，这也是根据概率统计超时后默认为成功的正确性最大。

缺陷：只是极大概率避免了数据不一致的可能性，还是可能出现超时导致数据不一致。

三、TCC

TCC (try-confirm/cancel):基于补偿的事务。其核心思想是：“针对每个操作都要注册一个与其对应的确认和补偿（撤销操作）”，即每个参与者都有 try confirm cancel 接口。
TCC事务机制相对于传统事务机制（X/Open XA Two-Phase-Commit），其特征在于它不依赖资源管理器(RM)对XA的支持，而是通过对（由业务系统提供的）业务逻辑的调度来实现分布式事务。
TCC类似于两阶段提交，不过每一个阶段都是独立完整的事务，都会改变数据（个人理解是强入侵的基于第三方应用来协调）。

四、本地事务表

消息生产方（也就是发起方），需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。

消息消费方（也就是发起方的依赖方），需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。
生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。

五、MQ

基于可靠消息的食物，虽有短时间不一致但能保证最终一致性，失败可以自动重试。
基于RocketMQ的事务：
半消息：暂不能投递的消息，发送方已经将消息成功发送到了 MQ 服务端，当Broker收到此类消息后，会存储到RMQ_SYS_TRANS_HALF_TOPIC的消息消费队列中，它暂时不会被Consumer消费，处于该种状态下的消息即半消息。
半消息回查：由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，MQ 服务端通过扫描发现某条消息长期处于“半消息”时，需要主动向消息生产者询问该消息的最终状态（Commit 或是 Rollback），该过程即消息回查。
流程：

1.发送方向 MQ 服务端发送事务消息；

2.MQ Server 将消息持久化成功之后，向发送方 ACK 确认消息已经发送成功，此时消息为半消息。

3.发送方开始执行本地事务逻辑。

4.发送方根据本地事务执行结果向 MQ Server 提交二次确认（Commit 或是 Rollback），MQ Server 收到 Commit 状态则将半消息标记为可投递，订阅方最终将收到该消息；MQ Server 收到 Rollback 状态则删除半消息，订阅方将不会接受该消息。

5.在断网或者是应用重启的特殊情况下，上述步骤4提交的二次确认最终未到达 MQ Server，经过固定时间后 MQ Server 将对该消息发起消息回查。

6.发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果。

7.发送方根据检查得到的本地事务的最终状态再次提交二次确认，MQ Server 仍按照步骤4对半消息进行操作。

六、Saga

其核心思想是将长事务拆分为多个本地短事务，由Saga事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。图片来源