如果有多个领导者，Raft算法如何保证共识？

Question

正如报纸所说：

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

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

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

Answer 1

只有拥有多数选票的候选节点才能领先。只有一个多数存在于集群中，另一个节点在没有联系至少一个已投票给另一个领导者的节点的情况下无法从多数人那里听到。听到另一位领导人的候选人将辞职。这是一个很好的动画，显示它是如何发生的：http://thesecretlivesofdata.com/raft/#election

Answer 2

群集中的每台计算机都将其当前术语与其收到的术语以及从其他计算机获得的所有请求进行比较。每当“领导者”试图充当领导者时，由于大多数机器具有比“领导者”更大的术语，因此它不会从群集的其余部分获得多数接受。这保证只有真正的领导者才能回复客户的要求 此外，根据Raft的说法，这位“领导者”在收到更长期的拒绝后会立即成为追随者。

Answer 3

是的，您是对的。 时间可以有多个领导者，但期限不能有多个领导者，因此保证仍然有效。可能的情况是在3服务器（A，B，C）群集中，A被选出。然后发生网络分区，群集被分为两个分区：{A}和{B，C}。在这种情况下，A不会下台，因为它没有收到任期更长的RPC，并且仍然是领导者。在多数派中，仍然可以选出新的领导人。但是请注意，这位新领导者的职称要比A领导的要强。

那客户端的请求呢？有两种情况。
1.对于WRITE请求，除非提交了输入日志，否则领导无法回复客户端，这对于过时的领导是不可能的。所以没问题。只有真正的领导者才能通过在大多数服务器上复制条目来提交条目。
2.对于只读请求，领导者可以在不查阅日志或提交条目的情况下离开。您是对的，这在第8节末尾的论文中已明确提及。

可以处理只读操作，而无需在日志中写入任何内容。但是，如果不采取其他措施，则存在返回陈旧数据的风险，因为响应请求的领导者可能已被不知情的新领导者所取代。可线性化的读取操作一定不能返回陈旧的数据，并且Raft需要采取两项额外的预防措施来保证不使用日志就可以做到这一点。首先，领导者必须掌握提交条目的最新信息。领导者完整性属性可以保证领导者拥有所有已提交的条目，但是在任期开始时，它可能不知道这些条目是谁。要找出答案，它需要从其期限中提交一个条目。 Raft通过让每位领导者在任期开始时在日志中输入空白的无操作条目来解决此问题。其次，领导者必须在处理只读请求之前检查它是否已被废除（如果已经选择了更新的领导者，其信息可能会过时）。 Raft通过让领导者在响应只读请求之前与大多数群集交换心跳消息来解决此问题。

希望这会有所帮助。

Answer 4

这是我三年前问的问题。现在，我可以自己回答这个问题了。

这里的重点是，即使是读操作，客户端也需要经过raft协议。如果客户端请求旧的leader，则旧的leader启动AppendEntry来确认是否是最新的leader。会注意到是老leader或者AppendEntry超时，然后返回客户端超时或者报错。