如果有多個領導者，Raft 算法如何保證共識？

Question

正如論文所說：

選舉安全：在給定的任期內最多可以選舉一個領導者。 §5.2

然而，系統中可能有不止一個領導者。 Raft 只能保證在給定的任期內只有一個領導者。 所以如果我有多個客戶端，我會不會得到不同的數據？ 這如何讓 Raft 成為共識算法？

這里有什么我不明白的地方，有人可以解釋一下嗎？

Answer 1

只有獲得多數票的候選節點才能領先。 集群中只存在一個多數，如果不聯系至少一個已經投票給另一個領導者的節點，另一個節點就無法聽到多數。 聽到另一位領導人的候選人將下台。 這是一個很好的動畫，展示了它是如何發生的： http : //thesecretlivesofdata.com/raft/#election

Answer 2

是的，你是對的。 有可能在同一時間多個領袖，但不是在同一個長期的，所以保證仍然有效。 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 log提交，這對於過時的leader是不可能的。 所以沒問題。 只有真正的領導者才能通過在大多數服務器上復制條目來提交條目。
2. 對於 READ-ONLY 請求，leader 可以在不查看日志或提交條目的情況下離開。 你是對的，這在第 8 節末尾的論文中明確提到。

可以在不向日志中寫入任何內容的情況下處理只讀操作。 然而，如果沒有額外的措施，這會冒着返回陳舊數據的風險，因為響應請求的領導者可能已經被一個它不知道的新領導者所取代。 可線性化讀取不能返回陳舊數據，Raft 需要兩個額外的預防措施來保證這一點，而不使用日志。 首先，領導者必須擁有關於提交哪些條目的最新信息。 領導者完整性屬性保證領導者擁有所有已提交的條目，但在其任期開始時，它可能不知道哪些是。 要找出答案，它需要從其任期提交一個條目。 Raft 通過讓每個領導者在其任期開始時將一個空白的 no-op 條目提交到日志中來處理這個問題。 其次，領導者必須在處理只讀請求之前檢查它是否已被廢黜（如果選舉了最近的領導者，則其信息可能會過時）。 Raft 通過在響應只讀請求之前讓領導者與集群的大多數人交換心跳消息來處理這個問題。

希望這可以幫助。

Answer 3

集群中的每台機器都將其當前術語與它從其他機器收到的所有請求以及它收到的術語進行比較。 並且每當“領導者”嘗試充當領導者時，它都不會從集群的其余部分獲得多數接受，因為大多數機器的任期比“領導者”大。 這保證了只有真正的領導者才能回復客戶的請求。
此外，根據 Raft 的說法，這個“領導者”在收到更大任期的拒絕后將立即成為追隨者。

Answer 4

這是我三年前問的問題。 現在，我可以自己回答這個問題了。

這里的關鍵是，即使是讀操作，客戶端也需要經過 raft 協議。 如果客戶端請求舊的leader，則舊的leader啟動AppendEntry來確認是否是最新的leader。 它會注意到是舊的leader或者AppendEntry超時，然后返回給client timeout或者error。