前言
最近筆者做了ZK集群的擴容，總結了一些經驗，分享一下，其實其中還是有些問題的，
1. 擴容架構設計
設計圖如下：
本質是zookeeper的3個節點擴容至5節點，實作2個節點的容錯，提高穩定性，
由于允許短時間停機，所以采用比較保守的方式擴容，沒有采用不停集群擴展，總結為改配置，重啟，
至于不停機擴容，這個其實需要嚴格測驗，根據停機擴容的情況，程序中出現的問題不少，
2. 擴容程序的問題
2.1 選主的程序
zookeeper選舉的原理是比較，當前服務器的epoch、lastLoggedZxid和myid，zookeeper會根據這幾個資料比對，然后根據這3個值選舉leader，保證資料的準確性，
epoch
選舉的次數，即參與了幾次選舉，表示取參與選舉次數最大的選舉節點，越大越優先，
lastLoggedZxid
最后的事務日志ID，我們知道zookeeper有快照與事務日志，快照是記憶體的瞬時態，配合事務日志才能還原最新記憶體的資料，越大越優先，
myid
節點ID，越小越優先，
2.2 zookeeper集群復制機制
DIFF同步、TRUNC+DIFF同步、TRUNC同步、SNAP同步
DIFF同步
直接差異化同步，在leader與follower差異不大的情況，資料影響較小，或者沒有影響，
TRUNC+DIFF同步
回滾同步，再差異比較，可能造成資料丟失
TRUNC同步
回滾同步，可能造成資料丟失
SNAP同步
記憶體復制，針對新增的節點，
2.3 擴容問題
擴容后資料丟失部分，造成監聽器監聽，對應用造成嚴重后果，
問題出現情況：
3個節點集群停機，馬上啟動5個節點集群，
問題出現原因，老集群3個節點在加載快照與事務的程序中有先后順序，新增的2個節點啟動極快，造成老節點與新增的2個節點開始選主，由于加載快的老節點資料一般就會比較舊，執行TRUNC+DIFF同步，造成資料丟失
即使后面老集群的其他2個節點啟動OK，也被迫接受TRUNC+DIFF同步，資料丟失了，所以在zookeeper擴容之前需要嚴格備份zoo.cfg 快照日志 事務日志，還要有方案，zookeeper完全掛掉如何恢復，
3. 解決方案
先啟動舊集群的3個節點，待選舉復制OK（即可以提供zk集群能力）后，再啟動新增的2個節點，直接作為follower參與SNAP復制，即可保證資料的準確性，
總結
zookeeper集群擴容需要非常慎重，資料是保存在快照與事務日志中的，每個節點的資料不是絕對對等的，不是強一致性，一半以上的節點復制OK即可提供服務，擴容前需要反復演練，否則很難發現問題，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/250660.html
標籤：其他
下一篇：三層架構實驗