标签：targe 获取当前值 keep 请求 集群 投票 节点 img 过程
分布式一致性算法主流方案：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/。
标签：targe 获取当前值 keep 请求 集群 投票 节点 img 过程
原文地址：https://www.cnblogs.com/hhhshct/p/11567365.html
