分布式事务-理论篇

分布式事务是什么

分布式事务指事务的操作位于不同的节点上，因此需要服务与服务之间远程协作才能完成事务操作，这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务，主要是指一个事务包含的多个跨服务的webservice。

分布式事务理论-CAP&BASE

CAP

• Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。
• Availability（可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝，即使是有不健康的节点，其他健康的节点也要响应。
• Partition tolerance （分区容错性）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区，在集群出现分区时，整个系统也要持续对外提供服务。

BASE

BASE可以说是对可用性和强一致性的一种中和软化。

• Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
• Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
• Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

分布式事务处理方案

XA协议包含两阶段提交（2PC）

第一阶段

在XA分布式事务的第一阶段，作为事务协调者的节点会首先向所有的参与者节点发送Prepare请求。

在接到Prepare请求之后，每一个参与者节点会各自执行与事务有关的数据更新，写入Undo Log和Redo Log。如果参与者执行成功，暂时不提交事务，而是向事务协调节点返回“完成”消息。

当事务协调者接到了所有参与者的返回消息，整个分布式事务将会进入第二阶段。

第二阶段

在XA分布式事务的第二阶段，如果事务协调节点在之前所收到都是正向返回，那么它将会向所有事务参与者发出Commit请求。

接到Commit请求之后，事务参与者节点会各自进行本地的事务提交，并释放锁资源。当本地事务完成提交后，将会向事务协调者返回“完成”消息。

当事务协调者接收到所有事务参与者的“完成”反馈，整个分布式事务完成。

补充 三阶段提交（3PC）两种实现：在第一步多加了一个CanCommit阶段，先询问是否都有条件进行提交，返回确认后才进行上边的两步提交步骤，加了一个超时时间，如果部分参与者在commit阶段一定时间没收到协调者的commit，会进行自动的本地提交。

劣势

1. 单点故障： 事务协调者是整个XA模型的核心，一旦事务协调者节点挂掉，参与者收不到提交或是回滚通知，参与者会一直无法完成事务。
2. 丢失消息导致的不一致问题： 第二个阶段，如果发生局部网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，那么就导致了节点之间数据的不一致。3pc解决了这个问题
3. 性能问题： 如果多个参与者，部分完成，部分没完成，要等未完成的完成之后才可提交，所以性能有一定的影响。

Seata的两步解决方案

TCC解决方案

1. Try： Try阶段一般用于锁定某个资源，设置一个预备状态或冻结部分数据。

2. Confirm： 根据Try阶段的执行情况，Confirm分为两种情况： 理想情况下，所有Try全部执行成功，则执行各个服务的Confirm逻辑；如果confirm执行失败，重试，人工介入，默认是一定执行成功的。 部分服务Try执行失败，则执行第三阶段——Cancel。

3. Cancel 如果Try阶段执行异常，就会执行Cancel阶段，这个阶段的执行是为了把try阶段的锁定的资源释放掉。默认也是执行成功，不成功人工介入。

MQ消息队列保证最终一致性

推荐文章

面试题：Redis为什么是单线程？看了这个视频通透了

面试官：小伙子来说一下拥塞控制

面试官：秒杀系统解决方案了解过吗

面试官:JMM特性说一下？

面试官：小伙子，分布式数据库ID解决方案了解吗？