标签: raft

什么时候使用像CRDT而不是paxos或筏这样的东西是个好主意？

是怎样的木筏共识算法从MongoDB的比MongoDB的需要等因素的影响(优先级,例如)因素,而选举的主要事实其他初选过程有什么不同？

在阅读了paxos和筏纸之后,我有以下困惑:paxos论文仅描述了单日志条目的共识,这相当于筏算法的领导者选举部分.在木筏领导者选举中,paxos的方法优于简单的随机超时方法有什么优势？

在所有关注者更新提交索引之前,领导者崩溃会发生什么？

例如,节点A,B,C形成集群:

• 只有A和B活着,A是领导者

• A将一个条目(比如说它的entry1)复制到B并从B获得成功的结果

• 提交entry1,并在向B发送心跳消息之前崩溃(这会导致B更新其提交索引)

• C现在在线

我的问题是:

• C会被选为新领导人吗？如果是这样,那么entry1会丢失吗？此外,如果A重新加入,其数据将与其他数据不一致？

我知道筏子规格说:

Raft使用一种更简单的方法,它保证从选举之时起,每个新领导者都会出现之前条款中的所有已提交条目,而无需将这些条目转移给领导者.

但是这里的entry1可能不被视为已提交的条目？因为B没有得到老领导的确认(来自领导者的心跳).那么C有机会成为新的领导者吗？

• 如果B成为新的领导者,那么它应该如何处理entry1？

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

在此示例中,Replicator负责将输入事件\命令复制到从属节点.复制一组节点需要我们应用一致性算法,以防我们希望系统在出现网络故障,主故障和从站故障时可用.

我正在考虑将RAFT一致性算法应用于此问题.一个观察结果是:"RAFT要求在复制期间将输入事件\命令存储到磁盘(持久存储)"(参考此链接)

这种观察实质上意味着我们无法执行内存中复制.因此,似乎我们可能必须结合复制器和记者的功能才能成功地将RAFT算法应用于LMAX.

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

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

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

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

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

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

正如论文所说:

选举安全:在一个特定的任期内,最多只能选出一名领导人.§5.2

但是,系统中可能有多个领导者.筏只能承诺在给定的期限内只有一个领导者.所以如果我有多个客户端,我不会得到不同的数据吗？这如何让Raft成为一致的算法？

有什么我不明白的,有人可以解释一下吗？

这真是愚蠢,但动物园管理员做的那个木筏没有 - 不是说zab而是动物园管理员本身.

我得到筏子领导选举等服务器,但动物园管理员的意义何在？是否有任何人有类比

在raft中,当节点重新启动时,它会尝试重做所有日志条目以赶上状态.但是如果节点在恢复阶段再次出现故障,节点会做两次操作.如果ops不是幂等的,那么这两次重做操作将违反状态机.

根据上面的描述,我的问题是,在实践中使用筏子的系统中使ops成为幂等的必要吗？

我正在阅读 Raft论文并关注数据可视化的秘密生活，似乎多数在 Raft 中至关重要，无论是对于领导者选举还是附加条目请求。

我的问题是节点首先如何知道集群中的节点总数？是否定义了发现协议或在创建集群时必须配置节点数量？或者 Raft 是否将其留给具体实现？

我的下一个问题是这个数字如何更新（即追随者节点如何标记为关闭），特别是在网络分区的情况下。

感谢您的指点！

这是来自Kubernetes 文档：

一致且高度可用的键值存储用作 Kubernetes 所有集群数据的后备存储。

Kubernetes 内部是否有单独的机制来使 ETCD 更可用？或者 ETCD 是否使用 Raft 的修改版本来实现这种超能力？