分布式事务的分类和简述

发表于 | 评论数： | 阅读次数：

不聊什么是分布式事务，分布式事务是解决的什么问题，直接开搞常见的处理模式

2PC

定义

两阶段提交（two-phase commit protocol），是一个强一致性，中心化的原子提交协议

参与对象：

一个协调者（coordinator）和多个参与者（partcipant）

过程

  1. 请求/表决阶段，事务发起方（参与者角色）向事务协调者发送请求时，事务协调者向参与者A、参与者B分别发送事务预处理请求（Prepare）
    1. 正常流程：参与者A、参与者B会开启本地数据库事务并执行本地数据库事务，并汇报给事务协调者（Vote Commit）
    2. 异常流程：参与者A/参与者B会开启本地数据库事务并执行本地数据库事务，并汇报给事务协调者（Vote_Abort）
  2. 第二阶段：提交/执行阶段
    1. 正常流程：如果所有的参与者汇报给事务协调者的结果都是可以执行，那么事务协调者会向所有的事务参与者发送全局提交确认通知（global_commit），所有的事务参与者完成本地数据库事务的提交，并反馈给事务协调者ACK
    2. 异常流程：如果有参与者汇报给事务协调者的结果不是可以执行，那么事务协调者会向所有的事务参与者发送事务回滚的消息（“global_rollback”），所有的事务参与者完成本地数据库事务的提交，并反馈给事务协调者ACK

其他问题

  1. 性能问题，各个事务参与者都处在堵塞状态。
  2. 2PC在一阶段中，如果协调者（coordinator）在向事务参与者（partcipant）发起预处理请求（Prepare）后挂掉，则该事务参与者的事务会处在挂起状态，长时间占用资源。
  3. 2PC在二阶段中，如果事务协调者会向所有的事务参与者发送全局提交确认通知（global_commit）后发生局部网络故障，可能会有部分事务参与者没有接受到全局提交确认通知（global_commit），导致数据不一致的问题。

3PC

在2PC的基础上进行了完善，添加了CanCommit阶段，添加了超时机制

参与对象

一个协调者（coordinator）和多个参与者（partcipant）

过程

  1. 第一阶段：检查阶段（CanCommit），事务发起方（参与者角色）向事务协调者发送请求时，事务协调者向参与者A、参与者B分别发送事务尝试（CanCommit），尝试执行事务并确定是否能够执行。
  2. 第二阶段：请求/表决阶段（PreCommit），事务发起方（参与者角色）向事务协调者发送请求时，事务协调者向参与者A、参与者B分别发送事务预处理请求（Prepare），参与者将Undo和Redo信息记录到事务日志中，并反馈给事务协调者ACK
  3. 第三阶段：提交/执行阶段（DoCommit）
    1. 正常流程：如果所有的参与者汇报给事务协调者的结果都是可以执行，那么事务协调者会向所有的事务参与者发送全局提交确认通知（global_commit），所有的事务参与者完成本地数据库事务的提交
    2. 异常流程：如果有参与者汇报给事务协调者的结果不是可以执行或者有参与者超时，那么事务协调者回向所有事务参与者发送事务中断（abort）请求。

解决问题

  1. 解决了性能问题，使用undo和redo记录来代替占用数据库资源
  2. 使用超时回滚机制，解决了一阶段挂起问题
  3. 使用三阶段提交，保证了在DoCommit阶段时数据一致性，但是其他阶段没有保障

TCC

定义

TCC（Try-Confirm-Cancel），针对每一个操作都注册一个与之对应的确认和撤销操作

过程

  1. 第一阶段：Try预留阶段，对系统资源进行检查和预留
  2. 第二阶段：
    1. Confirm阶段，确认执行操作
    2. Cancel阶段，取消执行操作

优缺点

  1. 【优】TCC抛弃了DB级别的分布式事务和锁，通过应用来处理逻辑和数据，实现更加灵活和，堵塞时间更少，吞吐量更高
  2. 【缺】TCC依赖于业务，业务逻辑的每个分支都需要分成Try-Confirm-Cancel三个方法，分别在三个阶段调用，而且TCC必须满足幂等性，代码侵入强
  3. 【缺】TCC的分布式事务协调器并没有业界公认的开源实现