这几天研究了一下Raft协议,继Paxos之后出来的第二个可以理论证明自己正确性的分布式一致性协议(可以这么说吧,没仔细了解过其它协议)。
其实看过paxos,初看Raft,感觉还是有很多熟悉的面孔,仔细看作者的描述,确实两者也有不少差别。
我觉得basic paxos好像也没有Ongaro说的那么难以理解吧,不过有一点是肯定的,paxos给出了理论,但是距离一个基本可用的工程实践确实还有很远的距离。
很多关键的细节,比如新leader当选后,节点之间的日志如何sync;再比如选leader,paxos只保证proposal number最大者胜出,但是这个proposal number和工程意义的联系在哪里,比如是不是拥有最新日志的参与者,其proposal number应该越高;等等问题。
找时间再把paxos复习一编,很多都忘了,当初也不一定理解的对。
Raft将日志限制到了leader到follower的单向流动,又对能够竞选上leader的candidate施加了限制条件,这简化了很多问题。
Raft引入了term的概念,这玩意太像中国历史了,类比起来很容易理解term和leader的行为。
看Raft的论文,如何保证一条已经commit的log永远不丢失,并不难理解;可能稍微困难一点的是如果一条日志没有被commit,它后面可能出现什么问题?这里面有很多corner case。
如果一条日志在commit之前,leader被推翻了。那么这条日志就是未决状态,可能会被新leader间接的commit,也可能被覆盖掉。
如果leader在commit这条日志上花了太长的时间,比如100ms,leader可能暂时和它的follower闪断了,包延迟,有这个可能。会不会有什么不良后果?
Raft一个比较核心的概念就是log的committed状态,log被写入文件,不一定代表它是committed的,这个是理解Raft的核心之一吧。
如果一条log被leader commit了,也就被apply到了leader的状态机,然后,它何时会被各follower apply到状态机中?
随便写点,比较乱。