不知怎么地,前一阵子知乎上对Raft的乱序的问题的讨论就变多了。我觉得其实这个问题可讨论的东西并不多。
Raft作者觉得Multi Paxos太复杂,所以搞了一个Raft。Raft加了很多约束,其中可能最重要的一条就是只能顺序commit。
所以,顺序commit的锅,Raft是得好好背着,翻不了案的。
值得谈一谈的是乱序apply。
能不能乱序apply本质上取决于你的状态机的设计。
比如,考虑rocksdb...
Deep Class
最近看了个有趣的talk:"A Philosophy of Software Design" by John Ousterhout。
如果要选一个概念,贯穿整个计算机系统,应该选哪个呢?
John Ousterhout问过Donald Knuth,Knuth给的答案是layers of abstraction。
John Ousterhout自己觉得是problem decomposition,要注意隔离复杂度。
Raft One-Server成员变更
前面介绍了Paxos成员组变更,现在根据Raft博士论文介绍一下Raft是怎么做成员组变更的。前者更多描述几个核心的思想,而后者更加实用,介绍了实践过程中遇到的一些实际问题。
Raft博士论文描述了两种变更方案:
One-Server变更:一阶段变更,要求每次成员组从G1变成G2时,G2相比G1加一个成员或者减一个成员。
Joint Consensus:支持任意的变更,即从成员组G1变成G2,不要求G1和G2有什么关联,比如可以完全...
Raft论文解读
Raft论文解读,本文根据Raft会议论文,参考Raft博士论文,解读了部分内容。Raft跟(Multi)Paxos差别较大,相比Paxos加强了很多约束,尤其是strong leader,直接影响了Raft协议的架构。