码迷,mamicode.com
首页 > 其他好文 > 详细

2PC和3PC

时间:2020-04-17 20:31:54      阅读:85      评论:0      收藏:0      [点我收藏+]

标签:多个   分布式系统   释放   参与   情况   原理   自身   ack   redo   

概念:

当一个事务需要跨越多个分布式节点的时候,需要保持事务处理的ACID,引入“协调者”的组件统一调度所有分布式节点的执行逻辑,被调度的节点称为“参与者”。协调者负责调度参与者的行为,并最终决定这些参与者是否要把事务真的提交。因此引入2PC和3PC。

 

2PC:

二阶段提交,为了使基于分布式系统架构下的所有节点进行事务处理过程中能够保证原子性和一致性设计的一种算法。

阶段一:“投票阶段”

  1,事务询问:协调者向参与者发送事务内容,询问是否可以执行事务提交操作,并等待参与者的响应。

  2,执行事务:各参与者执行事务操作,并将Undo和Redo信息记入事务日志中

  3,各参与者向协调者反馈事务询问的响应:成功执行返回YES,失败返回NO

阶段二:“执行阶段”

  执行事务提交:所有参与反馈都是YES

  1. 发送提交请求:协调者向所有参与者节点发出Commit请求
  2. 事务提交:参与者接收到Commit请求后,执行提交,并释放整个事务执行期间占用的事务资源
  3. 反馈执行情况:完成事务提交后,向协调者发送ACK消息
  4. 完成事务:收到ACK消息后完成事务

  中断事务:任意一个参与者反馈为NO,或等待超时

  1. 发送回滚请求:协调者向所有参与者发出Rollback
  2. 事务回滚:收到Rollback后,利用阶段一的Undo信息来执行事务回滚,并在完成后释放资源
  3. 反馈事务回滚结果:参与回滚后,发送ACK消息
  4. 中段事务:协调者收到所有参与者的ACK消息后,完成事务中断

优缺点:

  • 优点:原理简单,实现方便
  • 缺点:同步阻塞,单点问题,脑裂,太过保守

  同步阻塞: 在二阶段执行过程中,所有参与该事务操作的逻辑都处于阻塞状态,各个参与者等待其他参与者响应的过程中,将无法进行其他操作,接单理解,有的快,有的慢,快的必须等到慢的结束才能继续执行.

  单点问题: 整个过程都依赖协调者,如果协调者出问题,那么所有的参与者都将无法正常允许

  数据不一致: 在协调者发送Commit的时候,因为网络等原因,一部分发送,一部分未能正常发送,将会导致数据不一致现象

  太过保守: 当某一个参与者故障,就会导致协调者无法获取所有参与者响应,只能依赖自身的超时机制来判断时候中断事务,简单来说就是容错机制不完善,任意一个节点失败整个事务就将失败.

 

3PC:

2PC的改进版,三阶段提交,将二阶段的"提交事务请求"一分为二, 有CanCommit, PreCommit和DoCommit 三部分组成.

阶段一: CanCommit

  1. 事务询问 
  2. 各参与者向协调者事务询问的响应

阶段二: PreCommit

  执行事务提交

  1. 发送预提交请求
  2. 事务预提交
  3. 各参与者向协调者反馈事务执行的响应

  中断事务请求

  1. 发送中断请求
  2. 中断事务

阶段三: doCommit

  执行提交

  1. 发送提交请求
  2. 事务提交
  3. 反馈事务提交
  4. 完成事务

  中断事务

  1. 发送中断请求
  2. 事务回滚
  3. 反馈回滚结果
  4. 中断事务

优缺点:

  • 优点, 相比于二阶段提交,降低了参与者的阻塞范围,并且能够在出现单点故障后继续达成一致
  • 缺点, 在进入PreCommit时,如果出现网络分区,此时协调者所在的节点和参与者无法进行正常的通信,但是参与者在等待一段时间后会自动执行事物的提交,出产生数据不一致.

2PC和3PC

标签:多个   分布式系统   释放   参与   情况   原理   自身   ack   redo   

原文地址:https://www.cnblogs.com/codingLiu/p/12722115.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!