问题标签 [raft]

我在筏子上有问题。

在论文“寻找可理解的共识算法（扩展版）”中说：

要开始选举，追随者会增加其当前任期并转换到候选状态。（在第 5.2 节中）

它还说：

在 AppendEntries RPC 和 RequestVot RPC 中，reciever 应该是“Reply false if args.term < currentTerm”

所以，让我们想象一下这个场景，raft系统中有5台机器，现在机器0是leader，机器1到4是follower，现在是term 1。突然，机器1断开网络，然后机器1超时，并且它开始领导选举，它发送 RequestVot RPC，肯定会失败（网络断开）。然后它将开始新的领导人选举......等等。机器 1 的期限是多次增加。可能增加到10。当机器1'Term增加到10时，它连接网络。并且领导者（机器0）向机器1发送心跳，机器1将拒绝心跳（机器0'期限小于机器1），现在机器1将无法重新加入系统。

我正在尝试实现一个协作画布，许多人可以在其中自由绘制或使用特定的形状工具。服务器是在 Node.js 中开发的，客户端是使用 Angular1-js 开发的（我对它们都很陌生）。我必须使用共识算法来向所有用户显示始终相同的内容。

由于找不到合适的使用教程，因此我遇到了严重的麻烦。我一直在寻找和研究 Paxos 的实现，但似乎 Raft 非常实用。

有什么建议么？我真的很感激。

当我尝试使用 impala 传输一次海量数据（约 100G）并立即选择 count(1)时，我得到了错误的总数。然后我再次执行相同的sql，总数是正确的。

我想知道除了leader change之外，还有其他内部操作会导致扫描不一致吗？如果我将 impala 配置 kudu_read_mode: READ_LATEST 更改为 kudu_read_mode: READ_AT_SNAPSHOT，那么 impala 将传输的时间戳是多少？如果 READ_AT_SNAPSHOT 可以解决问题？

我正在使用 impala 2.10.0 + kudu 1.5.0。

这真的很愚蠢，但是 zookeeper 所做的那个木筏没有 - 不是在谈论 zab，而是 zookeeper 本身。

我得到了 raft 是否领导选举等。 w 服务器但是 zookeeper 的意义何在？有没有人有类比

我在看木筏纸。

到 requestvote rpc，

接收者实现： 1. 如果 term < currentTerm (§5.1) 则回复 false 2. 如果 votedFor 为 null 或 CandidateId，并且候选人的日志至少与接收者的日志一样最新，则授予投票权 (§5.2, §5.4)

在某些情况下，候选人的任期等于领导者的currentTerm，那么领导者如何响应候选人的RequestVote rpc？

在筏子上，领导者

• 收据请求，
• 转义日志条目，
• 发送 RPC，
• 应用于状态机
• 最后回应客户。

这个过程需要一些时间，那么，如何处理下一个请求？拒绝它们？

场景 1：假设有一个 5 节点集群，其中 3 个节点已经失效。服务A(leader), B, C中有3个节点

A 向 B、C 复制了一个日志条目，收到成功的响应，提交它，应用它，响应客户端，然后死亡。现在，只有两个节点 B、C 有一些未应用的日志条目。现在，如果 D 出现，并且 B 成为新的领导者，那么未应用的条目会发生什么？它们也会被提交/应用吗？

场景二： 5个节点集群，3个刚下线，A仍然是leader，B在线

A 向 B 复制了一个条目，但无法提交，然后 A 被杀死，C、D 出现（所以 B、C、D 都出现了）。复制到 B 的条目会怎样？他们会被承诺/应用吗？

在 raft 中，当一个节点重新启动时，它会尝试重做所有日志条目以赶上状态。但是如果节点在恢复阶段再次宕机，节点会执行两次操作。如果操作不是幂等的，这两次重做操作将违反状态机。

根据上面的描述，我的问题是，在实践中使用 raft 的系统中是否需要使 ops 幂等？

我需要定期执行某些作业（比如每分钟）。如果单个节点这样做，我们就会出现单点故障。为了避免这种情况，我正在考虑以下方案：

为了实现这个唯一的领导选举是必要的。那么有没有可能我只实现了RAFT的leader选举部分并实现了呢？这种方法有什么问题吗？

更新 1 以下是错误的假设：（这不可能发生）

更新 2：不需要重新启动失败的作业

注意：我可以使用 Zookeeper 或类似的东西来实现这一点，但我的目标是编写自己的

在 raft 的论文中，有一个图中描述的情况。

在 server1 重新启动后，可能会提交 entry2。

我的问题是：

如果entry2被误请求，则client的请求因server1的失败而失败。因此，客户端可能会认为错误的行为不是由状态机应用的，而实际上是在服务器 1 重新启动后执行的，如图（e）所示。