-
Notifications
You must be signed in to change notification settings - Fork 623
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lec 5:Raft基本 #9
Comments
Raft是工程化中非常有名且有效的分布式一致性算法,本次关注:Leader选举和日志的部分(对应Lab 2A与2B),下节关注:持久化、客户端行为和快照(Lab 2C和Lab 3) Raft是Paxos算法的简化版本,基于自动机复制(state machine replcation),即所有备份节点都执行相同的命令序列,以求得到相同的结果。核心问题就是要处理脑裂的问题,实现的基础在于保证“大多数”节点还是存活的,这里的“大多数”(quorm)指总数中超过半数。 Raft使用日志作为复制的单位载体(仅利用KV DB来维护状态并不够),思路是编号定序与方便存储,编号定序保证复制命令执行顺序性,存储保证消息可靠性。 Raft设计的两个难点:
Lab2A就是要实现一个选主算法。 首先考虑为何要选出leader?可以简化设计,保证其他节点执行按相同顺序执行相同命令。Raft使用term概念标记leader顺序,一个term中最多一个leader(可能没有leader),帮助其他节点找到最新的leader。 何时开始选主?节点发现收到主节点通信时,增加自己的term值,发起选举。注意这样可能导致不必要的选举过程,但是安全;也可能出现原leader还存活并且自认还是leader的情况。旧leader仅会影响“小部分”节点,大多数不会执行它的指令。 如何保证只有最多一个leader获胜?所有节点每轮只需投票一次,回应第一个询问的节点。获得“大多数“”节点投票信息的leader获胜。其他节点通过接收主节点的AppendEntries和心跳信息得知leader的获胜与存活。可能出现没有leader胜出的情况【活锁问题】,此时会超时并重新发起选举(term值递增)。 如何选择超时时间?至少几个心跳时间,节点随机选择长度,但要足够完成一轮选举。 |
选主算法的工程实现要点节点需要维护的字段:
节点可以发出两个RPC:
平时的日志同步RPC,同时有心跳功能。
由候选人负责调用用来征集选票。
节点线程模型
|
首先a,d,f在发现leader失效之后都可以将自己选为learder,并向其他server发送RequestVote RPC。在Section 5.4.2上面一点提到:
所以我们只要比较candidate与voter之间哪个新即可判断投票者是否deny vote。
不知道对不对。。。 |
不对,follower变成candidate首先会给自己投票,所以f会首先投给f。现在有6个servers,3个发起投票,没有一个可以得到超过半数的票,所以必然time out,重新建立新term,发起投票。 |
从Figure2可以看到投票结果只有两个判断: 题目是看a,d,f三个如果竞选leader的话,其他node是否会给它投票,说并不是说三个adf同时参加选举。
综上:
|
为什么f会投票给a 呀,没看明白 |
课前阅读论文:Raft Extended(2014)
讲义:英文
FAQ:英文
本期问题(请大家在本issue中直接回答):假设有七台机器的集群如论文中的Figure7所示,如果Leader失效后,节点(a)、(d)、(f)能否被选为Leader?如果可以,谁会投票?如果不行,Raft什么机制会阻止他们当选?
The text was updated successfully, but these errors were encountered: