為什么對於寫請求而不是讀請求強制選舉領導者？

Question

在可靠的分布式系統中，領導者選舉對於寫入成功是必不可少的，我可以理解它需要遵循 Paxos 算法。

但是，為什么讀請求不需要領導選舉（因此達成共識）？ （例如在動物園管理員中）

我錯過了什么嗎？

Answer 1

Zookeeper 讀取是不可線性化的，因此不需要共識協調。 相反，它們順序一致，允許從客戶端連接到的節點進行本地讀取。

例如，Raft 也是如此。 您可以執行本地讀取並獲得最多的順序一致性（前提是您與節點協調以不讀取比您看到的更舊的數據），但是如果您想要線性化讀取，則必須“提交”讀取操作（即，讓系統在您讀取之前就提交哪些寫入達成一致），再次需要達成共識。

Zookeeper 不可線性化。 參見例如https://github.com/jepsen-io/jepsen/issues/399 。 人們普遍認為可以同步+閱讀（並且，在進行此編輯之前，我在這里重復了這個神話），但引用 Zookeeper 文檔：

同步的使用有一個警告，它是相當技術性的，並且與 ZooKeeper 內部結構緊密相連。 （隨意跳過它。）因為 ZooKeeper 應該為讀取主導的工作負載提供快速讀取和擴展服務，所以同步的實現已經被簡化，它並沒有像創建一樣真正遍歷執行管道作為常規更新操作，設置數據，或刪除。 它只是到達領導者，領導者將響應排隊返回給發送它的追隨者。 領導者認為它是領導者 l 的可能性很小，但不再得到法定人數的支持，因為法定人數現在支持不同的領導者 lʹ 。 在這種情況下，leader l 可能沒有處理完所有更新，並且同步調用可能無法兌現其保證。