问题标签 [raft]

什么时候使用 CRDT 之类的东西而不是 paxos 或 raft 是个好主意？

除了 MongoDB 在选举主节点时考虑其他因素（例如优先级）之外，raft 共识算法与 MongoDB 的主节点选举过程有何不同？

我正在使用time.After(time)，它工作正常。

我的问题是：它是否准确，我应该使用它还是应该制作自己的功能？我将它与 Raft Consensus 算法实现一起使用。

我对实现 RAFT 有以下疑问：

考虑以下场景\实现：

1. RAFT 领导者收到一个命令条目，它将条目附加到内存数组中，然后将条目发送给跟随者（带有心跳）
2. 追随者接收条目并将其附加到他们的内存数组中，然后发送响应它已收到条目
3. 然后领导者通过将条目写入持久存储（文件）来提交条目领导者在心跳中发送最新的提交索引
4. 追随者然后通过将条目存储到他们的持久存储（文件）来根据领导者的提交索引提交条目

RAFT 的实现之一（链接：https ://github.com/peterbourgon/raft/ ）似乎以这种方式实现它。我想确认这是否正常。

如果条目由领导者和追随者“在内存中”维护，直到它被提交，是否可以？在什么情况下这种情况可能会失败？

LMAX Disruptor 通常使用以下方法实现：

如本例所示，Replicator 负责将输入事件\命令复制到从节点。跨一组节点进行复制需要我们应用共识算法，以防我们希望系统在出现网络故障、主故障和从故障时可用。

我正在考虑将 RAFT 共识算法应用于这个问题。一项观察是：“RAFT 要求在复制期间将输入事件\命令存储到磁盘（持久存储）”（参考此链接）

这种观察本质上意味着我们无法执行内存复制。因此，我们可能必须结合复制器和日志器的功能才能成功地将 RAFT 算法应用于 LMAX。

有两种方法可以做到这一点：

选项 1：使用复制的日志作为输入事件队列

• 接收者将从网络读取并将事件推送到复制的日志而不是环形缓冲区
• 一个单独的“阅读器”可以从日志中读取并将事件发布到环形缓冲区。
• 可以使用 RAFT 跨节点复制日志。我们不需要复制器和日志器，因为功能已经由 RAFT 的复制日志完成

我认为这个选项的一个缺点与我们做了一个额外的数据复制步骤（接收器到事件队列而不是环形缓冲区）有关。

选项 2：使用 Replicator 将输入事件\命令推送到从属的输入日志文件

我想知道 Replicator 的设计是否还有其他解决方案？人们为复制器采用了哪些不同的设计选项？特别是任何可以支持内存复制的设计？

As the paper says:

Election Safety: at most one leader can be elected in a given term. §5.2

However, there may be more than one leader in the system. Raft only can promise that there is only one leader in a given term. So If I have more than one client, wouldn't I get different data? How does this allow Raft to be a consensus algorithm?

Is there something I don't understand here, that someone could explain?

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

一旦选出领导者——

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

我有一个像这样的代码功能。我感到困惑的是：为什么我们需要atomic这里？这是为了防止什么？

谢谢。

在 Raft 集群中，每个日志条目都可以被认为具有一个日志索引（按照日志的顺序，该条目出现的位置）和一个日志术语（条目出现在哪个“术语”；每次选举都会增加术语）。

例如，

这里，方块代表日志条目。方块中的数字代表日志中每个条目的期限。正方形的位置（以及最顶部的数字）代表日志中每个条目的索引。

Raft 日志中的日志索引和日志项是否会无限增长？

如果不是，你如何“重置”这些变量？

如果是，实现（例如 etcd 或 ZooKeeper）是否支持这些无限增长，或者它们是否使用固定大小的整数类型并假设您永远不会溢出这些变量？

I read how current master election algorithms like Raft, Paxos or Zab elect master on a cluster and couldn't understand why they use sophisticated algorithms instead of simple bully algorithm.

I'm developing a cluster library and use UDP Multicast for heartbeat messages. Each node joins a multicast address and also send datagram packets periodically to that address. If the nodes find out there is a new node that sends packets to this multicast address, the node is simply added to cluster and similarly when the nodes in the cluster don't get any package from a node, they remove it from the cluster. When I need to choose a master node, I simply iterate over the nodes in the cluster and choose the oldest one.

I read some articles that implies this approach is not effective and more sophisticated algorithms like Paxos should be used in order to elect a master or detect failures via heartbeat messages. I couldn't understand why Paxos is better for split-brain scenarios or other network failures than traditional bully algorithm because I can easily find out when quorum of nodes leave from the cluster without using Raft. The only benefit I see is the count of packets that each server have to handle; only master sends heartbeat messages in Raft while in this case each node has to send heartbeat message to each other. However I don't think this is a problem since I can simply implement similar heartbeat algorithm without changing my master election algorithm.

Can someone elaborate on that?