利用paxos算法实现主从选举方案

Posted 跬步匠心

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了利用paxos算法实现主从选举方案相关的知识,希望对你有一定的参考价值。

设计场景


在分布式系统中,最常见的场景就是主备架构,一个主节点和多个普通节点。主节点负责对其他节点的协调和管理。当主节点宕机时,需要在普通节点中重新选举一个成为新的主节点。本文主要基于paxos算法来一步步讲解重新选举方案的实现。



自荐与无条件服从


发生主节点宕机时,存活着的普通节点都会“自荐”参与主节点的选举,并且将这一"提议"广播通知所有存活节点。节点每收到一个候选的"提议"后,都会无条件的同意该提议。

很明显,这样最终结果会导致各个节点中的master节点会各不相同。原因在于后到的“提议”会覆盖掉前面的“提议”,而对于每个节点最后接收的“提议”可能各不相同。


带有版本号的提议


为了解决各个节点最后接收的“选举提议”不同导致对主节点的选举无法达成一致,我们引进一个选举版本号,节点“自荐”前,会先在版本生成器中获取一个单调递增的版本号,在广播”提议“时带上版本号。节点收到"提议"后,会比较提议中的版本号a与节点此前收到的最大版本号b相比,如果a>b,则接受该”提议“,否则保持原本的master选择。

利用paxos算法实现主从选举方案

由于v5比其他版本号都大,所以最终结果是全部节点都统一server5成为master。


选举结果虽然统一了,但选举过程中经历了几次选举结果的覆盖,比如server1首先收到v2,将master设置为server2,后面再收到v5,将master覆盖为server5。


有些主从架构中,切换了master后,新master需要对自身进行初始化操作,同时,普通节点确定master后,需要向master请求同步一些元信息。当server收到一个更大版本的master时,都会重新进行信息同步,当server发现自己版本是当前最大时,也会进行一次master初始化。所以,这个方案还需要进一步完善。



提议前询问


上个方案的问题主要是由于高版本的master提议与已被采纳的低版本master提议不一样导致的。所以,我们可以在获取版本号后,先向其他各个存活节点发送请求。请求的目的有三个:

  • 获取各个节点当前接受的master提议。

  • 检查这次发送的版本号Vsend各个节点能不能接受(如果Vsend比节点此前收到的最大版本号Vrecvd小,则Vsend不会被节点接受)。

  • 如果发送的版本号比节点接收过的版本号都大,会更新Vrecvd = Vsend。


各节点的响应汇总后按以下处理:

  • 如果没有超过集群节点总数一半(全部节点,不止当前存活节点)的节点接受发送的版本号,直接中断此次master提议。

  • 如果超过半数同意了Vsend:

    • 节点中有已经接受的master提议(这种情况下,如果有多个节点都有接受的master提议,接受的提议都是一样的,可以思考下为什么),将该提议当成此次版本的master提议。

    • 各节点此前都没有任何master提议,将采取“自荐”的方式,把当前server当成此次版本的master提议。


确定了这次版本的master提议后,再向各个节点广播提议内容。节点收到提议后,会再次比较Vrecvd与提议中的版本号,如果提议中的版本号比较大,接受此次提议,否则保持原本的master选择。


我们通过下面时序图来看看当两个节点同时进行提议时,会如何处理。假设server的版本号为v1,server2的版本号为v2,v1 < v2。


v1的提议,虽然在"询问"是否接受v1版本时,4个节点都给予了肯定,但最终只有被server1接受了,因为其他节点在收到v1的提议时,当前的版本Vrecvd均为v2,所以都拒绝了v1的提议。


v2的提议,当”询问"server1的时候,此时server1上已经有master提议了,所以v2的提议内容与v1的提议相同,都是server1。保证了高版本的提议与已被采纳的低版本master提议一致。


以上是关于利用paxos算法实现主从选举方案的主要内容,如果未能解决你的问题,请参考以下文章

ZAB协议与Paxos算法

Raft算法

ZAB协议工作机制与及他与PAXOS算法的区别

Paxos工程实践

分布式环境RAFT一致性共识算法解读

分布式学习笔记1-分布式算法Raft