问题标签 [raft]

有没有一种简单的方法可以确定谁是 etcd 集群中的当前领导者（除了通过日志搜索）？

使用 RAFT 分布式共识算法一次调用构建分布式消息代理。代理还将具有支持按顺序向订阅者传递消息的附加功能。属于某个主题的消息将按照代理接收它们的顺序传递（或从订阅者中提取，如果是拉模型）。

具有这些功能的消息代理的用例之一是作业队列，因为它要求作业永远不会丢失（持久）并且按照它们到达的顺序完成。

这种消息代理的其他用例是什么？你能提供例子吗

我试图了解 etcd 上的“原子”更新是什么。

当我想到“原子”时，我认为有“之前”和“之后”（没有期间，如果更新失败，它仍然是“之前”）。

这是一个例子：

因此，此时，任何人都可以访问该消息并获取当前值：

稍后，我可以修改这个值，如下所示：

并且可以像以前一样获取结果。在我更改值“Hidee Ho”之前返回，更改后值“Mr Hanky”返回。所以，我的问题是我能保证其中一个结果吗？也就是说，我想确认将返回一个或另一个（而不是结果之间的nil值）。

我不是特别在意时间。如果我进行 Hanky 先生更新，并且随后的价值获取者在（短）一段时间内继续获得 Hidee Ho，那没关系。

我很困惑，因为协议中有一个 Atomic CompareAndSwap函数。据我所知，它不是原子的，而是“只有当值是我所说的值时才进行更新”。就我而言，我不太在乎过去的价值。我只想知道它已经改变了，除了“之前”或“之后”值之外，没有读者会看到任何东西。

当领导者获得日志条目时，它会将其复制到集群中的其他服务器。然后它提交条目并告诉其他服务器也提交。这里似乎有两种情况：
1）领导者提交条目，然后告诉其他服务器也提交。
2）领导者告诉每个人都承诺，然后它也这样做。

在＃1中，如果领导者在告诉其他人提交之前崩溃了，那么成为新领导者的人是否会使用该条目，即使它没有提交？如果不是，那么我们有一些与最新条目不同步的日志。（老领导会应用它，而另一个不会。）如果是这样，那么它怎么知道可以提交它？

在#2中，如果leader在提交之前就崩溃了，那么所有其他节点在提交之后都崩溃了，然后在选举中，旧的leader再次成为新的leader，然后其他服务器已经提交了新leader没有提交的条目没有。在这种情况下会发生什么？

如果我们的数据库中修改了某些特定数据，我们的 API 需要将数据发送到 Zapier。

例如，我们有一个公司表，如果名称或地址字段被修改，我们会触发 Zapier 钩子。

有时我们的 API 会在几分钟内收到多个更改请求，但我们不想多次触发 Zapier 钩子（因为它非常昂贵），所以我们在每个修改请求上调用一个setTimeout()（并覆盖现有的），用一个延迟。setTimeout5000ms

它工作正常，即使我们在此5000ms期间收到来自客户端的大量修改请求，也没有多次 Zapier 挂钩调用。

现在 - 由于我们的流量正在增长 - 我们想在一些负载均衡器后面设置多个 node.js 实例。

但是在这种情况下，不同的 Node.js 实例不能使用 - 并覆盖 - 同一个setTimeout实例，这会导致很多无用的 Zapier 调用。

你们能否帮助我们，如何解决这个问题 - 同时保持可扩展性？

以多人网络游戏的用例为例。您会立即遇到跨网络复制和协调共享状态的问题。

针对这个问题的方面似乎有多种工具，特别是两个似乎重叠：

1. 无冲突复制数据类型(CRDT) - 用于
2. RAFT 共识算法- 用于在分布式网络中选择交易领导者以帮助达成共识。

我的问题是：CRDT 和 RAFT 协议之间是否存在关系——或者它们是正交的？

假设一个 3 成员 raft 集群 a[master],b,c

客户端将日志发送到 a，a 将其复制到 b 和 c，a 将日志应用到状态机并响应客户端。然后 a 在 b 和 c 有机会将提交的状态复制到 b 和 c 之前崩溃。

b 替换 a 作为集群领导者。当日志已经响应客户端时，未提交的日志会发生什么？

它会被 b 再次复制还是被丢弃？

然后假设一个 4 成员 raft 集群 a[master],b,c,d

客户端将日志发送到 a，a 将其复制到 b 和 c（而不是 d），a 将日志应用到状态机并响应客户端，然后 a 在将提交的状态复制到 b、c 和 d 之前崩溃。

d 替换 a 成为集群领导者。那么在日志已经响应客户端的情况下，未提交的日志会发生什么？它会被丢弃吗？

我有 2001、2002、2003 和 2004 的 4nodes 集群。它们使用 goraft 绑定。假设 2001 是主服务器。现在，当它失败时，另一个节点成为服务器。现在我想要的是，成为当前服务器的节点应该发送我是新领导者的消息。那么如何实现呢？我正在使用带有 GORAFD 实现的 GORAFT。我在这里附上源代码。

main.go - 对于客户端

Main.go - 用于服务器，即 2001

通用 Server.go 代码

请给出一些解决方案。

我们正在尝试构建一个系统，该系统从 Cassandra 数据库获取要执行的任务列表，然后通过某种组共识创建一个执行计划（最好在一个节点上），然后由整个服务器集群同意并执行. 我们真的不想添加任何额外的软件，例如 Redis 或 AMPQ 系统，而是将共识直接内置到所有运行作业的服务器中。到目前为止，我们已经找到了 Skiff，它是 Raft 算法的一种实现，看起来可以完成任务，但我想知道是否有人以纯 Node.js 的方式找到了一个优雅的解决方案，不涉及外部消息传递系统。

我已经阅读了 Raft 算法论文，并得到了一个与 Raft 在接收到客户端请求时执行的操作顺序相关的问题：

为了克服单点故障场景，Raft 依赖于在其他机器上维护一个复制的日志，该算法还参考了一个共识模块来进行完整的日志管理。操作顺序如下：

1. 领导者的状态机接收到客户端请求，领导者将命令附加到其日志中。
2. 领导者向他的追随者发送AppendEntries RPC 以在他们的本地日志中克隆命令，并等待大多数追随者确认该条目已成功附加到他们的本地日志文件中。
3. 一旦接收到请求已成功记录在大多数追随者日志中的确认，然后该请求将提交到领导者的状态机，从而发生转换，将该转换的输出返回给客户端。
4. 最终，领导者在后续的AppendEntries RPC中通知追随者提交的条目。

如果上述理解是正确的，那么我可以声称客户端请求被保留一段时间以完成复制过程，我也可以声称客户端请求的成功很大程度上取决于复制的成功进程（因为在收到多数确认之前，不会在领导者的机器上执行客户端命令/请求）。问题是，在复制过程完成后，客户端请求平均需要多长时间才能收到响应，这对于实时系统也有效吗？