问题标签 [raft]

我有一个类MyClass在初始化时创建 7 个线程。一个线程是 TCPServer，另外六个是MyClassTCPServer 用来处理请求的对象。

我的目的是创建可以在后台运行MyClass并维护 6 个线程的方法。这 6 个线程对应于 2 个分布式对象obj1，并obj2通过名为 PySyncObj 的 Raft 实现进行复制。每个对象有三个线程。

每个对象集群obj_1_cluster都有obj_2_cluster一个领导者，服务器必须跟踪它，因为对对象的所有更改都必须只发送给领导者。

当我运行这段代码时，我看到的唯一输出是......

直到我用 ctrl-C 终止进程。

有没有办法改变这一点，以便这两个进程可以使用自己的线程运行——在需要更改对象时忙于检查对象的状态？我已经阅读了很多关于线程的内容，但我不明白为什么这目前没有按照我认为的方式工作。

环境：我在 MacOS 10.13.3 上运行 python 2.7.14。

在网络分区的情况下，Raft 保持一致。但是，如果只有一个节点只与领导者失去联系，成为候选人并要求投票，会发生什么？

这是设置，我调整了http://thesecretlivesofdata.com/raft/中的示例以满足我的需要：

节点B是当前的领导者，并向追随者发送心跳（红色）。B和之间的连接C丢失，在选举超时后C成为候选人，为自己投票并要求节点A，D并E为它投票（绿色）。

会发生什么？

据我了解 Raft，nodesA和DshouldE投票选出C下C一个领导者（第 2 学期）。然后，我们有两个领导者各自发送心跳，并希望节点发送心跳，并且A由于任期较低D而E将忽略这些心跳。B

这是正确的还是有更好的机制？

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

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

raft共识算法是拜占庭容错算法吗？

需要多少（百分比）节点才能达成一致/共识？

是否已更改 Corda 版本 3 上的 RAFT 实现，或者它与版本 2 类似并且无法禁用 TLS v1？

我们知道 Corda 使用 TLS v1.2，但 v1 仍然处于活动状态，我们需要完全禁用。有没有办法做到这一点？

谢谢！！

在 raft 中，如果日志复制到多数，则认为它已在领导者中提交。然后leader发送msg给follower，告诉follower一个entry变为commit。如果没有，follower如何以及何时知道一个entry变为commit？

Another question,if an out of date can win an election in the following case? 5个节点集群，节点A是当前leader。

答： 0 1 2 3 4

乙： 0 1 2 3 4

C: 0 1 2 3 4

D： 0 1 2 3

E: 0 1

当节点 A（当前领导者）收到请求（条目 4）时，将其记录并复制到节点 B 和节点 C。然后节点 A 在状态机中应用条目 4 并回复客户端（此时条目被认为已由节点提交B 和节点 C 与否？）。Then node A and node B crash, node D start new election vote itself and get vote by node E, then win the election . 这种情况会发生吗？

在 Quorum 的RAFT 共识文档中提到

这种链扩展逻辑是确定性的：集群中的每个节点都会发生相同的行为，从而使区块链保持同步。

在leader发生变化的情况下，共识算法如何保证所有follower节点拥有相同的账本？是不是有一些follower节点先从前一个leader那里得到一个新块，而一些节点先从新leader那里得到一个新块？是否有任何同步机制来避免这种行为？

我正在尝试实现 Raft 共识算法。以下是我对设置服务器状态的term和votedFor属性的所有时间的一般理解：

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

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

我似乎不知道 etcd 如何保证按顺序接收同一（跟随者）节点发送的消息。该message结构似乎不包含“已发送索引”，例如，MSGProp它甚至不包含该术语。

同样，如果消息延迟了怎么办？是否有删除消息的时间戳？

Suppose a cluster of 5 nodes(ABCDE), node-A is elected leader at the beginning, and while leader-A issues AppendEntries RPCs to the follower(BCDE) to replicate log entry(log-X)，only node-B receives and returns success, at this point leader-A crashes.

If node C(or D or E) wins the next leader election then everything's fine, because only node B has log-X, and that means log-X is not committed.

My question is, could node-B (which has the highest term and longest log) win the next leader election? If so, will node-B spread log-X to other nodes?