标签: raft

这可能是一个非常简单的问题，但我还没有找到一个好的答案。也许有人可以帮助我。

一旦选举出领导人——

1. 客户端只会将所有请求发送给领导者。这样对吗？
2. 鉴于领导者的位置（实际上是 IP 地址）是动态的，客户端如何知道集群中的这个 IP 地址？

我有两个不同的独立网络。一个有两个组织和两个排序者，第二个有三个组织和三个排序者。如果我想在两个网络的 type=Raft 中拥有所有五个排序器，我应该如何配置它？

我知道订购者可以处理多个渠道，但是多个网络呢？（我猜问题出在创世块上）

func resetElectionTimeoutMS(newMin, newMax int) (int, int) {
    oldMin := atomic.LoadInt32(&MinimumElectionTimeoutMS)
    oldMax := atomic.LoadInt32(&maximumElectionTimeoutMS)
    atomic.StoreInt32(&MinimumElectionTimeoutMS, int32(newMin))
    atomic.StoreInt32(&maximumElectionTimeoutMS, int32(newMax))
    return int(oldMin), int(oldMax)
}

我得到了这样的代码函数.我感到困惑的是:我们为什么需要atomic这里？这是什么阻止了？

谢谢.

我读到当前的主要选举算法如Raft,Paxos或Zab如何选择群集上的主人,并且无法理解为什么他们使用复杂的算法而不是简单的欺负算法.

我正在开发一个集群库,并使用UDP Multicast来处理心跳消息.每个节点都加入一个多播地址,并定期向该地址发送数据报包.如果节点发现有一个新节点将数据包发送到此多播地址,则该节点只是添加到集群中,类似地,当集群中的节点没有从节点获取任何程序包时,它们会将其从集群中删除.当我需要选择一个主节点时,我只需遍历集群中的节点并选择最旧的节点.

我阅读了一些文章,暗示这种方法无效,应该使用像Paxos这样的更复杂的算法,以便通过心跳消息选出主控或检测故障.我无法理解为什么Paxos比传统的欺负算法更适合裂脑情况或其他网络故障,因为我可以很容易地发现当法定数量的节点离开集群而不使用Raft时.我看到的唯一好处是每个服务器必须处理的数据包数量; 只有master在Raft中发送心跳消息,而在这种情况下,每个节点都必须向对方发送心跳消息.但是我不认为这是一个问题,因为我可以简单地实现类似的心跳算法而不改变我的主选举算法.

有人可以详细说明吗？

最近读了一篇关于Raft共识算法的论文。新的领导者不知道当前的提交索引是什么。

无操作如何 解决这个问题？

我正在尝试实现 Raft 共识算法。以下是我每次设置服务器状态的一般term理解votedFor：

1. 启动时term为 0 并且votedFor是null
2. 服务器选举超时后，该服务器将成为候选者，将其加term1，并将其设置votedFor为自身。
3. 当服务器收到一个比自己更高的RequestVoteRPC时，它应该将 更新为观察到的数字，然后更新到发送者，前提是接收服务器有一个of并且其日志不比发送者的日志更新。termtermvotedForvotedFornull
4. 当 Candidate 收到AppendEntriesRPC，并且发送者的状态term高于或等于自己的 RPC 时，Candidate 应该将其更新term为发送者的状态term，然后将其设置votedFor为发送者，并将其状态变为 Follower，从而承认发送者为其合法的领导者。
5. 在所有其他情况下，当服务器接收到任何包含term高于其自身的 RPC 请求或响应时，它应该将自己的值设置term为接收到的服务器的值term并设置votedFor为null。

这些一起构成了Raft 正确实现中仅有的 5 种方式吗？这些情况是否被正确总结term？votedFor我对此感到困惑，因为论文仅提到在某些时候节点将转换为追随者，而没有指定是否votedFor应该是具有较高术语或的发送者的值null。我担心情况4是错误的，应该是这样的：如果AppendEntries发送者的术语更大，那么接收者应该将其更新term为发送者的术语，然后设置votedFor为发送者，无论接收者是否是追随者、候选者或过时的领导者。

在论文 \xe3\x80\x8a In Search of an Understanding Consensus Algorithm \xe3\x80\x8b 中，图 8 显示了（d）和（e）中的一个问题，即一些旧日志可能会被覆盖并且永远不会回来。

在第 5.4.2 节中，它说\xe2\x80\x9c 为了消除如图 8 中的问题，Raft 从不通过计算副本来提交前一项的日志条目。通过计算副本数，仅提交来自leader\xe2\x80\x99s当前任期的日志条目；一旦以这种方式提交了当前术语中的条目，则由于 Log Matching Property\xe2\x80\x9d ，所有先前的条目都会间接提交。

我对这部分感到困惑，它在图 8 中是如何工作的？什么会发生，什么不会发生？

我对分布式系统还很陌生，想知道 Raft 共识算法是如何线性化的。Raft 通过仲裁提交日志条目。当领导者 Raft 提交时，这意味着超过一半的参与者拥有复制的日志。但可能有一部分参与者没有最新日志，或者他们有日志但没有收到提交这些日志的指示。

或者 Raft 的读取线性化是否需要读取法定人数？

在 raft 的论文文档第 6.4 章中，给出了绕过 Raft 日志进行只读查询并仍然保持线性化的步骤：

\n

\n
1. 如果领导者尚未将当前任期中的条目标记为已提交，它将等待直到完成此操作。领导者完整性属性保证领导者拥有所有已提交的条目，但在其任期开始时，它可能不知道这些条目是哪些。为了找出答案，\n 它需要从其术语中提交一个条目。Raft 通过让每个领导者在其任期开始时向日志中提交一个空白的无操作条目来处理此问题。一旦提交此无操作条目，领导者\xe2\x80\x99s\n 提交索引将至少与其任期内的任何其他服务器\xe2\x80\x99 一样大。
\n
2. 领导者将其当前提交索引保存在局部变量 readIndex 中。这将用作查询操作所针对的\n 状态版本的下限。
\n
3. 领导者需要确保它没有被它不知道的新领导者取代。它发出新一轮的心跳并等待大多数集群的确认。一旦收到这些确认，领导者就知道在发送心跳时，不可能存在更长时间的领导者。因此，readIndex 当时是集群中任何服务器见过的最大提交索引。
\n
4. 领导者等待其状态机至少前进到 readIndex；这足以满足线性化要求。
\n
5. 最后，领导者对其状态机发出查询，并将结果回复给客户端。
\n

\n

我的问题：

a) 对于步骤1，是否仅适用于刚刚选举出领导者时的情况？因为只有新领导者在当前任期内没有承诺加入。并且由于无操作条目对于找出当前提交的条目是必要的，那么实际上在选举完成后总是需要这一步，而不仅仅是特定于只读查询？换句话说，通常，当领导者处于活动状态一段时间时，它必须在其任期内提交条目（包括无操作条目）。

b) 对于步骤 3，这是否意味着只要领导者需要提供只读查询，就会发送一个额外的心跳，无论当前未完成的心跳（已发送但尚未收到主要响应）或下一个计划的心跳？

c) 对于步骤 4，是否仅适用于关注者（对于关注者帮助卸载只读查询处理的情况）？因为在领导者上，提交的索引已经意味着它已应用于本地状态机。

总而言之，正常情况下，领导者（活跃一段时间）只需要执行步骤3和步骤5，对吗？

共识算法（例如 raft）要求集群包含奇数个节点以避免裂脑问题。

假设我有一个由 5 个节点组成的集群，如果只有一个节点发生故障会发生什么？集群现在有4个节点，打破了奇数规则，集群会继续正常运行吗？

一种解决方案是再删除一个节点，使集群只包含 3 个节点，但是如果之前出现故障的节点又回来了怎么办？那么集群又有了 4 个节点，为了保持集群奇数，我们必须将之前丢弃的节点带回来。

共识算法的实现是自动处理这个问题，还是我必须在我的应用程序代码中这样做（例如，删除一个节点）？