理解2PC，3PC与TCC

理解TCC、2PC和3PC

2PC

2PC，是Two-Phase Commit的缩写，二阶段提交。

过程如下：

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

2PC的缺点

二阶段提交看似能提供原子性操作，但不幸的是：二阶段提交还是有几个缺点的：

1. 同步阻塞问题：执行过程中，所有参与节点都是事务阻塞型。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
2. 单点故障：由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其是在第二阶段，协调着发生故障，那么所有的参与者都处于锁定状态，而无法进行事务操作。（挂掉会重新选一个协调者，但有时候会因为协调者宕机导致参与者阻塞）
3. 数据不一致：在二阶段提交的阶段二中，当协调者向参与者发送commit请求后，出现了异常（网络波动，协调者宕机），导致只有一部分接收到commit请求，这样子这一部分就会进行commit操作，导致出现数据不一致。
4. 二阶段无法解决的问题：协调者发完commit后宕机，唯一的参与者也宕机，那么即使选举出新的协调者，那么这个事务状态也是不可知的。

3PC

三阶段提交（Three-phase commit），也叫三阶段提交协议（Three-phase commit protocol），是二阶段提交（2PC）的改进版本。

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

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

也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。

CanCommit阶段

3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。

1. 事务询问协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。
2. 响应反馈参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No

PreCommit阶段

协调者根据参与者的反应情况来决定是否可以记性事务的PreCommit操作。根据响应情况，有以下两种可能。

假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。

1. 发送预提交请求协调者向参与者发送PreCommit请求，并进入Prepared阶段。
2. 事务预提交参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。
3. 响应反馈如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。

假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行分布式事务的中断。

1. 发送中断请求协调者向所有参与者发送abort请求。
2. 中断事务参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行分布式事务的中断。

doCommit阶段

该阶段进行真正的事务提交，也可以分为以下两种情况。

1、执行提交

1. 发送提交请求：协调者接收到参与者发送的ack请求，那么参与者会从预提交状态进入提交状态，并向所有参与者发送doCommit请求。
2. 事务提交：参与者接收到doCommit请求后，执行正式的事务提交。并在事务结束后释放所有事务资源。
3. 响应反馈：事务提交完毕后，向协调者发送ack响应。
4. 完成事务：协调者接收到所有参与者发送的ack响应后，完成事务。

2、中断事务

协调者没有接收到参与者发送的ack响应（参与者发送的不是ack响应，响应超时等），那么就会中断事务。

1. 发送中断请求：协调者向所有参与者发送abort请求
2. 事务回滚：参与者接收到abort请求后，利用其在二段的undo信息来执行事务回滚，并在回滚结束后释放所有事务资源。
3. 反馈结果：参与者完成事务回滚之后，向协调者发送ack消息。
4. 中断事务：协调者收到ack消息后，执行事务中断

2PC与3PC的区别

相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的消息后，会默认执行commit操作，而不会一直让事务处于阻塞状态。但是也有可能会造成数据不一致。例如：当一部分机器收不到协调者信息，这时候协调者发送的abort信息，这样的话，一部分机器commit，一部分rollback，就会导致数据不一致。

TCC

TCC分别对应Try，Confirm和Cancel三种操作，三个操作业务含义如下：

Try：预留业务资源

Confirm：确认执行业务操作

Canal：取消执行业务操作

与关系型数据库事务的三个操作作对比：DML、Commit，Rollback

操作	TCC	关系型数据库事务
Try/DML	预留业务资源	锁定数据库记录行
Confirm/Commit	确认后，使用预留资源	对锁定记录航进行操作
Cancel/Rollback	没有全部成功就回滚	没有全部成功就回滚

TCC和两阶段分布式事务处理的区别

当讨论2PC时，我们只专注事务处理阶段，因而只讨论prepare和commit，所以，可能很多人都忘了，使用2PC事务管理机制也是有业务逻辑阶段的。正是因为业务逻辑的执行，发起了全局事务，这才有其后的事务处理阶段。所以，实际上，使用2PC机制时，以提交为例：

一个完整的事务周期：

begin–>业务逻辑–>prepare–>commit。

再看TCC，也不外如是：要发起全局事务，同样也必须通过业务逻辑来实现。该业务逻辑一来通过执行触发TCC全局事务的创建；二来也需要执行部分数据写操作；此外还要通过执行想TCC全局事务注册自己，以便后续TCC全局事务commit/rollback时回调其相应的confirm/canal业务逻辑。所以，使用TCC机制时，以提交为例：

一个完整的生命周期：

begin–>业务逻辑(Try业务)–>commit(confirm业务)。

综上所述：将两个机制做对应：

1、2PC机制的业务阶段 === TCC机制的try业务阶段

2、2PC机制的提交阶段(prepare & commit) ==== TCC机制的提交阶段(confirm)

3、2PC机制的回滚阶段(rollback) === TCC机制的回滚阶段(cancel)

结论

TCC中的两个阶段都存在业务逻辑的执行，但其中try业务阶段其实是与全局事务处理无关的。当认清这一点之后，再比较TCC与2PC，就会发现，TCC不是两阶段提交，而只是它对事务的提交与回滚是通过confirm/cancel业务逻辑来实现的