最常见分布式事务解决方案.docx

这六种目前最常见分布式事务解决方案
 
   
 
 
 
 
 
 
 
     
 
 
 
 
一、分布式事务
分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
以商品流水账单为例，我们拆分为商品购买系统，订单系统，支付系统。
用户看中一件商品，点击购买。
商品购买系统响应用户的点击，向订单系统插入一条订单信息。
跳转到支付系统完成支付。
在用户整个购买商品的过程中，我们需要保证事件1，2，3在没有异常的情况下全部执行成功，一旦某个系统抛出异常，都需要回滚。
那么，如何保证各个子系统的操作具有一致性呢？这就是我们下面提到的分布式事务的解决方案。
在这里，文章中没有提到分布式一致性协议，下面简单列举一下，有兴趣的读者可以参考其他详细资料：
两阶段提交协议
三阶段提交协议
Paxos协议
Raft协议
二、分布式事务的解决方案

该方案基于两阶段提交协议，因此也叫做两阶段提交方案。在该分布式系统中，其中 需要一个系统担任协调器的角色，其他系统担任参与者的角色。主要分为Commit-request阶段和Commit阶段
请求阶段：首先协调器会向所有的参与者发送准备提交或者取消提交的请求，然后会收集参与者的决策。
提交阶段：协调者会收集所有参与者的决策信息，当且仅当所有的参与者向协调器发送确认消息时协调器才会提交请求，否则执行回滚或者取消请求。
该方案的缺陷：
同步阻塞：所有的参与者都是事务同步阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
单点故障：一旦协调器发生故障，系统不可用。
数据不一致：当协调器发送commit之后，有的参与者收到commit消息，事务执行成功，有的没有收到，处于阻塞状态，这段时间会产生数据不一致性。
不确定性：当协调器发送commit之后，并且此时只有一个参与者收到了commit，那么当该参与者与协调器同时宕机之后，重新选举的协调器无法确定该条消息是否提交成功。
XA方案的实现方式可以使用Spring+JTA来实现，可以参考文章：Springboot+atomikos+jta实现分布式事务统一管理

TCC方案分为Try Confirm Cancel三个阶段，属于补偿性分布式事务。
Try：尝试待执行的业务
这个过程并未执行业务，只是完成所有业务的一致性检查，并预留好执行所需的全部资源
Confirm：执行业务
这个过程真正开始执行业务，由于Try阶段已经完成了一致性检查，因此本过程直接执行，而不做任何检查。并且在执行的过程中，会使用到Try阶段预留的业务资源。
Cancel：取消执行的业务
若业务执行失败，则进入Cancel阶段，它会释放所有占用的业务资源，并回滚Confirm阶段执行的操作。
以一个电商系统用户购买商品的流水线为例。
T