ZooKeeper ZAB協議 詳解

• ​
• 參考：B站大法好：https://www.bilibili.com/video/BV1U5411t7Mp?from=search&seid=11109207762490056623
• 選舉
  • 每個機器保存zxid(日誌id)，自己的機器id(myid)
  • 選舉規則，按照<zxid,myid>排序
    • zxid大的是老大
    • zxid相同的情況下，myid大的是老大
  • 初始化：
    • 先說結論：
      • 按機器id順序啓動，中間那個機器是leader
    • details
      • 機器1：(zxid=0,myid=1); 啓動，投票給自己。把自己選票發給機器2和3，沒有反應。人不夠，等待。
      • 機器2：(zxid=0,myid=2); 啓動，投票給自己。成功成爲leader
        • 把自己選票發給機器3，沒有反應。
        • 機器2收到機器1的選票(zxid=0,myid=1)，發現自己更強，所以自己認爲自己是老大
        • 機器1收到機器2的選票(zxid=0,myid=2)，發現自己沒機器2強，不再listen，乖乖當follower，轉向給機器2發心跳
      • 機器3：zxid=0,myid=3; 啓動，投票給自己。會發現已經選好leader了，乖乖轉成follower
        • 把自己選票發給機器1，機器2；
        • 機器1和機器2一看，現在都知道leader是機器2了，迴應說咱已經選好了，你乖乖當follower吧
• 提交
  • 2PC,2階段提交
  • 大致過程
    • 客戶端寫請求，轉發到leader
    • leader本地寫log
    • leader把Prepare請求發到其他機器
    • 收到過半數ack之後，給其他機器發commit請求讓他們提交，然後給客戶端返回ok
• 腦裂
  • 情況1，6機器，3：3
    • 機房1：機器1-3
    • 機房2：機器4-6
    • 兩個機房中間斷網了。兩個機房內部溝通發現都超不過半數（3<4）兩邊都選不出leader，拒絕請求。
  • 情況2，6機器，2：4
    • 機房1：機器1-2
    • 機房2：機器3-6
    • 兩個機房中間斷網了。機房2內部溝通發現能超過半數，成功選了leader，繼續對外提供服務。機房1內部溝通發現選不出leader，拒絕對外提供服務。
    • 後面網恢復了，機房1的機器需要找機房2的leader把數據同步回來。
• 如何保證順序寫
  • 代碼
    • CommitProcessor#run
  • 大概流程
    • leader會收到很多不一樣的客戶端的讀/寫請求
    • 首先按照客戶端sessionId分成不同的隊列
    • 然後第一個寫請求前的讀，先給全部讀了
    • 再把寫請求後面的按順序排好