Zookeeper使用的Raft算法和Zookeeper使用的ZAB算法都使用复制日志来更新状态机。
我想知道是否可以通过简单地使用领导者选举和版本化值来设计类似的系统。为什么这些系统决定使用复制日志。
我的例子，如果我们有以下设置
写作会像这样：
要使此系统正常工作，在获得领导者Lease之后领导者更改时，领导者必须通过在接受请求之前从法定数量的节点读取来获取最新数据版本。
答案 0 :(得分：4)
ETCD中的筏算法和Zookeeper中的ZAB算法都使用复制日志来更新状态机。 我想知道是否可以通过简单地使用领导者选举和版本化值来设计类似的系统。
是的，在没有日志复制的情况下，可以实现共识/线性化。最初，共识问题在Leslie Lamport（1998）的Paxos Made Simple论文中得到了解决。他描述了两种算法：单一法令Paxos，用于构建分布式线性化一次写入寄存器，以及Multi-Paxos，以便在仅附加日志（一次写入寄存器的有序数组）之上构建分布式状态机。
仅附加日志比一次写入寄存器更强大的抽象，因此人们选择日志通过寄存器并不令人惊讶。此外，在Vertical Paxos（2009）发布之前，日志复制是唯一能够进行集群成员变更的共识协议;对于多个任务至关重要的是：如果您无法替换失败的节点，那么最终您的群集将变得不可用。
然而Vertical Paxos是一篇很好的论文，通过联合共识来理解群集成员资格的Raft's概念要容易得多，所以我写了a post关于如何适应筏子的单一法令Paxos。
随着时间的推移，＃34;写一次＆＃34;单一法令的性质Paxos也解决了将一次写入寄存器转换为分布式线性化变量的问题，这是一个非常强大的抽象，适用于许多用例。在野外，我在Treode database看到了这种方法。如果您有兴趣，我会在How Paxos Works帖子中发布关于此改进的SDP的博客。
所以现在当我们有日志的替代品时，考虑它是有意义的，因为基于日志的复制很复杂并且具有内在的局限性：
为什么这些系统决定使用复制日志。
基于日志的方法比替代方法更老，因此它有更多的时间来获得普及。
关于您的示例
很难对其进行评估，因为您没有描述领导者选举如何发生以及领导者之间的冲突得到解决，处理失败的策略是什么以及如何更改群集的成员资格。
我相信如果你仔细描述它们，你会得到a variant of Paxos。
答案 1 :(得分：3)
你的榜样是有道理的。但是，您是否考虑过每种可能的故障情况？在步骤2中，由于网络分区或故障路由器，机器B可以在机器C之前或之后接收消息（反之亦然）。在步骤3中，确认可能丢失，延迟或重新发送多次。领导者也可能失败并在同一轮共同回合中一次，两次或可能多次回归。并且在步骤5中，消息可能丢失，重复或者机器A＆amp;当B错过它时，C可以收到通知....
概念简单，也称为＆＃34;减少潜在的故障点＆＃34;，是分布式系统的关键。任何事情都可能发生，将在现实环境中发生。基于共识协议的复制日志在任何环境中都被证明是正确的，这些基础是构建更高抽象级别的坚实基础。毫无疑问，更好的性能或延迟或您感兴趣的衡量标准是＆＃34;可以通过定制算法实现，但确保此类算法的正确性是主要时间投资。
复制日志简单，易于理解，可预测，并且整齐地落入已建立的共识协议（paxos，paxos-variants，＆amp; raft）的范围内。这就是他们受欢迎的原因。这并不是因为它们对任何特定的应用程序来说都是最好的，而是它们的理解和可靠性。
有关相关参考资料，您可能会对Understanding Paxos和Consensus in the Cloud: Paxos Systems Demystified
感兴趣