这几天研究了一下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到状态机中？
随便写点，，比较乱。
他们不计后果的彼此拥抱，握紧双手，怕天会亮，怕爱会走。
