文章讨论了Raft协议在选举和状态机管理上的设计，指出其相比Paxos在选举冲突概率、日志复制与投票的并发性以及配置变更时的容错性方面存在的问题。Raft的Term逻辑可能导致选举冲突，而Paxos的全序关系更优。此外，Raft的优化如prevote机制旨在减少不稳定情况，但仍有改进空间。
Raft相比于paxos不好的地方有下面这些地方
1.Term
raft的逻辑时钟是通过term，和votefor来确定的，同时，raft的votefor只能是None < 有，有的话，就不可比，也就是一个偏序关系。这个不可比的特性会增加选举冲突的几率，比如下面这个例子中，candidate都给自己投票的，这个term就谁也变不成leader。
而paxos（可能说的是multi-paxos）则是一个全序关系，冲突概率就小很多
2.Server State
leader可以发起日志复制，但不能来投票，candidate可以发起vote，但不能日志复制，也就是说在raft这里日志复制和投票是不能并行来做的。但是这是可行的
优化
如果vote不成功的话，回退会follower.
单节点变更的bug
可能覆盖之前的提交。解决方法就是leader起来后先来插入一条空日志，然后提交后，再propose 新的config。也就是要保障Cu起来后不能成为leader。（也就是原来的大多数就只有一个）。
联合共识来变更有更好的容错性
多了一种组合bc
有两种配置日志生效：立即生效（没提交的话，需要做一些处理）提交生效（两个大多数的日志commit_idx不同，需要做一些处理）
prevote
就是多做一个rpc来问这个follower当前有没有leader。 也就是在follower上做一个超时时间，每次leader发送心跳给它时，重置一下。
clock-time和term mix混合起来做一个时间很糟糕，但是如果我们把lastterm, lastlog作为时间就比较好（把heartbeat也append日志）
但是有可能在一个极端的情况下，prevote到达时，heartbeat没到，然后candidate提升term，准备vote，打破本不应该打破的稳定网络。这时，我们就要下面的方法：
prevote就是要解决如果对面形成了一个稳定网络的话，我就不用提升term，来打破这个网络(leader)，但是如果我们直接不打破网络（leader），直接提升leader的term的话，就可以做一个优化。
Reference
747
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
