1. 分布式事务协议

Two/Three Phase Commit

1.1 两阶段提交协议：2PC

2PC 成立假设

1. 存在一个节点为协调者（Coordinator），其他节点为参与者（Cohorts），节点间可以进行通讯
2. 所有节点都预写日志，且日志被写入后即保持在可靠的存储设备上，即使节点损坏也不会导致日志消失
3. 所有节点不会永久性损坏，即使损坏后仍然可以恢复

2PC 流程（阶段）

• 第一阶段：投票阶段
  1. Coordinator 询问所有 Cohorts 是否可以执行 提交操作（vote），并等待所有 Cohorts 响应
  2. Cohorts 询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。（注意：若成功这里其实每个参与者已经执行了事务操作）
  3. 所有Cohorts响应 Coordinator 发起的询问。如果 Cohorts的事务实际执行成功，则它返回一个 “同意” 消息；如果执行失败，则它返回一个 “中止” 消息
• 第二阶段：提交执行阶段
  • 所有Cohorts在第一阶段响应响应为**“同意”**时：
    1. Coordinator 向所有Cohorts发出 正式提交（commit） 的请求
    2. Cohorts 正式完成操作，并释放在整个事务期间内占用的资源
    3. Cohorts 向 Coordinator 发送 “完成” 消息
    4. Coordinator 接收所有 Cohorts反馈的 “完成” 消息后，完成事务
  • 任意Cohorts在第一阶段响应为 “中止” 时：
  • Coordinator 在第一阶段询问超时前无法获取所有Cohorts的响应消息时：
    1. Coordinator 向所有参与者发出 回滚操作（rollback） 的请求
    2. Cohorts 利用之前写入的 undo 信息执行回滚，并释放占用的资源
    3. Cohorts 向 Coordinator 发出 回滚完成 消息
    4. Coordinator 收到所有 Cohorts 节点反馈的 回滚完成 消息后，取消事务。
  • 不管最终结果如何，第二阶段都会结束当前事务

2PC 的缺点

1. 执行过程中，所有参与节点都是事务阻塞型。当节点占用公共资源时，其他任务不可用
2. Cohorts 故障，Coordinator 只能等待超时失败，没有其他容错机制
3. Coordinator 发生故障，Cohorts会一直阻塞
4. 2PC无法解决的问题：Coordinator 发出 commit 消息后宕机，而唯一接受到这消息的 Cohorts 也宕机，这样即使通过选举重新指定 Coordinator 后，也无法确定事务的状态

1.2 三阶段提交协议：3PC

与2PC的差异

• 引入超时机制。同时在协调者和参与者中都引入超时机制。
• 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

3PC 的三个阶段

三个阶段提交有 CanCommit、PreCommit、DoCommit 三个阶段。

1. CanCommit 阶段

1. 事务询问：Coordinator 向所有 Cohorts 发送 CanCommit 请求，并等待响应
2. 响应反馈：Cohorts 接收到 CanCommit 请求后，如果认为自身可以顺利执行事务，则返回 YES 响应，否则返回 NO

2. PreCommit 阶段

• 如果所有 Cohorts 均反馈为 YES 这执行 PreCommit 阶段：
  1. 发送预提交请求：Coordinator 向所有 Cohorts 发送 PreCommit 请求，进入 Prepared 阶段
  2. 事务预提交： Cohorts 接受到 PreCommit 请求后，执行事务，记录 undo 和 redo 信息
  3. 响应反馈：如果Cohorts执行完事务操作，则返回 ACK 响应 ，并等待最终指令
• 如果任何一个Cohorts响应为 NO：执行事务的中断
• 等待超时，Coordinator 没有接收到Cohorts的响应：执行事务的中断
  1. 发送中断请求：Coordinator 向所有 Cohorts 发送 abort 请求
  2. 中断事务： Cohorts 接收到 abort 请求 之后（或者超时之后），执行事务中断

3. doCommit 阶段

• 执行提交：

  1. 发送提交请求：Coordinator 接受到所有 Cohorts 的 ACK 响应 ，从预提交进入到提交状态，并向所有 Cohorts 发送 doCommit 请求

  2. 事务提交： Cohorts 接受到 doCommit 请求之后，执行正式的事务提交，并在完成之后释放所有资源

  3. 响应反馈：事务提交完成之后，向Coordinator 发送 ACK 响应

  4. 完成事务：Coordinator 接收到所有 Cohorts 的 ACK 响应 之后，完成事务

• 中断事务:（Coordinator 没有接收到 Cohorts 的 ACK，发送的不是ACK或者超时）

  1. 发送中断请求：Coordinator 向所有 Cohorts 发送 abort 请求
  2. 事务回滚： Cohorts 接收到 abort 请求后，利用其在 ProCommit 阶段记录的信息来回滚事务，并释放资源
  3. 反馈结果： Cohorts 完成事务回滚后，向Coordinator 发送 ACK 消息
  4. 中断事务：Coordinator 接收到 Cohorts 反馈的 ACK 消息 后，执行事务的中断

2. 分布式事务方案

2.1 全局事务（DTP模型）

DTP模型： 由X/Open组织提出的一种分布式事务模型——X/Open Distributed Transaction Processing Reference Model

DTP 规定的三种角色：

1. AP: Aplication 应用系统。即我们开发的业务系统，在业务过程钟，可以使用资源管理器提供的事务接口来实现分布式事务

2. TM: Transaction Manager 事务管理器

   • 分布式事务的实现由 TM 来完成，TM 提供分布式事务的操作接口，这些接口 TX 接口
   • TM 还管理着所有的资源管理器（RM）,通过它们提供的 XA 接口 来统一调度这些 RM ，以实现分布式事务
   • DTP只是一个模型，具体 TM 可以采用 2PC, 3PC, Paxos 等协议去实现分布式事务

3. RM: Resource Manager 资源管理器

   • 能够提供数据服务的对象都可以是 RM 。比如：数据库、消息中间件、缓存等。数据库即为分布式事务中的资源管理器

   • RM 能够提供单数据库的事务能力，它们通过 XA接口 将本地数据库的提交、回滚等能力提供给 TM 调用，以帮助 TM 实现分布式的实物管理

   • XA 是 DTP 模型定义的接口，用于向 TM 提供该 RM （该数据库）的提交、回滚等能力

   • DTP只是一套实现分布式事务的规范， RM 具体的实现是由数据库厂商来完成的。

2.2 基于可靠消息服务的分布式事务

2.3 最大努力通知（定期校对）

2.4 TCC（两阶段型、补偿型）

TCC即为Try Confirm Cancel，它属于补偿型分布式事务。

三个步骤：

1. Try:尝试待执行的业务
   • 这个过程不执行业务，只是完成所有业务的一致性检查，并预留执行需要的全部资源
2. Confirm:执行业务
   • 使用 Try 阶段预留的业务资源执行业务
3. Cancel:取消执行的业务
   • 业务执行失败，进入 Cancel 阶段，释放所占用资源，回滚 Confirm 阶段执行的操作