雷火UX数据挖掘初识分布式共识算法Basic Paxos

Posted 2021-04-03 网易雷火UX用户体验中心

01

一致性性与共识算法的关系

一致性（Consistency）

CAP中的一致性：客户端的每次读操作，不管访问哪个节点，要么读到的都是同一份最新的数据，要么读取失败。一致性强调的不是数据完整，而是各节点间的数据一致。

共识（Consensus）

每个进程都提出自己的提案（propose），最终通过共识算法，所有正确运行的进程决定（decide）相同的值。

一致性往往指分布式系统中多个副本对外呈现的数据的状态。（静态）

共识则描述了分布式系统中多个节点之间，彼此对某个提案达成一致结果的过程。（动态）

一致性描述的是结果，共识则是一种手段。

02

提议者、接受者、学习者

提议者（Proposer）：提议一个值，用于投票表决

接受者（Acceptor）：每个提议的值进行投票，并存储接受的值。一般来说，集群中的所有节点都在扮演接受者的角色，参与共识协商，并接受和存储数据。

学习者（Learner）：被告知投票的结果，接受达成共识的值，存储保存，不参与投票的过程。

03

算法流程

准备阶段

①提案者向所有接受者发送包含提案编号的准备请求（在准备请求中是不需要指定提议的值的，只需要携带提案编号就可以了）

②由于之前没有通过任何提案，所以节点 A、B 将返回一个 “尚无提案”的响应。也就是说节点 A 和 B 在告诉提议者，我之前没有通过任何提案，并承诺以后不再响应提案编号小于等于 1 的准备请求，不会通过编号小于 1 的提案

③当节点 A、B 收到提案编号为 5 的准备请求的时候，因为提案编号 5 大于它们之前响应的准备请求的提案编号 1，而且两个节点都没有通过任何提案，所以它将返回一个 “尚无提案”的响应，并承诺以后不再响应提案编号小于等于 5 的准备请求，不会通过编号小于 5 的提案。当节点 C 收到提案编号为 1 的准备请求的时候，由于提案编号 1 小于它之前响应的准备请求的提案编号 5，所以丢弃该准备请求，不做响应。

接受阶段

当节点 A、B、C 收到接受请求[1, 3]的时候，由于提案的提案编号 1 小于三个节点承诺能通过的提案的最小提案编号 5，所以提案[1, 3]将被拒绝。

当节点 A、B、C 收到接受请求[5, 7]的时候，由于提案的提案编号 5 不小于三个节点承诺能通过的提案的最小提案编号 5，所以就通过提案[5, 7]，也就是接受了值 7，三个节点就 X 值为 7 达成了共识。

当接受者通过了一个提案时，就通知给所有的学习者。当学习者发现大多数的接受者都通过了某个提案，那么它也通过该提案，接受该提案的值。

04

总结

Basic Paxos 是通过二阶段提交的方式来达成共识的二阶段提交是达成共识的常用方式。

Basic Paxos 还实现了容错，在少于一半的节点出现故障时，集群也能工作。它不像分布式事务算法那样，必须要所有节点都同意后才提交操作，因为“所有节点都同意”这个原则，在出现节点故障的时候会导致整个集群不可用。

Basic Paxos算法只对某个值达成了共识，对一系列值达成共识需要用Multi-Paxos。

参考资料

https://www.jianshu.com/p/98f94482c9f1

https://zhuanlan.zhihu.com/p/68743917

往期推荐