Apache zookeeper 在分布式存储中实现线性化是否需要复制日志

etcd使用的Raft算法和Zookeeper使用的ZAB算法都使用复制日志更新状态机

我想知道是否有可能通过简单地使用领导人选举和版本化的值来设计类似的系统。以及为什么这些系统决定使用复制日志

如果我们有以下设置，我将举我的例子

• 机器A（引线），包含版本1
• 机器B（从动件），包含版本1
• 机器C（从动件），包含版本1

写的是这样的：

机器A接收写入请求并存储挂起的写入V2

机器A向机器B和机器C发送准备请求

追随者（机器B和机器C）向领导者（机器A）发送确认

在领队（机器A）收到来自机器仲裁的确认后，它知道V2现在已提交，并向客户端发送成功响应

领队（机器a）向跟随者（机器a和机器B）发送完成请求，通知他们V2已提交，V1可能被丢弃

---

为了使该系统能够工作，在获取leader Lease后进行leader change时，leader机器必须在接受请求之前通过读取节点的仲裁来获取最新的数据版本

你的例子很有道理。但是，您是否考虑过所有可能的故障情况？在步骤2中，由于网络分区或路由器故障，机器B可能在机器C之前或之后几分钟收到消息（反之亦然）。在步骤3中，确认可能会丢失、延迟或重新发送多次。领导人也可能失败，并在同一轮协商一致中重新站起来一次、两次或可能几次。在步骤5中，消息可能丢失、重复，或者机器A&C可能在B未收到通知时收到通知

概念上的简单性，也称为“减少潜在故障点”，是分布式系统的关键。任何事情都可能发生，在现实环境中也会发生。原语，例如基于在任何环境中被证明是正确的一致性协议的复制日志，是建立更高层次抽象的坚实基础。当然，定制的算法可以实现更好的性能、延迟或“感兴趣的指标”，但确保这种算法的正确性是一项重大的时间投资

复制日志简单、易于理解、可预测，并且完全属于已建立的共识协议（paxos、paxos变体和raft）的范畴。这就是为什么它们很受欢迎。这并不是因为它们是任何特定应用程序的最佳选择，而是因为它们被理解和可靠

有关参考资料，您可能对和感兴趣

ETCD中的raft算法和Zookeeper中的ZAB算法都使用复制日志更新状态机。 我想知道是否有可能通过简单地使用领导人选举和版本化的值来设计类似的系统

是的，不需要日志复制就可以实现一致性/线性化。最初，Leslie Lamport（1998）在论文中解决了共识问题。他描述了两种算法：单命令Paxos构建分布式线性化一次写入寄存器，多命令Paxos在append only log（一次写入寄存器的有序数组）之上构建分布式状态机

仅追加日志比一次性写入寄存器更强大，因此人们选择日志而不是寄存器也就不足为奇了。此外，在（2009）发表之前，日志复制是唯一能够改变集群成员身份的一致协议；对于多个任务来说，什么是至关重要的：如果您不能替换失败的节点，那么最终您的集群将变得不可用

然而，这是一篇很好的论文，通过联合共识，我更容易理解集群成员的概念，所以我写了一篇关于如何将Raft的方式应用于单一法令Paxos的文章

随着时间的推移，单指令Paxos的“一次写入”特性也得到了解决，将一次写入寄存器转换为分布式线性化变量，这是一个非常强大的抽象，适用于许多用例。在野外，我在野外看到了这种方法。如果你感兴趣的话，我会在博文中介绍这个改进的SDP

因此，当我们有一个替代日志时，考虑它是有意义的，因为基于日志的复制是复杂的并且有内在的限制：

• 对于日志，您需要关心日志压缩和垃圾收集
• 日志的大小受一个节点的大小限制
• 用于拆分日志和迁移到新集群的协议并不广为人知

以及为什么这些系统决定使用复制日志

基于日志的方法比其他方法更老，因此它有更多的时间获得流行

关于你的例子

很难对其进行评估，因为您没有描述领导人选举是如何发生的，领导人之间的冲突是如何解决的，处理失败的策略是什么，以及如何改变集群的成员资格

---

我相信如果你仔细描述一下，你会明白的。

我实际上是在假设领导人选举本身会使用paxos。并且很想知道如果写入值包含前导历元和值版本号，写入本身是否也需要使用paxos或simple quorum就足够了。