1樓：CatKang
可以從以下幾個方向比較協議：
primary-backup system or state machine system：raft是state machine system，zab是primary-backup system
處理唯讀請求：raft的讀請求與寫請求處理邏輯一樣，zab用租約使得可以讀任意副本
選主方式：raft比較last_log_index以及last_log_term保證選出的leader已經擁有最完整的資料，zab僅通過節點標識選主，所以需要之後的recovery過程，不過實現中zab也採用了類似於raft的選主方式
恢復方向：raft單向，僅從leader到follower補齊log；zab雙向，leader需要從follower接收資料來生成initial history
參考：https://www.
cs.cornell.edu/fbs/publ
ications/viveLaDifference.pdf
choices in consensus algorithm
2樓：汪小敏最美
最近在研究，可以看下我寫的這個
1、選舉 https://
zhuanlan /p/25332350
2、成員管理 https://zhuanlan /p/25344714
其他後續再填
raft協議疑問？
bluebore 1.不能返回失敗 2.操作結果就是不可預知 呼叫者通過重試或者通過其他查詢手段獲取結果，具體到raft，就是重新更新一次或者發起一次一致性讀來確認到底有沒有寫成功。分布式系統中的請求結果區別與單機系統，最大的特點是存在 三態 的概念。也就是除了 成功 失敗 之外還有個 超時 未知 ...
zab協議與paxos協議為什麼只保證超過半數的機器保持同步？那剩下的機器是不是會出現不一致的問題？
CatKang 只要求超過半數，是為了提公升可用性，容忍一部分節點異常。而之所以可以這麼做，是由於大多數的性質 兩個大多數一定有交集 這也正是所有一致性協議證明的關鍵，利用這個性質 Propose發起Accept前，確保得到了大多數節點的Promise，就保證不會有兩個不同的提案內容同時被不同節點A...
raft協議，leader在commit了一條日誌後，立刻掛了，那其他節點如何處理這條日誌？
王傳義 該問題問的非常好，首先故障傳送後，raft不會通過簡單計數判斷是否安全寫入，這也你是有疑問地方。不管log 日誌處於什麼狀態。總能保證內部資料的一致性。具體是寫入還是覆蓋。要看具體情況。但是對客戶端不清楚的，需要客戶做冪等操作等處理。問題 怎麼保證一致性的。依然通過正常日誌複製操作 這地方沒...