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

深度探究 OpenRaft ｜Data Infra 研究社第二期_哔哩哔哩_bilibili

Paxos算法 | Calvin's Marbles