事务实现原理

两阶段提交（Two-phaseCommit）

两阶段提交主要保证了分布式事务的原子性:即所有结点要么全做要么全不做，所谓的两个阶段是指:第一阶段:准备阶段;第二阶段:提交阶段。将提交分成两阶段进行的目的很明确，就是尽可能晚地提交事务，让事务在提交前尽可能地完成 所有能完成的工作。

1 准备阶段

事务协调者(事务管理器)给每个参与者(资源管理器)发送 Prepare 消息，每个参与者要么直接返回 失败(如权限验证失败)，要么在本地执行事务，写本地的 redo 和 undo 日志，但不提交，到达一 种“万事俱备，只欠东风”的状态。

2 􏰀交阶段:

如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息;否则， 发送提交(Commit)消息;参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过 程中使用的锁资源。(注意:必须在最后阶段释放锁资源)

两阶段事务的缺点

• 执行过程中，所有参与节点都是事务阻塞型的。
• 单点故障，由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。
• 数据不一致(脑裂问题)，在二阶段提交的阶段二中，当协调者向参与者发送 commit 请求之后，发生了局部网络异 常或者在发送 commit 请求过程中协调者发生了故障，导致只有一部分参与者接受到了 commit 请求。于是整个分布式系统便出现了数据部一致性的现象(脑裂现象)。

二阶段无法解决的问题(数据状态不确定)，协调者再发出 commit 消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

三阶段提交(Three-phase commit)

与两阶段提交不同的是，三阶段提交有两个改动点。

• 引入超时机制。同时在协调者和参与者中都引入超时机制。
• 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。也就是说，除了引入超时机制之外，3PC 把 2PC 的准备阶段再次一分为二，这样三阶段 提交就有 CanCommit、PreCommit、DoCommit 三个阶段。

1. CanCommit阶段：协调者向参与者发送 commit 请求，参与者如果可以提交就返回 Yes 响应，否则返回 No 响应。
2. PreCommit阶段：协调者根据参与者的反应情况来决定是否可以继续进行，有以下两种可能。假如协调者从所有的 参与者获得的反馈都是 Yes 响应，那么就会执行事务的预执行假如有任何一个参与者向协调者发送 了 No 响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。
3. doCommit阶段：该阶段进行真正的事务提交，主要包含 1.协调这发送提交请求 2.参与者提交事务 3.参与者响应反馈( 事务提交完之后，向协调者发送 Ack 响应。)4.协调者确定完成事务。

事务类型

强一致性

Java 事务编程接口(JTA:Java Transaction API)和 Java 事务服务 (JTS;Java Transaction Service) 为 J2EE 平台提供了分布式事务服务和XA协议。分布式事务(Distributed Transaction)包括事务 管理器(Transaction Manager)和一个或多个支持 XA 协议的资源管理器 ( Resource Manager )。我们可以将资源管理器看做任意类型的持久化数据存储;事务管理器承担着所有事务 参与单元的协调与控制。这里的一个重点是需要一个协调者来协调各个资源，例子实现如下：

public void transferAccount() {
    UserTransaction userTx = null;
    Connection connA = null;
    Statement stmtA = null;
    Connection connB = null;
    Statement stmtB = null;
    try {
        // 获得 Transaction 管理对象
        userTx = (UserTransaction) getContext().lookup("java:comp/UserTransaction");
        connA = getDataSourceA().getConnection();// 从数据库 A 中取得数据库连接 connB = getDataSourceB().getConnection();// 从数据库 B 中取得数据库连接
        userTx.begin(); // 启动事务
        stmtA = connA.createStatement();// 将 A 账户中的金额减少 500
        stmtA.execute("update t_account set amount = amount - 500 where account_id = 'A'"); // 将 B 账户中的金额增加 500
        stmtB = connB.createStatement();
        13 / 04 / 2018 Page 135 of 283
        stmtB.execute("update t_account set amount = amount + 500 where account_id = 'B'");
        userTx.commit();// 提交事务
        // 事务提交:转账的两步操作同时成功(数据库 A 和数据库 B 中的数据被同时更新) } catch(SQLException sqle){
    } catch (SQLException sqle) {
        // 发生异常，回滚在本事务中的操纵
        userTx.rollback();// 事务回滚:数据库 A 和数据库 B 中的数据更新被同时撤销
    } catch (Exception ne) {
        
    }
}

柔性事务

在分布式领域基于 CAP 理论以及 BASE 理论，有人就提出了 柔性事务 的概念。CAP(一致性、可用性、分 区容忍性)理论大家都理解很多次了，这里不再叙述。说一下 BASE 理论，它是在 CAP 理论的基 础之上的延伸。包括 基本可用(Basically Available)、柔性状态(Soft State)、最终一致性 (Eventual Consistency)。通常所说的柔性事务分为:

• 两阶段型：应技术上的 XA、JTA/JTS。这是分布式环境下事务处理的 典型模式
• 补偿型：(Try/Confirm/Cancel)，一种基于补偿的 long-running 的事务处理模型，这样的 SAGA 事务模型，是牺牲了一定的隔离性和一致性的，但是 提高了 long-running 事务的可用性
• 异步确保型：通过将一系列同步的事务操作变为基于消息执行的异步操作, 避免了分布式事务中的同步 阻塞操作的影响
• 最大努力通知型：这是分布式事务中要求最低的一种, 也可以通过消息中间件实现, 与前面异步确保型操作不 同的一点是, 在消息由 MQ Server 投递到消费者之后, 允许在达到最大重试次数之后正常 结束事务。