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?
只有拥有多数票的候选节点才能领先。集群中只有一个多数，如果不联系至少一个已经投票给另一位领导者的节点，其他节点无法听到多数的消息。听到另一位领导人的候选人将下台。这是一个很好的动画，展示了它是如何发生的： http: //thesecretlivesofdata.com/raft/#election
是的你是对的。可以同时有多个领导，但不能在同一任期内，所以保证仍然有效。A possible situation is in a 3-server (A, B, C) cluster, A becomes elected. 然后发生网络分区，集群分为 2 个分区：{A} 和 {B, C}。在这种情况下，A 不会下台，因为它没有收到任何更高任期的 RPC，并且仍然是领导者。在多数分区中，仍然可以选出新的领导者。但请注意，这位新领导人的任期比 A大。
那么客户端的请求呢？两种情况。
1、对于一个WRITE请求，leader不能回复客户端，除非entry logcommit了，这对于过时的leader是不可能的。所以没问题。只有真正的领导者才能通过在大多数服务器上复制条目来提交条目。
2. 对于只读请求，领导者可以在不查阅日志或提交条目的情况下脱身。你是对的，这在第 8 节末尾的论文中明确提到。
无需将任何内容写入日志即可处理只读操作。然而，如果没有额外的措施，这将面临返回陈旧数据的风险，因为响应请求的领导者可能已被它不知道的新领导者取代。线性化读取不能返回陈旧数据，Raft 需要两个额外的预防措施来保证这一点，而不使用日志。首先，领导者必须拥有提交的条目的最新信息。领导者完整性属性保证领导者拥有所有已提交的条目，但在其任期开始时，它可能不知道那些是哪些。要找出答案，它需要提交其任期内的一个条目。Raft 通过让每个领导者在其任期开始时将一个空白的 no-op 条目提交到日志中来处理这个问题。第二，领导者必须在处理只读请求之前检查它是否已被废止（如果选举了更新的领导者，其信息可能已过时）。Raft 通过让领导者在响应只读请求之前与大多数集群交换心跳消息来处理这个问题。
希望这可以帮助。
这是我三年前提出的问题。现在，我可以自己回答这个问题。
这里的重点是，即使是读操作，客户端也需要经过raft协议。如果客户端请求旧的leader，旧的leader会启动AppendEntry来确认它是否是最新的leader。它会注意到它是旧的leader或者AppendEntry超时，然后它会返回客户端超时或错误。
集群中的每台机器都会将其当前期限与它收到的期限以及它从其他机器获得的所有请求进行比较。并且每当“领导者”尝试充当领导者时，它不会从集群的其余部分获得多数接受，因为大多数机器的任期比“领导者”更长。这保证了只有实际的领导者才能回复客户的请求。
此外，根据 Raft 的说法，这个“领导者”将在收到更长期限的拒绝后立即成为追随者。