什么是2PC 3PC TCC?

Posted 2020-12-16 zyh-s

2PC（两阶段提交）

 

 

阶段1

 

在阶段1中，协调者发起一个提议，分别问询各参与者发送事务预处理请求（可不可以执行任务）

 

 

阶段2

在阶段2中，协调者根据参与者的反馈，提交或中止事务，如果参与者全部同意则提交，只要有一个参与者不同意就中止。

 

 

缺点

• 同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
• 单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
• 丢失消息导致的数据不一致问题。在第二个阶段，如果发生网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，那么就会导致节点间数据的不一致问题。
  
  
  
  

3pc（三阶段提交）

 

其在两阶段提交的基础上增加了CanCommit阶段，并引入了超时机制。一旦事务参与者迟迟没有收到协调者的Commit请求，就会自动进行本地commit，这样相对有效地解决了协调者单点故障的问题。这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。

 

 

CanCommit阶段

 

事务的协调者向所有参与者询问“你们能否完成本次事务？”，如果参与者节点认为自身可以完成事务就返回“YES”，否则“NO”。而在实际的场景中参与者节点会对自身逻辑进行事务尝试

 

 

 

PreCommit阶段

 

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

假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。发送中断请求 协调者向所有参与者发送abort请求。中断事务 参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求）。

 

 

doCommit阶段

 

协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。 事务提交完之后，向协调者发送Ack响应。协调者接收到所有参与者的ack响应之后，完成事务。

 

 

 

 

如果有一个参与者节点未完成PreCommit的反馈或者反馈超时，那么协调者都会向所有的参与者节点发送abort请求。利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。

 

补偿事务（TCC）

 

 

• Try阶段：主要是对业务系统做检测及资源预留。

 

• Confirm阶段：确认执行业务操作。

 

• Cancel阶段：取消执行业务操作。

 

 

TCC与2PC类似，只是TCC针对于代码层面，对代码侵入性比较强，而2pc通常都是在跨库的DB层面。