在《從Paxos到Zookeeper 分布式一致性原理與實踐》一書中有下面這段話：
當 leader 收到合法數量 follower 的 ACKs 后，就向各個 follower 廣播 COMMIT 命令，同時也會在本地執行 COMMIT 并向連接的客戶端回傳「成功」。但是如果在各個 follower 在收到 COMMIT 命令前 leader 就掛了，導致剩下的服務器并沒有執行都這條訊息。
如何解決 已經被處理的事務請求（proposal）不能丟（commit的）呢？
1、選舉擁有 proposal 最大值（即 zxid 最大） 的節點作為新的 leader：由于所有提案被 COMMIT 之前必須有合法數量的 follower ACK，即必須有合法數量的服務器的事務日志上有該提案的 proposal，因此，zxid最大也就是資料最新的節點保存了所有被 COMMIT 訊息的 proposal 狀態。
2、新的 leader 將自己事務日志中 proposal 但未 COMMIT 的訊息處理。
3、新的 leader 與 follower 建立先進先出的佇列， 先將自身有而 follower 沒有的 proposal 發送給 follower，再將這些 proposal 的 COMMIT 命令發送給 follower，以保證所有的 follower 都保存了所有的 proposal、所有的 follower 都處理了所有的訊息。
我的疑問是：若舊leader發出的proposal被少于半數的follower收到時掛了，那么選舉出來具有最大ZXID的新leader應該是含有那些未提交的proposal，但是那些proposal其實并沒有被舊leader提交，那協議中是怎么處理這種場景的呢？
uj5u.com熱心網友回復：
新leader會在恢復階段會詢問是否有半數以上的flower收到了這條proposal，按照你的場景，沒有半數以上的flower收到，那么新的leader就會放棄這條proposal不會做提交uj5u.com熱心網友回復：
具體的流程可以參考https://blog.csdn.net/gangsijay888/article/details/82383599 這篇博客下半部分對【幾種領導選舉場景】的分析，分析很全面uj5u.com熱心網友回復：
這樣子應該是不對的，假設有如下場景：
在某一時刻，集群中各節點的情況如下：
A:1,2,3,4
B:1,2,3,4
C:1,2,3,4
D:1,2,3
E:1,2
其中A是leader;B,C,D,E是follower
此時A因為某種原因掛掉，理論上我們應該保證已被提交的1,2,3,4訊息保留
理論上C會被推舉為leader，但是此時集群中(B,C,D,E)4號訊息并沒有在多數節點上提交，如果按照你的說法該proposal不會做提交，那這樣就有問題，我的結論是在zxid最大的情況下，leader會逐步讓每條訊息都達成共識。而不是丟棄該proposal
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/93689.html
標籤：分布式計算/Hadoop
上一篇：【圖片助手】chrome插件請教
下一篇：程式員