考虑三个节点(A、B、C)获取键/值数据。并发生了以下步骤
- 节点 A 接收键:值 (1:15)。这是一个领导者
- 复制到节点B和节点C
- 在预提交日志中对节点 B 进行的输入
- 节点C进入失败
- 来自节点 B 的 Ack 丢失。
- Nod A 进入失败并发送失败给客户端
- 节点A仍然是leader,B不在quorum中
- 客户端从节点 A 读取键 1 并返回旧值。
- 节点 A 宕机
- 节点 B 和节点 C 已启动
- 现在节点 B 在预提交日志中有一个条目,而节点 C 没有。
此时日志匹配是如何发生的。节点 B 是要提交该条目还是要丢弃它。如果要提交,则读取不一致,或者如果要丢弃,则在其他情况下可能会丢失数据
最佳答案
错误出现在第 8 步。每个读取操作都必须复制到其他节点,否则您可能会遇到过时数据的风险,系统应该在将虚拟值写入日志后提供读取服务。在您的情况下(B
离线),“读取”必须影响节点 A
和 C
,因此当节点 B
重新上线并且 A
死亡,C
将能够使 B
的记录无效。
这是一个棘手的问题,甚至 Etcd 过去也遇到过(现在是 fixed )。
关于consensus - raft算法如何在写入失败后节点故障的情况下保持强读一致性,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/46675252/