首先,这两者的选举都是采用过半选举的机制(因此,一般选择奇数布置)
一: etcd集群中的raft算法如何负责选举?(以三个节点为例子)
1.首先,在三个节点启动的时候,首先进入到candidate(候选者)状态,然后进行投票选举,这个时候,所有的节点都会在本地创建一个term的属性,并初始化为0.表示还没有开始选举投票,然后每个节点都会设置一个随机数的倒计时(150~300ms),当这个倒计时结束的时候,第一个倒计时结束的节点会率先发起投票,并且投票给自己即(vote = 自己本身) 的投票请求给其它两个节点.
2.假设有A.B.C三个节点, C节点在倒计时结束的时候率先发起了投票,则节点C将自己的term从0设置为1,并且vote票给自己,然后将这些参数包装发送给节点A和节点B,此时节点A和节点B还没有结束倒计时,节点A和节点B在收到C的投票请求之后,首先会比较收到的term和自己的term作比较,如果发现接收的term数值比自己的大,则会放弃自己的投票,把自己的票(vote)投给第一个接收到的投票请求, 即 节点A和节点B在收到C的请求之后,会比较term的值,发现自己的是0,接收到的是1,于是将自己的vote设置为节点C,然后响应请求,当节点C收到了节点A和节点B的响应(ack)和投票信息(vote),则会计算票数,由于过半选举机制,一个节点需要成为Leader节点,必须得到(n/2+1)的票数,而此时这里的n就是3,就是得到2票就可以当选leader节点,而C节点收到了节点A和节点B的两票,加上自己的一票,就是三票,则满足条件,于是节点C当选leader,当选leader之后向节点A和B发送心跳包,并且告诉它们自己成为了leader节点,那么节点A和B就会从candidate(候选者状态)转为follower(追随者)状态,并开始工作流程.此时选举流程结束
3.当我们遇到leader节点出现故障的异常情况时候(follower节点和leader节点会维持一个心跳的,并且会有超时时间),当follower节点在等待leader节点的心跳请求的时候,如果超过了这个超时时间,就会认为leader宕机了,然后节点都会进入到candidate(候选者状态),然后重新选举.假设在剩下的A和B中 B成为了新的leader,这个时候节点A和B的term就分别变为了1和2,但是由于节点C宕机,节点C的term还是1,这样做的好处 就是当节点C重启时候,发现自己的term落后了,那么不会在成为leader,就会等待新的leader将数据同步给自己,这样不会出现数据丢失的情况.
总结:(以A、B、C三个节点为例子)
启动时候:
1.启动时候,每个节点都会是一个candidate(候选者)状态,并且在本地创建一个term的属性,并初始化为0且各自有自己的倒计时((150~300ms)
2.当第一个倒计时结束的节点是C,那么会率先发起投票,term从0设置为1并且投票给自己即(vote = 自己本身) 的投票请求给其它两个节点A和B
3.A和B两个节点会比较收到的term和自己的term,发现接收的term数值比自己的大,则会放弃自己的投票,把自己的票(vote)投给C,然后响应回去
4.C收到响应,开始计算会发现自己有三票,满足过半选举机制,节点C当选leader,当选leader之后向节点A和B发送心跳包,并且告诉它们自己成为了leader节点,那么节点A和B就会从candidate(候选者状态)转为follower(追随者)状态并开始 工作流程.此时选举流程结束
运行时异常重新选举:
1.当已经当选leader节点C出现故障(如何发信故障是因为:follower节点和leader节点会维持一个心跳的,并且会有超时时间,超过超时时间,那么就认为leader挂掉了),然后节点都会进入到candidate(候选者状态),然后重新选举
2.假设剩下的A和B中,B当选了新的leader,此时A和B的term就分别变为了1和2
3.当C节点恢复了节点C的term还是1,这样C不会在成为leader,就会等待新的leader将数据同步给自己,这样不会出现数据丢失
二: zookeeper的leader的选举过程
首先理解下面几个:
1.serverId(服务器Id 即myId)
2.Zxid(最新的事务ID)
服务器存放的最大数据ID,一般ID值越大,说明数据越新,选举算法中数据越新,权重越大
3.epoch(逻辑时钟)
1.每个服务器都会给自己投票,或者叫投票次数,同一轮投票过程中的逻辑时钟值是相同的
2.每投完一次票这个数据就会增加,然后与接收到的其它服务器返回的投票信息中的数值进行比较
3.如果收到的低于当前轮次的投票结果,该投票无效,需更新到当前轮次和当前的投票结果.
4.选举状态
Looking 竞选状态
Following 随从状态,同步leader状态,参与投票
OBSERving 观察状态同步leader状态,不参与投票
Leading 领导者状态
启动时候选举:
在集群初始化阶段,当有一台服务器server1 启动的时候是无法进行和完成leader选举,当第二台服务器server2启动后,此时两台机器是可以相互通信,每台机器都试图找到leader,
于是便进入到leader选举过程:
1.每个server发出一个投票投给自己,由于是初始化情况,server1和server2都会将自己作为leader服务器来进行投票,每次投票会包含所推举的服务器myId和Zxid,即使用(myId,Zxid)来表示,此时server1的投票为(1,0),server2的投票为 (2,0),然后各自将这个投票发给集群中的其它机器.
2.接收来自给个服务器的投票,集群中的每个服务器收到投票后,首先判断投票的有效性,(如检查是否是本轮投票,是否来自Looking状态的服务器)
3.处理投票.针对每一个投票,服务器都需要将别人的投票和自己的投票进行pk.
pk规则:
1.检查Zxid,Zxid较大的服务器优先作为leader
2.如果Zxid相同,则比较myId,myId大的优先作为leader
4.统计投票.每次投票后,服务器都会统计投票信息,判断自己是否已经有了过半机器接收到了投票信息,对于server1和server2来说,都统计出了集群中已经有两台机器接收了(2,0)的投票信息,此时已经选出了leader.
5.改变服务器的状态. 一旦确定了leader,每个服务器都会更新自己的状态,如果是Follower --- > Following,如果是leader ---- > Leading
运行时异常重新选举:
1.在zookeeper运行期间,有非leader的服务器宕机或者新的机器加入,此时不会影响leader,但是一旦leader宕机,那么整个集群将暂停对外服务,进入到
新一轮的选举leader
2.变更状态.leader所在服务器宕机之后,余下的非observer服务器都会将自己的服务器状态变为Looking,然后开始选举流程
3.每个server都会发出一个投票,在这个过程中,需要生成投票信息即使用(myId,Zxid),每个服务器上的Zxid可能不同了,此时按照启动时的规则在进行比较就可以了
4.处理投票.(与启动一样)
5.统计投票.(与启动一样)
6.改变服务器的状态. (与启动一样)