分布式(二) -- 分布式事务
本文参考什么是分布式事务，分布式事务的四种解决方案，分布式一致性，关于分布式事务，XA协议的学习笔记
分布式事务是什么
我们知道数据库事务就是一组数据库操作序列。所以事务我们可以理解成是一组逻辑单元执行的操作，要么全成功，要么全失败。但是目前我们一般讲事务也都是单机数据库事务，有着ACID的特性，而我们现在服务基本都是多集群配置的分布式服务了，那么分布式事务是啥？
分布式事务可以理解成在分布式系统中保证不同节点数据一致性，提到分布式事务就不得不提XA分布式事务协议了，包含2PC（两阶段提交）和3PC（三阶段提交）两种实现。并且除了事务执行者（执行事务的机器）外需要增加一个事务协调者（进行协调执行的机器）进行协调。那我们就以分布式集群上Mysql数据为例讲解一下。
2PC
两阶段提交包含了Prepare阶段和Commit/RollBack阶段。我们分别看下两阶段的过程。
-
Prepare（准备阶段）
1：首先事务协调者发送事务内容给到所有事务执行者并等待执行者回复。:
2：事务执行者收到事务内容开始操作事务，并将讲 undo 和 redo 信息记入事务日志中，但是此时并不提交事务。
3：事务执行者将自己的事务执行情况报告给事务协调者，不管成功或者失败。 -
Commit/RollBack（提交或回滚阶段）
1： 如果协调者收到都是执行者执行成功的消息，那么协调者会发送一个Commit的信息给到所有执行者，否则发送Rollback的信息给所有执行者。
2：执行者根据协调者的指令进行提交或者回滚，结束后释放所有事务处理过程中使用的锁资源。
3：事务执行者将自己的事务执行情况报告给事务协调者，协调者完成事务中断。
-
总结
2PC的问题：
1：首先存在性能问题，所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。
2：协调者存在单点故障问题。
3：数据一致性问题：在阶段 2 中，如果发生局部网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，那么就导致了节点之间数据的不一致。
3PC
三阶段提交是在二阶段提交上的加入了超时机制，同时在协调者和参与者中都引入超时机制。并且将二阶段的准备阶段拆分为2个阶段，插入了一个preCommit阶段，以此来处理原先二阶段，参与者准备后，参与者发生崩溃或错误，导致参与者无法知晓是否提交或回滚的不确定状态所引起的延时问题。
-
CanCommit
1：协调者向所有执行者发送包含事务内容的 canCommit 请求并等待所有参与者答复。
2：执行者收到 canCommit 请求后，如果认为可以执行事务操作，则反馈 yes 并进入预备状态，否则反馈 no。 -
PreCommit
1：协调者向所有执行者发出 preCommit 请求，进入准备阶段。
2：执行者收到 preCommit 请求后开始执行事务操作并将 undo 和 redo 信息记入事务日志中，但不提交事务。
3：事务执行者将自己的事务执行情况报告给事务协调者包括超时情况，并等待最终指令。 -
DoCommit
如果协调者正常工作就同2PC的第二执行阶段。如果协调者出现问题，执行者会自行回滚并中断事务。 -
总结：
优点：
1：提高性能，三阶段提交降低了阻塞范围，在等待超时后协调者或参与者会中断事务。
2：避免了协调者单点问题，DoCommit中协调者出现问题时，参与者会继续提交事务。
缺点：
1：数据不一致问题依然存在，当在参与者收到 preCommit 请求后等待 do commite 指令时，此时如果协调者请求中断事务，而协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。
优化方案
-
TCC事务
TCC 是服务化的二阶段编程模型，其 Try、Confirm、Cancel 3 个方法均由业务编码实现：
1：Try 操作作为一阶段，负责资源的检查和预留。
2：Confirm 操作作为二阶段提交操作，执行真正的业务。
3：Cancel 是预留资源的取消。
优点：
1：性能提升：具体业务来实现控制资源锁的粒度变小，不会锁定整个资源。
2：数据最终一致性：基于 Confirm 和 Cancel 的幂等性，保证事务最终完成确认或者取消，保证数据的一致性。:
3：可靠性：解决了 XA 协议的协调者单点故障问题，由主业务方发起并控制整个业务活动，业务活动管理器也变成多点，引入集群。
缺点：
1：TCC 的 Try、Confirm 和 Cancel 操作功能要按具体业务来实现，业务耦合度较高，提高了开发成本。
总结：
当然看参考文章还有MQ事务，Saga事务等优化方案，暂时还未理解，后面会继续学习并丰富一下，首先先整理一下分布式事务的简单理解。
