知乎 《raft演算法詳解》 比較通俗易懂的描述了raft
github 《尋找一種易於理解的一致性演算法（擴充套件版）》 該文是raft文獻的乙個翻譯，翻譯的還是比較流暢易懂的
下面是以q&a的方式自己的總結，對於應試幫助比較大：
q1: raft演算法的目的
a1: 解決分布式架構下的副本一致性問題。
q2: raft的角色和狀態變化
a2: leader, candidate, follower. 任一時刻最多有乙個leader，這也是和paxos的乙個區別
q3: 選舉的過程
a3: 開始時角色初始化為follower，來自leader的心跳超時（這時因為沒有leader） follower轉變為candidate 增加term發起選舉。選舉請求帶了term和index，是否被選舉取決於term大於請求接受方，如果相等再比較index大。
選出leader後，leader通過心跳與其他node保持關係。
這裡是q4中提到的要解決的問題是什麼： 如果沒有安全性原則，達到了歷史任期中被複製到「大多數」機器的情況是需要被提交的，然而提交前leader掛了，leader再回來的時候已經是下乙個term了，如果這個這時leader還要管理歷史term下要提交的情況，此時又掛了，那麼會被s5的動作覆蓋，不符合要求。
所以解決方案是：1. 定義最新的log，是term + index 對比
2. leader只判斷當前term的log複製是否達到commit狀態，一旦commit，那麼之前的copy也會被commit。 但是如果沒有達到commit狀態又宕機 被搶主，本身歷史log就不是約定的必須要commit的，所以就不用處理。
q5: 如果s5不是宕機，而是因為網路問題與其他node在不同的網路分割槽，那麼s5會不斷地自己進行選舉增加自己的term，然後在term很高的時候恢復了與原集群的網路，那麼這時候他的term最高，豈不是他才會被選主（但是他的index又不是最新的）
a5: s5網路分割槽前是後，他的term因為election不停的增加到20，但是在網路恢復後，他發出去的vote請求裡帶的term應該不是20, 而是具有最高index（5）所對應的term，也就是10. 所以他的vote請求會大概率被拒絕
raft演算法 Paxos和Raft共識演算法（二）
raft 譯文 在過去的 10 年中，leslie lamport 的 paxos 演算法幾乎已經成為了一致性演算法的代名詞，但是paxos 有兩個致命的缺點 第乙個是 paxos 太難以理解，第二個缺點是它難以在實際環境中實現。其中乙個原因是，對於多決策 paxos multi paxos 大家還...
Raft演算法詳解
3 log replication 4 腦裂問題 raft協議中，乙個節點任一時刻處於以下三個狀態之一 有節點啟動時都是follower狀態，在一段時間內如果沒有收到來自leader的心跳，從follower切換到candidate，發起選舉。如果收到集群中大多數的票 含自己的一票 則切換到lead...
Raft選舉演算法
目標 分布式集群中，選舉leader，保持資料一致性 集群中每個節點都有三種狀態 follower 純小弟 candidate 候選人。我原來是小弟，但我現在想當老大 leader 老大 集群狀態 有明確的老大 穩定狀態 沒有老大，選舉中 有老大的狀態 follower內有倒計時 150ms 300...