bao*_*iao 8 algorithm distributed consensus raft
正如论文所说:
选举安全:在一个特定的任期内,最多只能选出一名领导人.§5.2
但是,系统中可能有多个领导者.筏只能承诺在给定的期限内只有一个领导者.所以如果我有多个客户端,我不会得到不同的数据吗？这如何让Raft成为一致的算法？
有什么我不明白的,有人可以解释一下吗？
只有获得多数票的候选节点才能领先。集群中只有一个多数存在，其他节点在不联系至少一个已经投票给另一位领导者的节点的情况下无法听到多数的消息。听说另一位领导人的候选人将下台。这是一个很好的动画，展示了它是如何发生的：http ://thesecretlivesofdata.com/raft/#election
是的你是对的。可以同时有多个领导者，但不能在同一任期内，因此保证仍然有效。一种可能的情况是在 3 个服务器（A、B、C）集群中，A 当选。然后发生网络分区，集群分为 2 个分区：{A} 和 {B, C}。在这种情况下，A 不会下台，因为它没有收到任何更高期限的 RPC，并且仍然是领导者。在多数票分配的情况下，仍然可以选举出新的领导者。但请注意，这位新领导者的任期比 A更大。
\n\n那么客户端的请求呢？两个案例。
\n1. 对于 WRITE 请求，除非条目日志已提交，否则领导者无法回复客户端，这对于过时的领导者来说是不可能的。所以没问题。只有真正的领导者才能通过在大多数服务器上复制该条目来提交该条目。
\n2. 对于只读请求，领导者可以离开而无需查阅日志或提交条目。你是对的，论文第 8 节末尾明确提到了这一点。
\n\n\n只读操作可以在不向日志中写入任何内容的情况下进行处理。然而，如果不采取额外措施，这将面临返回过时数据的风险，因为响应请求的领导者可能已被它不知道的新领导者取代。可线性化读取不得返回陈旧数据，Raft 需要两个额外的预防措施来保证这一点，而不需要使用日志。首先，领导者必须掌握有关提交条目的最新信息。领导者完整性属性保证领导者拥有所有已提交的条目，但在其任期开始时，它可能不知道这些条目是哪些。为了 \xef\xac\x81nd 输出，它需要从其术语中提交一个条目。Raft 通过让每个领导者在其任期开始时向日志中提交一个空白的无操作条目来处理此问题。其次，领导者必须在处理只读请求之前检查其是否已被废黜（如果更新的领导者已当选，则其信息可能已过时）。Raft 通过让领导者在响应只读请求之前与集群中的大多数成员交换心跳消息来处理此问题。
\n
希望这可以帮助。
\n这是我三年前问过的问题。现在，我可以自己回答这个问题。
这里的关键点是，即使是读操作，客户端也需要经过raft协议。如果客户端请求旧的leader，旧的leader会启动AppendEntry来确认它是否是最新的leader。它会注意到它是旧的领导者或AppendEntry超时，然后它会返回给客户端超时或错误。