我们知道了Basic Paxos是可以根据某个值进行达成共识,但是一系列的值如何办呢?
Multi-Paxos并没有完全的说明,因为Multi-Paxos官方只是给出了一个思想,并没有给出对应的实现,所以很多算法都是基于这个思想实现的,比如Chubby的Multi-Paxos算法,Raft算法
我们按这个Chubby的Mutil-Paxos来进行说明Multi-Paxos思想是如何真正的在生产环境中真正落地
首先说一下Basic Paxos的局限性,并针对这都些局限性来查看Multi-Paxos是如何解决的
这是Basic Paxos的提交细节
Basic Paxos是通过二阶段提交达成共识的,第一个阶段,进行准备,准备好了,然后发起接受请求进入第二阶段
1.在多个提交者一同提交提案的时候,可能会出现编号冲突的问题,在准备阶段没有提议者收到大多数的准备响应的时候,就会出现协商,一个5节点的集群,如果收到了3个节点作为提议者同时提案,可能会出现1个提议者收到了一个准备响应,另外2个提议者各自收到了两个响应准备,导致没有人协商成功
2.2轮RPC通信,会因为往返信息多,耗性能,延迟大,分布式系统的运行建立在RPC通信上,因此,多次通信带来的延迟问题不容小觑
可以通过引入领导者和优化Basic Paxos的执行过程来进行解决的.我们看下解决方案
1.引入领导者,将整个领导者作为唯一提议者,就不存在多个提议者同时提交提案的问题了
虽然Multi-Paxos说了这个领导者的解决方案,但是没有说明如何实现选举领导者,需要单独的实现选举能力
比如在Chubby中,主节点是通过执行Basic Paxos来进行选举的,进行投票选择生成
2.优化Basic Paxos执行
可以采用,当领导者处于稳定的时候,省掉准备阶段,直接执行接受阶段,正因为领导者的序列的命令是最新的,导致不再需要通过准备请求来查看大多数节点的通过提案了,领导者可以独立指定提案中的值,省掉了第一轮的准备阶段
然后我们看一下Chubby如何实现Multi-Paxos的
1.领导者
引入了主节点机制,实现了领导者节点的特性,就是主节点作为唯一提议者,不存在多个提议者同时提交提案的情况
在Chubby之中,主节点是通过使用Basic Paxos算法来投票选举的,并且,在运行过程中,不断的进行续租操作,来延长租期,如果主节点中出现故障了,其他的节点就会选举出新的主节点
2.在Chubby中,根据主机点的永久存在的特性,于是直接省略了准备阶段,直接进入了接受阶段
但是为了保证强一致性,导致读操作也只能在主节点中执行,一旦写入成功,所有的客户端读到的数据都是一致的
写操作的话,就是直接请求主节点,然后执行Basic Paxos,将所有数据发送给所有节点,并且在所有的大多服务器接受这个写请求后,响应给客户端成功
读操作就很简单了,主节点只需要查询本地数据,然后返回给客户端就可以了
Chubby的Multi-Paxos的实现,是一个闭源的实现,但是Multi-Paxos思想在实际上很有价值
我们本章分享了Basic Proxy的局限,以及Chubbty 的 Multi-Paxos
重点如下
兰伯特提到的Multi-Paxos是一种思想,不是算法,还缺少算法的实现细节和编程必须的细节,如何选举领导者,这是局域Multi-Paxos实现的
Chubby实现的主节点,也就是领导者机制,也实现兰伯特提到的当领导者处于稳定状态,省掉了准备阶段,直接进行接收阶段的提交,这样的优化机制,但是由于实现的细节导致只能在主节点上进行读写操作,性能约等于单机
Chubby的Multi-Paxos实现中,约定了大多数原则,只要大多数节点正常运行,集群就能正常工作,所以Chubby能容错(n-1)/2节点
课后思考
Chubby只能在主节点上进行读操作,这个设计有什么限制吗?
这样的话,整体的设计就意义不大了,我们之所以使用分布式系统,其意义在于,提高吞吐量,但是如果只能在主节点操作,那么本质上还是一个单机系统,不过数据有了对应的备份罢了