在仲裁系统中撤消部分写入

问题描述

假设一个法定人数系统有 5 个节点，读写法定人数为 3。现在，假设一个客户端发送一个写入请求 w，并且 w 被复制到 2/5 个节点上。由于我们没有在至少 3/5 个节点上进行复制，我们告诉客户端写入不成功。现在，紧接着，未复制写入的 2 个节点关闭。所以，在剩下的 3 个节点中，2 个有部分写入，1 个没有。在这种情况下，系统如何判断部分写入 w 需要撤消，因为它实际上没有成功完成？

解决方法

在大多数系统中，3/5 意味着该值被选择且不得撤消。

不同的协议和系统以不同的方式处理这个问题。

在ABD中，下一个读取将从一个节点学习值并将其传播到其他两个剩余节点。

类似地，在 Paxos 中，下一个提议者将从该节点学习值并将其传播给其他两个节点。在基于 Paxos 的实际系统中，会有一个系统（可能是领导者）会产生一个no-op提案，以确保及时传播价值。

在像 Raft 这样的领导选举/主副本系统中，领导将确保传播到副本。那当然是除非它是死者之一。在这种情况下，选举过程通常要求新领导者是最新的，在这种情况下将包括有争议的值。

,

这是您在构建分布式系统以检查如何管理未发送到所有所需节点的故障或事件时需要考虑的常见情况。

Leader 有责任确保事件被成功发送到在事件被视为提交之前定义的最小法定人数[应该有一个带有该事件 ID 哈希码的标志]，并且该事件不符合重试条件。

>

当一个请求进入图片以从分布式系统中获取数据时；它总是交给一个领导者，领导者将通过它的哈希码将请求委托给节点附近。但是在委托之前，Leader 必须确保 Commit Flag 为 TRUE（意味着事件被传递到最少定义的节点）。否则，Leader 可以抛出异常。

此外，Leader 应该在事件上标记一个版本号，并保留当前提交的标志版本号。在检索事件时，Leader 可以比较事件版本，以确保所有节点都提供最新和最大的数据。

您可以从 Zookeeper 等系统中看到开箱即用的功能。