参考:html
Paxos 一致性协议能够说是一致性协议研究的起点,也以难以理解闻名。其实协议自己并无多难理解,它的难理解性主要体如今:为什么如此设计协议以及如何证实其正确性。本文尝试经过流程图来讲明协议的内容以及基本应用过程,不涉及如何证实其正确性。算法
Paxos 能够分为两种:微信
本文只关注单 Paxos 的原理,理解了单 Paxos,多 Paxos 也就不难理解了。网络
在协议中,每一个节点能够同时扮演以上多个角色。分布式
Paxos
经过上面的流程,若是有多个节点同时提出各自的提议,Paxos 就能够保证从中选出一个惟一肯定的值,保证分布式系统的一致性。学习
下面咱们经过例子来理解 Paxos 的实际应用过程。spa
假设如今有五个节点的分布式系统,此时 A 节点打算提议 X 值,E 节点打算提议 Y 值,其余节点没有提议。
Paxos-1.net
假设如今 A 节点广播它的提议(也会发送给本身),因为网络延迟的缘由,只有 A,B,C 节点收到了。注意即便 A,E 节点的提议同时到达某个节点,它也必然有个前后处理的顺序,这里的“同时”不是真正意义上的“同时”。
Paxos-2设计
A,B,C接收提议以后,因为这是第一个它们接收到的提议,acceptedProposal 和 acceptedValue 都为空。
Paxos-3htm
因为 A 节点已经收到超半数的节点响应,且返回的 acceptedValue 都为空,也就是说它能够用 X 做为提议的值来发生 Accept 请求,A,B,C接收到请求以后,将 acceptedValue 更新为 X。
Paxos-4
A,B,C 会发生 minProposal 给 A,A 检查发现没有大于 1 的 minProposal 出现,此时 X 已经被选中。等等,咱们是否是忘了D,E节点?它们的 acceptedValue 并非 X,系统还处于不一致状态。至此,Paxos 过程尚未结束,咱们继续看。
Paxos-5
此时 E 节点选择 Proposal ID 为 2 发送 Prepare 请求,结果就和上面不同了,由于 C 节点已经接受了 A 节点的提议,它不会三心二意,因此就告诉 E 节点它的选择,E 节点也很绅士,既然 C 选择了 A 的提议,那我也选它吧。因而,E 发起 Accept 请求,使用 X 做为提议值,至此,整个分布式系统达成了一致,你们都选择了 X。
Paxos-6
上面是 Paxos 的一个简单应用过程,其余复杂的场景也能够根据流程图慢慢推导,这里只是抛砖引玉。