问题标签 [raft]

在 Raft 算法中，项总是在增加。有什么好的办法可以解决这个问题，防止以后期限达到极限吗？因为我用的是tinyint类型的term，又不想修改类型，一分钟就会有一轮选举，所以term会快速增长。

我想在follower收到心跳后修改term=0，但是这样不行。

我目前正在自己​​实现 Raft 共识算法，我遇到了以下问题。考虑有 4 个节点（A、B、C 和 D），因此可以提交超过 2 票的日志条目。现在我们启动集群并让 Leader A 用term = 0. 然后发生以下事情：

1. 从动 B/D 断开。
2. 领导者 A 创建LogEntryX。
3. 领导者 A 尝试复制到所有节点并最终失败，因为只有 2 个节点（A 和 C）。
4. 节点 B 重新连接并超时，它使用 new 开始选举term = 1。
5. 节点 A 失去了领导地位，因为它收到了节点 B 的RequestVoteRPC。
6. Node B can't win the election, because it has no LogEntryX. So there are no Leader in the cluster.
7. 节点A超时，再次被选为Leader。
8. Leader A 成功将 X 复制LogEntry到 B。

9. 现在节点 A/B/C 具有完全相同的LogEntryX，即(index = 0, term = 0). 然而，根据 Raft 论文，Leader A 不能提交 X，尽管它是自己生成的，并且多数同意 X。

   Raft 永远不会通过计算副本来提交先前条款的日志条目。只有来自领导者当前任期的日志条目通过计算副本来提交；

10. 假设不再有LogEntry来自客户端的 s 来复制，所以LogEntryX 保持未提交。

我的问题是：

1. 这是一个真正的问题吗？
2. 有一些解决方案吗？事实上，已经有一些关于 SoF 的帖子强调了这条规则的重要性。在这篇文章中，似乎说我们可以创建 X 的副本 Y，并复制 Y。它是否有效，或者是否存在通用解决方案？

最近在用RAFT搭建一个分布式系统，实现一个简单的功能就是将日志条目复制到每台服务器，以保持数据的一致性，所以我的问题是在RAFT中所有节点都登录的时候如何安全的删除历史日志条目已提交。

我正在尝试测试在现有仲裁网络中添加新节点。有没有其他方法可以做到这一点，而无需去 geth 控制台并执行 admin.addPeer()。

是否存在任何 API，我可以在其中调用和添加新的对等点，以便它可以相应地同步。

在实现 Raft 算法时，我发现有一种情况我认为可能对集群造成伤害，也可能不会。

假设一些来自 Leader 的 AppendEntriesRPC 被重新排序（网络延迟或其他原因）是合理的。考虑领导者向对等点 A 发送心跳 AppendEntriesRPC，使用prev_log_index = 1，然后发送另一个带有条目 2 的 AppendEntriesRPC，然后它崩溃（我确保通过我的测试中的回调立即发生这种情况）。如果两个 RPC 按发送顺序处理，则条目 2 将成功插入。但是，如果心跳 RPC 延迟，那么 peer A 会首先插入 entry 1 并响应 Leader。然后是延迟的心跳，peer A 将删除条目 2，因为该条目与 Le​​ader 的 冲突prev_log_index = 1。所以对等体 A 错误地删除了一个日志条目。

再深入一点，如果Leader不立即崩溃，它会解决这个问题吗？我认为如果 peer A 正确响应延迟的心跳，Leader 会在以后的一些 RPC 中发现并修复它。

但是，如果对等体 A 对条目 2 的响应导致commit_index前进怎么办？在这种情况下，节点 A 投票支持前进commit_index到 2，即使它实际上没有条目 2。因此可能没有足够的票数来支持前进。现在当Leader崩溃时，日志较少的节点将被选为Leader。我在测试过程中确实遇到过这种情况。

我的问题是：

1. 我的推理正确吗？
2. 如果重新排序 RPC 是一个真正的问题，我应该如何解决？对所有 RPC 进行索引和缓存，并强制它们一一处理是一个好的解决方案吗？我发现在 gRPC 中很难实现。

我了解基本的 raft 协议以及它如何实现强一致性。但是在我看来，要实现真正的一致性，您需要在每次写入时使用 fsync（不仅在领导者上，而且在追随者上），因为如果您不这样做，即使您认为自己处于安全区大多数“已提交”，这些日志将来可能会丢失，因为它们仍在页面缓存中。

但是在每次写入时使用 fsync 会使系统性能下降几个数量级。

所以我想知道如果我的理解是错误的，他们如何解决权衡或向我解释。

使用 raft 时，在提交日志条目后，我们应该将节点提出的数据写入我们的存储中。如果其中一个节点写入失败怎么办。假设磁盘坏了。故障节点是否应该自行终止？

在诸如 PAXOS 和 RAFT 之类的共识算法中，会提出一个值，如果法定人数同意，则将其持久地写入数据存储。在达到法定人数时无法参加的参与者会怎样？他们最终如何赶上？无论我在哪里看，这似乎都留给读者作为练习。

我正在阅读有关 raft 的信息，但在网络分区后达成共识时我有点困惑。

因此，考虑一个包含 2 个节点、1 个领导者、1 个跟随者的集群。

在分区之前，那里有X条消息写入，成功复制，然后想象网络问题导致分区，所以有2个分区，A（前领导）和B（前跟随），现在都是领导（接收写入):

在分区事件之后，我们已经弄清楚了，会发生什么？

a) 我们选出 1 个新的领导者并考虑它的日志？（删除新追随者的消息？例如：

甚至：

（取决于哪个节点成为领导者）

b) 我们选出一个新的领导者，并找到一种方法来就所有信息达成共识？

如果是b，有什么具体的方法吗？还是取决于客户端的实现？（例如：消息时间戳...）

1. 假设有 7 个节点N1, N2, ...N7的集群，状态为x=2
2. 假设N1是领导节点
3. 然后客户端发送x=5到领导节点N1，N1复制x=5到节点N6 和 N7（未提交），但是N2~N5 没有收到这个 RPC

4. 这时，N1 崩溃了，所以，触发了新的选举，我的问题如下：

   • 如果N6 赢得这次选举，集群中的状态将是x=5（未提交将变为已提交）
   • 如果N2 赢得这次选举，集群中的状态将是x=2（N6/N7 中未提交的将被丢弃）

我是不是误会了什么？谢谢！