木筏：提交的条目可能会丢失？
raft: committed entry may be lost?
当领导者在所有追随者更新提交索引之前崩溃时会发生什么？
例如节点A、B、C组成集群：
只有A和B活着，A是领导者
A 复制一个条目（假设它是 entry1）到 B 并从 B 得到成功的结果
A 提交 entry1，并在向 B 发送心跳消息之前崩溃（这将导致 B 更新其提交索引）
C在线
我的问题是：
- C会被选为新的leader吗？如果是这样，那么 entry1 丢失了吗？而且如果A后面重新加入，会不会和别人的数据不一致？
我知道 raft 规格说：
Raft uses a simpler approach where it guarantees that all the
committed entries from previous terms are present on each new leader
from the moment of its election, without the need to transfer those
entries to the leader.
但是这里entry1可能不被认为是committed entry？因为 B 还没有得到老领导的确认（来自领导的心跳）。所以 C 有机会成为新的领导者？
- 如果B成为新的leader，那么它应该如何处理entry1？
重要的是要注意，一旦条目在集群中的大多数服务器上 存储 就被视为已提交（从技术上讲，这有一些注意事项，但对于这次对话，我们应该假设是这种情况），而不是当节点从领导者那里收到提交消息时。如果需要提交消息来考虑已提交的条目，那么每次提交都需要两次往返 - 一次用于复制，一次用于提交 - 并且必须保留提交索引。
相反，在您的场景中，当 A 崩溃并且 C 恢复时，Raft 选举算法将确保 C 不能被选为领导者，因此 C 不能丢弃提交的条目。只有 B 可以被选为领导者，因为它拥有最新的日志。 If C tries to get elected leader, it will receive only a rejected vote from B since B's log is more up-to-date than C's (它具有已提交的条目）。因此，您将在实践中看到 B 最终将被选出并将提交其先前任期的所有条目，届时该条目仍将被提交。即使 B 然后崩溃并且 A 恢复，A 仍然会有比 C 更新的日志，因此它会再次被选中领导者。
当（不是如果）B成为领导者时，它将首先确保存储先前任期的条目在提交当前任期的任何条目之前，在大多数服务器上。通常这是通过在新领导者任期开始时提交一个空操作条目来完成的。本质上，新领导者提交了一个无操作条目，一旦该条目存储在大多数服务器上，它就会增加其提交索引并将新的提交索引发送给所有跟随者。因此，该条目不会丢失。新领导将确保它得到承诺。
Raft 论文和论文中都描述了考虑将存储在大多数集群上的条目提交的注意事项。
当领导者在所有追随者更新提交索引之前崩溃时会发生什么？
例如节点A、B、C组成集群：
只有A和B活着，A是领导者
A 复制一个条目（假设它是 entry1）到 B 并从 B 得到成功的结果
A 提交 entry1，并在向 B 发送心跳消息之前崩溃（这将导致 B 更新其提交索引）
C在线
我的问题是：
- C会被选为新的leader吗？如果是这样，那么 entry1 丢失了吗？而且如果A后面重新加入，会不会和别人的数据不一致？
我知道 raft 规格说：
Raft uses a simpler approach where it guarantees that all the committed entries from previous terms are present on each new leader from the moment of its election, without the need to transfer those entries to the leader.
但是这里entry1可能不被认为是committed entry？因为 B 还没有得到老领导的确认（来自领导的心跳）。所以 C 有机会成为新的领导者？
- 如果B成为新的leader，那么它应该如何处理entry1？
重要的是要注意，一旦条目在集群中的大多数服务器上 存储 就被视为已提交（从技术上讲，这有一些注意事项，但对于这次对话，我们应该假设是这种情况），而不是当节点从领导者那里收到提交消息时。如果需要提交消息来考虑已提交的条目，那么每次提交都需要两次往返 - 一次用于复制，一次用于提交 - 并且必须保留提交索引。
相反，在您的场景中，当 A 崩溃并且 C 恢复时，Raft 选举算法将确保 C 不能被选为领导者，因此 C 不能丢弃提交的条目。只有 B 可以被选为领导者，因为它拥有最新的日志。 If C tries to get elected leader, it will receive only a rejected vote from B since B's log is more up-to-date than C's (它具有已提交的条目）。因此，您将在实践中看到 B 最终将被选出并将提交其先前任期的所有条目，届时该条目仍将被提交。即使 B 然后崩溃并且 A 恢复，A 仍然会有比 C 更新的日志，因此它会再次被选中领导者。
当（不是如果）B成为领导者时，它将首先确保存储先前任期的条目在提交当前任期的任何条目之前，在大多数服务器上。通常这是通过在新领导者任期开始时提交一个空操作条目来完成的。本质上，新领导者提交了一个无操作条目，一旦该条目存储在大多数服务器上，它就会增加其提交索引并将新的提交索引发送给所有跟随者。因此，该条目不会丢失。新领导将确保它得到承诺。
Raft 论文和论文中都描述了考虑将存储在大多数集群上的条目提交的注意事项。