分布式一致性算法梳理

Posted 2022-11-22 hhhshct

　　分布式一致性算法主流方案：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/。