当领导者获得日志条目时，它将其复制到集群中的其他服务器。然后它提交该条目并告诉其他服务器也提交。这里似乎有两种情况:
1) 领导者提交条目，然后告诉其他服务器也提交。
2) 领导者告诉每个人都要做出 promise ，然后每个人也都会做出 promise 。
在#1中，如果领导者在告诉其他人提交之前崩溃了，那么成为新领导者的人是否会使用该条目，即使该条目尚未提交？如果不是，那么我们有一些日志与最新条目不同步。 (老领导者会应用它，而另一个领导者不会。)如果是这样，那么它如何知道可以提交它？
在#2中，如果领导者在提交之前崩溃，那么所有其他节点在提交后崩溃，然后在选举中，旧领导者再次成为新领导者，然后其他服务器已提交该条目新领导没有。在这种情况下会发生什么？
最佳答案
请务必注意存储在服务器上的条目、正在提交的条目和正在应用的条目之间的区别。 promise 实际上是一个理论概念。在大多数情况下，服务器不执行任何操作来提交条目。这是因为它存储在大多数服务器上，因此保证不会丢失。条目可以在提交时应用，也可以在稍后的某个时间应用，只要服务器按顺序应用它们即可。
由于分布式系统的性质，所有服务器不可能同时提交条目。相反，Raft 仅保证当领导者将条目应用到其状态机时，该条目会持久在大多数服务器上。大多数 Raft 实现都采用方法#1，以便允许领导者将命令应用到其状态机，并在其他服务器必须将命令应用到其状态机之前响应客户端。
如果领导者应用命令然后失败，会发生什么:
* We know that the command has been stored on a majority of servers therefore...
* Raft's election algorithm guarantees that the next server that's elected has that entry
* When the next leader is elected, it will append a no-op entry to its log and commit it
* Once the no-op entry is committed, the leader will increase its commitIndex to that of the no-op entry and thereby commit all entries remaining from the previous term (including the original leader's last commit)
* On the next heartbeat, the leader will send the index of the no-op as the `commitIndex`
* Remaining followers will be replicated entries up to the leader's no-op and commit entries from the previous leader's term
这有意义吗？
因此，需要注意的是，即使领导者没有机会通知追随者条目已提交，Raft 也会保证下一个领导者将拥有第一个领导者已提交的条目，并且该领导者最终将获得第一个领导者提交的条目。将这些条目复制到尚未拥有它们的追随者，并且提交索引将继续超出前一个领导者的最后一个索引。
引用文献: 有关提交先前条款条目的信息，请参阅 Raft 论文 ( https://ramcloud.atlassian.net/wiki/download/attachments/6586375/raft.pdf ) 的第 5.4.2 节
关于consensus - RAFT 中是否存在竞争条件？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32250879/