分布式一致性算法梳理

Posted hhhshct

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了分布式一致性算法梳理相关的知识,希望对你有一定的参考价值。

  分布式一致性算法主流方案:2PC、3PC、leader/follower、paxos

  一致性有两种场景:

  1、多份相同的数据,在一处修改,保证多份一致
  2、一个业务变更多份不同的数据,要保持一致,要成功都成功,要失败都失败

 

  产生不一致的原因:

  1、异常操作导致不成功
  2、网络分区
  3、应用故障

  两阶段提交(2PC)

  将事务的提交分为准备和提交两个阶段来达成一致性的算法,主要用于事务管理、分布式一致性,两阶段提交需要在更新发起者和参与者中间加一个协调者的角色。具体步骤如下:

  1、变更者发起变更申请后由协调者询问各参与者是否可以提交,等待所有参与者给予回应
  2、参与者执行事务操作到待提交指令的点(这个过程中记录undo、redo日志)
  3、参与者响应会否准备好提交的结果给协调者,并阻塞等待协调者下一步的指令
  4、协调者接受所有参与者的响应,如果有一个 超时未收到响应,则当回滚处理
  5、协调者向所有参与者发布提交或者回滚的指令
  6、参与者执行提交或者回滚,释放占用的锁等资源,并作出响应
  7、结束

  两阶段提交的不足:

  1、会阻塞,参与者在等待协调者时会阻塞,并且如果准备完成后,协调者宕机,则参与者一直阻塞
  2、不一致,协调者发出提交或者回滚命令时,参与者宕机,收不到消息,造成不一致(需人工处理)

  2PC的实现:XA规范,java领域JTA实现

  三阶段提交(3PC):增加预提交阶段和超市机制来解决2PC出现的问题,具体步骤:

技术图片

  3PC存在的不足:在部分参与者在precommit失败,协调者宕机,等待超时后,precommit成功的参与者将提交,造成数据不一致,并且超时时间很难把控,因此3PC没有工业实现。

  leader/master方案,所有更新操作由leader发起,实现简单,大部分分布式一致性场景都采用这种方式,例如zookeeper。

  leader/master方案缺点:leader负载高、leader单点故障集群不可用(新leader选举期间)

  paxos算法

  角色:proposer(提议者,负责提议)、acceptor(接收者,负责投票)、learner(学习,不参与投票),一个节点既可以是proposer也可以是acceptor

  提案构成:提案编号(全局唯一自增,体现提案的先后顺序)、更新值

  写流程:

  1、准备阶段(投票阶段,提议者提出提案给接接收者,接收者如果同意该提案,则作出promise响应,并且承诺不再接受(accept)比当前提案编号更低的提案,
提议者收到过半数的响应,进入下一阶段,否则重新提案
  2、接受变更阶段(提交阶段),提议者向接收者发送accept消息,接收者比较accept中的提案编号,如果比自己当前已promise的提案编号小则回应NACK(把自己当前promise的提单号返回),否则接受accpet。

技术图片

  同一提案,提议者1、提议者2先后被批准,正常场景演示

技术图片

  接收者3与提议者2失联,接收者1与提议者1失联,异常场景演示

技术图片

  读流程:

  1、接收客户端请求的节点广播向大家获取当前值,
  2、接收到过半数的相同值,则返回该值,如果与本地的值不一致则更新该值
  3、得不到半数一样的值则读取失败

  此外还有一种常用的分布式一致性算法实现:RAFT,原理参考http://thesecretlivesofdata.com/raft/

  

以上是关于分布式一致性算法梳理的主要内容,如果未能解决你的问题,请参考以下文章

分布式一致性算法:Raft 算法

分布式一致性最强算法之Paxos透析

分布式一致性算法——paxos

图解一致性hash算法和实现

分布式缓存技术memcached学习系列—— 一致性hash算法原理

分布式系统共识机制:一致性算法设计思想