分布式架构之事务

1、概述

根据CAP（一致性、可用性、可靠性）的理论，鱼和熊掌不可兼得，P是必须要的，所以需要在C和A之间做平衡，实际上在互联网领域Ａ也是必须的，因此就不得不在Ｃ上做文章。于是有了弱一致或者最终一致，它不要求你在做完一个操作后能立马看到效果，只要在可接受的时间内看到正确的结果即可。解决分布式事务的思路就是避免分布式事务，具体来说就是利用本地事务+异步消息+重试+幂等去保证整个系统数据的最终一致性。
2、分类：①单服务操作多个数据库资源 ②服务调用服务再操作多数据源则出现跨服务且多数据源

3、常用处理模型：2阶段提交、3阶段提交、TCC（Try-Confirm-Cancel）、可靠消息（消息队列、数据库表）、SAGAS长事务、补偿性事务

4、2PC(Two Phase Commit，两阶段提交)：即事务提交过程分为两个阶段，2PC中只有协调者可以超时

     ① 准备阶段（TM发准备消息给每个RM，RM本地事务执行成功则返回成功，否则返回失败）

     ② 提交阶段（如果TM收到所有RM都回复成功，则发提交消息给每个RM，不然发回滚消息，RM则执行提交或者回滚本地事务操作，最后释放所有用到的锁资源）

 

• 存在的问题

     ① 同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态
     ② 单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
     ③ 数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象
     ④ 二阶段无法解决的问题：协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交

 

5、3PC（Three-phase commit三阶段提交）：是二阶段提交（2PC）的改进版本

     ① CanCommit阶段，协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应
     ② PreCommit阶段，协调者根据参与者的反应情况来决定是否可以继续事务的PreCommit操作。根据响应情况，假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行，假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断
     ③ doCommit阶段，该阶段进行真正的事务提交，要么执行提交，要么在这个阶段如果 参与者超时没有收到 commit命令或者 回滚命令则会在超时后自动 commit

• 比2PC的优势

    ① 引入超时机制。同时在协调者和参与者中都引入超时机制，在try和confirm过程中有节点超时无反馈则执行事务中断，但在最后阶段
    ② 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的

    ③ 在doCommit阶段，如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。（其实这个应该是基于概率来决定的，当进入第三阶段时，说明参与者在第二阶段已经收到了PreCommit请求，那么协调者产生PreCommit请求的前提条件是他在第二阶段开始之前，收到所有参与者的CanCommit响应都是Yes。（一旦参与者收到了PreCommit，意味他知道大家其实都同意修改了）所以，一句话概括就是，当进入第三阶段时，由于网络超时等原因，虽然参与者没有收到commit或者回滚响应，但是他有理由相信：成功提交的几率很大 ）。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的回滚响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到回滚命令并执行回滚的参与者之间存在数据不一致的情况

 

6、XA协议：作用于资源层，对于业务层无侵入，但因为事务过程独占数据，并发性能较差，如实现MVCC或乐观锁可能稍微好些

• DTP(Distributed Transaction Processing)模型分布式事务处理流程

① 应用程序（AP，Application）向 TM 申请开始一个全局事务
② 针对要操作的 RM，AP 会先向 TM 注册（TM 负责记录 AP 操作过哪些 RM，即分支事务）
③ TM 通过 XA 接口函数通知相应 RM 开启分布式事务的子事务
④ 接着 AP 就可以对该 RM 管理的资源进行操作
⑤ 当 AP 对所有 RM 操作完毕后，AP 根据执行情况通知 TM 提交或回滚该全局事务
⑥ TM 通过 XA 接口函数通知各 RM 完成操作
⑦ TM 会先要求各个 RM 做预提交，所有 RM 返回成功后，再要求各 RM 做正式提交，XA 协议要求，一旦 RM 预提交成功，则后续的正式提交也必须能成功；如果任意一个 RM 预提交失败，则 TM 通知各 RM 回滚
⑧ 所有 RM 提交或回滚完成后，全局事务结束

• 原子性：2PC(Two Phase Commit，两阶段提交)：即事务提交过程分为两个阶段
• 隔离性：保证每个子事务的隔离性，则分布式事务也隔离，如mysql的2PL(Two Phase Locking，两阶段锁即加锁和解锁)

• 一致性：一层是确保事务执行结束后，数据库从一个一致状态转变为另一个一致状态，这一层实现很简单，通过原子性、隔离性以及 RM 自身一致性的实现就可以保证。另一层语义是事务执行过程中的中间状态不能被观察到，子事务一致但不能保证分布式一致，除非用Serializable或者自己实现MVCC

 

7、TCC(Try-Confirm-Cancel)模型：也称补偿事务，不依赖资源，而是用业务逻辑分解

• 三大主角

① 主业务服务：主业务服务为整个业务活动的发起方，服务的编排者，负责发起并完成整个业务活动
② 从业务服务：从业务服务是整个业务活动的参与方，负责提供 TCC 业务操作，实现初步操作（Try）、确认操作（Confirm）、取消操作（Cancel）三个接口，供主业务服务调用
③ 业务活动管理器：业务活动管理器管理控制整个业务活动，包括记录维护 TCC 全局事务的事务状态和每个从业务服务的子事务状态，并在业务活动提交时调用所有从业务服务的 Confirm 操作，在业务活动取消时调用所有从业务服务的 Cancel 操作

• 事务流程

    ① 主业务服务首先开启本地事务； 
    ② 主业务服务向业务活动管理器申请启动分布式事务主业务活动； 
    ③ 然后针对要调用的从业务服务，主业务活动先向业务活动管理器注册从业务活动，然后调用从业务服务的 Try 接口；
    ④ 当所有从业务服务的 Try 接口调用成功，主业务服务提交本地事务；若调用失败，主业务服务回滚本地事务； 
    ⑤ 若主业务服务提交本地事务，则 TCC 模型分别调用所有从业务服务的 Confirm 接口；若主业务服务回滚本地事务，则分别调用 Cancel 接口；
    ⑥ 所有从业务服务的 Confirm 或 Cancel 操作完成后，全局事务结束。

• 原子性：应用层2PC（try-prepare，confirm-commit，cancel-rollback）
• 隔离性：通过业务的改造，在第一阶段结束之后，从底层数据库资源层面的加锁过渡为上层业务层面的加锁，从而释放底层数据库锁资源，放宽分布式事务锁协议，提高业务并发性能，如下面的例子

• 一致性：第一层与 XA 协议实现一致性第一层语义类似，通过原子性保证事务的原子提交、业务隔离性控制事务的并发访问，实现分布式事务的一致性状态转变。第二层事务的中间状态不能被观察到，BASE原则