问题标签 [raft]

看了paxos和raft论文后，我有以下困惑：paxos论文只描述了对单个日志条目的共识，相当于raft算法的leader选举部分。在 raft 的 leader 选举中，paxos 的方法相对于简单的随机超时方法有什么优势？

在牛皮纸第 5.4.2 节

如果领导者在提交条目之前崩溃，未来的领导者将尝试完成复制条目。但是，领导者不能立即断定上一任期的条目一旦存储在大多数服务器上就已提交。可能存在这样一种情况，即旧的日志条目存储在大多数服务器上，但仍可能被未来的领导者覆盖。

作者提到为了避免上述情况

为了消除图 8 中的问题，Raft 永远不会通过计算副本来提交先前条款的日志条目。只有来自领导者当前任期的日志条目通过计算副本来提交；一旦以这种方式提交了当前术语中的条目，则由于日志匹配属性，所有先前的条目都将间接提交。

但是不会还是会出现同样的问题吗？

鉴于作者提供的以下情况

当S5被选为领导者时，它只查看其当前提交的日志，(term3, index1)这将覆盖term2所有追随者中的条目。

让领导者查看自己的提交日志如何解决问题？

我使用以下pdf作为参考。

它说这lastApplied是应用于状态机的最高日志条目，但这与commitIndex?

领导者也matchIndex只是追随者的commitIndex吗？如果不是，有什么区别？

在官方raft 网页中考虑这个模拟

为什么term 2 index 1尽管没有提交S2 (leader)，S3并且S4同意日志？我运行了几分钟以确保所有通信都已进行。

奇怪的是，如果我再添加一个日志条目term 6 index 2，那么term 2 index 1将被提交。

有谁知道阻止term 2 index 1提交的规则是什么？

考虑三个节点（A、B、C）获取键/值数据。并发生了以下步骤

1. 节点 A 接收 key:value (1:15)。它是一个领导者
2. 它复制到节点 B 和节点 C
3. 在预提交日志中对节点 B 进行的条目
4. 节点 C 未能进入
5. 来自节点 B 的 Ack 丢失。
6. Nod A 输入失败并将失败发送给客户端
7. 节点 A 仍然是领导者，而 B 不在仲裁中
8. 客户端从节点 A 读取键 1 并返回旧值。
9. 节点 A 已关闭
10. 节点 B 和节点 C 已启动
11. 现在节点 B 在预提交日志中有一个条目，而节点 C 没有。

此时日志匹配是如何发生的。节点 B 是要提交该条目还是要丢弃它。如果它要提交，那么它会被读取不一致或者如果它要丢弃，那么在其他情况下可能会丢失数据

我们正在尝试在聊天应用程序中实现 Raft。据我所知，Raft 是用于复制的，仅此而已。那么当一个客户端想要连接到聊天服务器与另一个客户端聊天时，Raft 是否要求所有客户端都只连接到领导者？如果是，如果它连接到一个追随者，追随者可以将其重定向到领导者。但是然后呢？领导者是否再次将其分配给跟随者节点，即领导者本质上是否也充当负载平衡器，或者它是否通过在所有其他服务器上复制用户数据来完成所有工作？

我无法在 Ubuntu 中使用 scons 和 protobuf3 构建 LogCabin (C++) 的 RAFT 实现。

错误就像

请建议我如何进行。！

我想将 consul 用于 2 节点集群。缺点是两个节点没有容错能力：

https://www.consul.io/docs/internals/consensus.html

Consul 有没有办法只用两个节点进行一致的领导者选举？Consul Raft Consensus 算法可以改吗？

非常感谢。

在 HappyFunPizzaCorp 中，我们有一个 POS 系统，它生成两个事件：new_order事件和payment事件。这两个事件都包含一个用于交叉引用的披萨order_id键。

两个事件都被发送到一个交换器TheExchange。new_order事件总是在payment事件之前发出。

我们是一个非常繁忙的地方，例如每秒销售 100000 个比萨饼，因此不能选择串行处理所有记录。

所以问题是我们如何并行处理我们的工作负载，同时仍然保证在同一个披萨的事件new_order之前处理事件？payment

具有多个消费者的简单队列是行不通的。我们得到消费者之间的循环行为，因此事件可能与同一个披萨payment的事件同时处理。new_order

另一种解决方案是使用分片交换并将order_id用作分片键。虽然这听起来不错，但我们现在在队列之间有了一些内在的并行性，我们的消费者如何连接？我们可以有一组预定义的队列来防止由于重新分片而导致消息之间的重新分片和并行性。但是如果我们有多个消费者实例，他们如何决定使用哪些队列来消费数据。最重要的是，我们希望自动扩展我们的消费者。

我们当前的解决方案是使用共识协议（通过 zookeeper 的 raft/paxos）来确定每个消费者进程应该服务的队列数量和队列。我们在系统中有一个预设的（大量）分片队列，它们不应该改变。队列的消费者是排他的（最多提供一次交付保证），他们通过共识协议协调哪些队列应该由谁服务。

虽然这个设置似乎可以工作，但它似乎过于复杂，我想知道是否有我们缺少的参考解决方案。

请任何人澄清“完全异步协议协议”中的第 3 步（见下文）：

过程 P：初始值 xp。

• 步骤0：设置r := 1。
• 第 1 步：将消息发送(1, r, xp)到所有进程。
• 第 2 步：等到收到N - t, 类型(1, r, x)的消息。如果多个N/2消息具有相同的值v，则将消息发送(2, r, v, D)到所有进程。否则将消息发送(2, r, ?)到所有进程。
• 第 3 步：等待N - t类型的消息(2, r)到达。
  • (a) 如果有一个 D 消息(2, r, v, D)，则设置xp := v。
  • (b) 如果有多个tD 消息，则决定v。
  • (c) 其他集合xp = 1或0每个集合的概率为 1/2。
• 第 4 步：设置r := r + 1并转到第 1 步。

我对这个协议的理解如下。

在第一步中，每个节点都会通知其他每个节点其状态。

在第二步，每个节点决定它是否“看到”了足够的信息来确定值，换句话说，它等待多数。如果多数具有相同的值，它会开始广播此信息，例如“我看到多数认为v”。否则，它会发送消息，表明它没有下定决心。

最后，在第三步中，我们检查是否有多个t“决定性”消息（如果t节点的消息无法传递，则至少会有一个“决定性”消息）。但我不明白为什么我们xp := v只在收到一条D 消息时才设置。接收两个 D 消息属于 3c，在这种情况下，我们将为 v 分配随机值。为什么？

为什么我们不能像这样描述第三步：

• (a) 如果 D 消息为零，则以 1/2 的概率设置xp = 1或0每个。
• (b) 如果有多个tD 消息，则决定v。
• (c) 其他设置xp := v。