如果想要对Raft算法的了解更深入一点的话，仅仅做6.824的Lab和读《In Search of an Understandable Consensus Algorithm》这篇论文是不够的。我个人粗略阅读了一下Tikv中关于Raft的实现（https://github.com/tikv/raft-rs ，使用rust语言，基本移植了etcd中关于raft算法的实现），并配合着注释阅读了下原作者的博士论文《CONSENSUS: BRIDGING THEORY AND PRACTICE》，配合着PingCap的一些Blog，还是比较有收获的。开这篇Blog是希望记录一下6.824的Lab和《In Search of an Understandable Consensus Algorithm》中没有涉及到的一些东西。
Cluster Member Change集群成员变更足足占了一整张Ongano的论文，重要性不言而喻吧..
Safty GuaranteeConf Change的设计首先要保证安全问题；假设当前使用旧配置的机器构成集合Mold，使用新配置的机器构成集合Mnew；在Ongano的论文中，貌似将安全性问题等价为了双主问题，即Mold和Mnew是否会形成两个互不交叠Qurom（两个Qurom存在选出两个Leader的可能性）；换句话说，原作者认为只要解决了双主问题，Conf Change的安全性就得以保证；
上图为一种双主问题的情景；在箭头所指的地方，{3, 4, 5} ∈ Mnew， {1, 2} ∈ Mold；nQurom(Mold) = (3 + 1) / 2 = 2，nQurom(Mnew) = (5 + 1) / 2 = 3；可以看到{1, 2}可以构成Qurom，{3, 4, 5}也可以构成Qurom，这样就可能出现双主错误；
在2014年的论文中，采用了一种Join Concensus算法解决双主问题；而在Phd的论文中提出了一种更加简单的方法：一次Conf Change只添加/删除一台Server；在这种情景下，两个Qurom至少有一个交集，因此双主错误可以避免，而更加复杂的Conf Change也可以由多次增/删机器来实现；
1）当Server收到Conf Change时，必须立刻使用，无需等待其对应的日志被提交；
2）只有上一条Conf Change成功提交后，才允许下一条Conf Change开始；
3）Conf Change可能最终未能提交而被截断；在这种情景下，Server必须恢复到Conf之前的状态
Unfortunately, this decision does imply that a log entry for a configuration change can be removed (if leadership changes); in this case, a server must be prepared to fall back to the previous configuration in its log.
作者在论文中解释了为什么Conf Change的日志为什么会立即生效，而不是在Commit时生效：
If servers adopted Cnew only when they learned that Cnew was committed, Raft leaders would have a difficult time knowing when a majority of the old cluster had adopted it. They would need to track which servers know of the entry’s commitment, and the servers would need to persist their commit index to disk;
增添机器我们考虑新的机器的加入会对集群的Avalibility产生哪些影响：
1）新的机器初始日志是空的，它Catch-Up需要一段不短的时间；
2）新的机器可能会被算入Qurom，它的Catch Up所需时间可能会影响性能；例如3台机器构成的cluster其Qurom为2，而4台机器构成的Qurom为3，为此整个集群必须等待那个新加入者顺利Catch Up才能提交新的请求；
新的机器可能性能或环境很差，迫使Leader为它花费更多的开销；例如说必须给他送多次AppendEntries浪费网络带宽，或者想做一次日志压缩，但被迫要等待那台慢的机器；
Raft算法充分考虑了上述情景，并给出了解决方案：
为这些新加入的机器设定设定一个Learner的角色；Learner可以投票，可以接收日志，但其本身不被计入Qurom内，等它Catch Up到了一定阶段后，再把它计入到Qurom内；这解决了问题1和2，但又引入了一个新的问题，就是怎么评估新机器的Catch Up进度，以及这个进度到哪个程度时才把它计入Qurom；
为了解决3以及前面新带来的问题，作者提出了一种Catch-Up算法；设定一个max_round，每个round里都会将自己所有的日志（第一轮round）或者新机器缺的日志（后面的rounds）全量发送；如果发现新的机器可以赶得上，那么就把它计入Qurom，否则会回报一个错误，期望集群管理者将这台机器撤除掉；
If the last round lasts less than an election timeout, then the leader adds the new server to the cluster, under the assumption that there are not enough unreplicated entries to create a significant availability gap. Otherwise, the leader aborts the configuration change with an error.