当所有关注者更新提交索引之前，领导者崩溃会发生什么？
例如，节点A，B，C形成集群：
只有A和B活着，A是领导者
A复制一个条目（让他们说它的条目1）到B并从B获得成功
提交entry1，并在将心跳消息发送给B之前崩溃（这会导致B更新其提交索引）
C现在在线
我的问题是：
我知道筏子规格说：
Raft使用更简单的方法保证所有的 来自先前条款的承诺条目出现在每个新领导者身上 从选举的那一刻起，无需转移那些 领导的条目。
但是这里的entry1可能不被视为已提交的条目？因为B没有得到老领导的确认（来自领导者的心跳）。那么C有机会成为新的领导者吗？
答案 0 :(得分：8)
重要的是要注意，一旦条目在群集中的大多数服务器上存储，就会被视为已提交（在技术上有一些警告，但对于此对话，我们应该假设这是这种情况）而不是节点收到来自领导者的提交消息。如果需要提交消息来考虑提交的条目，则每次提交都需要两次往返 - 一次用于复制，一次用于承诺 - 并且必须保留提交索引。
相反，在您的方案中，当A崩溃且C恢复时，筏选举算法将确保C无法被选为领导者，因此C无法删除已提交的条目。只有B可以被选为领导者，因为它具有最新的日志。如果C尝试获得当选的领导者，那么B只会收到被拒绝的投票，因为B的日志比C更新了（它有承诺的条目）。因此，您将在实践中看到B最终将被选出，并将提交其前一个词的所有条目，此时该条目仍将被提交。即使B崩溃并且A要恢复，A仍然会有比C更新的日志，因此它将再次被选举领导者。
当（而不是）B成为领导者时，首先确保先前条款中的条目存储在大多数服务器上，然后再提交任何服务器从当前任期开始。通常，这是通过在新领导者任期开始时提交无操作条目来完成的。从本质上讲，新的领导者提交了一个no-op条目，一旦该条目存储在大多数服务器上，它就会增加其提交索引，并将新的提交索引发送给所有关注者。因此，该条目不会丢失。新领导人将确保承诺。
在Raft论文和解析中都描述了考虑存储在大多数群集上的条目的注意事项。