RAFT算法中是否可能出现Lost update（丢失更新）？

场景回顾 #

我们有一个5节点的Raft集群，初始leader为A，发生以下事件：

• A向所有follower并行发送复制变更请求
• 仅B收到该请求，C-E在接收前崩溃或发生网络分区
• Leader A多次尝试获取多数派确认失败后崩溃
• C-E重新上线，选举超时后，B、C、D、E参与选举
• C成为候选节点，获得C、D、E的多数派支持赢得选举
• B中未提交的写入丢失

结论：该场景完全可能发生 #

原因分析 #

1. 未提交日志的特性：Raft协议要求leader必须收到多数派（5节点中至少3个）的日志复制确认，才能提交该日志条目。此场景中，A仅完成了向B的日志复制，远未达到多数派确认的要求，因此这条日志始终处于未提交状态。
2. 选举规则的约束：C-E恢复后，它们的日志中没有这条未提交的日志，而B的日志包含该条目但未被提交。Raft选举时，候选者只需获得多数派选票即可当选，C可以轻松获得C、D、E的三票（满足多数派要求），无需获得B的支持。
3. 日志同步逻辑：C当选新leader后，会将自己的日志作为基准，要求所有follower（包括B）同步对齐自己的日志。由于B中的未提交日志在新leader的日志中不存在，这条日志会被新leader的日志覆盖，最终导致丢失。

内容的提问来源于stack exchange，提问作者Tarun