Java 面試——Zookeeper
目錄
一、Zookeeper 的高可用性原理
一個 ZooKeeper 叢集如果要對外提供可用的服務，那麼叢集中必須要有過半的機器正常工作並且彼此之間能夠正常通訊。如果想搭建一個能夠允許 N 臺機器 down 掉的叢集，那麼就要部署一個由 2*N+1 臺伺服器構成的 ZooKeeper 叢集。所以部署3個節點，那麼就得至少有2個節點可用則該叢集才可用。4個節點同樣還是要2個以上。所以 Zookeeper叢集部署的節點（非Observer）數一般為奇數。高可用機制其實基於 ZAB協定[連結]。
二、Zookeeper 實現機制
檔案系統 + 通知機制
三、Zookeeper檔案系統
Zookeeper 提供一個多層級的節點名稱空間（節點稱為znode）。與檔案系統不同的是，這些節點都可以設定關聯的資料，而檔案系統中只有檔案節點可以存放資料而目錄節點不行。Zookeeper為了保證高吞吐和低延遲，在記憶體中維護了這個樹狀的目錄結構，這種特性使得 Zookeeper不能用於存放大量的資料，每個節點的存放資料上限為1M。
四、四種型別的資料節點 Znode
提供過了四種型別的資料節點 Znode：
【1】PERSISTENT 持久節點：除非手動刪除，否則節點一直存在於 Zookeeper上；
【2】EPHEMERAL 臨時節點：臨時節點的生命週期與使用者端對談繫結，一旦使用者端對談失效（使用者端與 zookeeper連線斷開不一定對談失效），那麼這個使用者端建立的所有臨時節點都會被移除；
【3】PERSISTENT_SEQUENTIAL 持久順序節點：基本特性同持久節點，只是增加了順序屬性，節點名後邊會追加一個由父節點維護的自增整型數位；
【4】EPHEMERAL_SEQUENTIAL 臨時順序節點：基本特性同臨時節點，增加了順序屬性，節點名後邊會追加一個由父節點維護的自增整型數位；
五、Zookeeper Watcher 機制
zookeeper 允許使用者端向伺服器端的某個 Znode註冊一個 Watcher監聽，當伺服器端的一些指定事件觸發了這個 Watcher，伺服器端會向指定使用者端傳送一個事件通知來實現分散式的通知功能，然後使用者端根據 Watcher通知狀態和事件型別做出業務上的改變。
Watcher 特性總結：
【1】一次性：無論是伺服器端還是使用者端，一旦一個 Watcher被觸發，Zookeeper都會將其從相應的儲存中移除。這樣的設計有效的減輕了伺服器端的壓力，不然對於更新非常頻繁的節點，伺服器端會不斷的向用戶端傳送事件通知，無論對於網路還是伺服器端的壓力都非常大。
【2】使用者端序列執行：使用者端 Watcher回撥的過程是一個序列同步的過程。
【3】輕量：Watcher通知非常簡單，只會告訴使用者端發生了事件，而不會說明事件的具體內容。使用者端向伺服器端註冊 Watcher的時候，並不會把使用者端真實的 Watcher物件實體傳遞到伺服器端，僅僅是在使用者端請求中使用 boolean型別屬性進行了標記。
【4】watcher event非同步傳送：watcher的通知事件從 server傳送到 client是非同步的，這就存在一個問題，不同的使用者端和伺服器之間通過 socket進行通訊，由於網路延遲或其他因素導致使用者端在不通的時刻監聽到事件，由於 Zookeeper本身提供了ordering guarantee，即使用者端監聽事件後，才會感知它所監視 znode發生了變化。所以我們使用 Zookeeper不能期望能夠監控到節點每次的變化。Zookeeper只能保證最終的一致性，而無法保證強一致性。
【5】註冊 watcher getData、exists、getChildren。
【6】觸發 watcher create、delete、setData。
【7】當一個使用者端連線到一個新的伺服器上時，watch將會被以任意對談事件觸發：當與一個伺服器失去連線的時候，是無法接收到 watch的。而當 client重新連線時，如果需要的話，所有先前註冊過的 watch，都會被重新註冊。通常這是完全透明的。只有在一個特殊情況下，watch可能會丟失：對於一個未建立的 znode的exist watch，如果在使用者端斷開連線期間被建立了，並且隨後在使用者端連線上之前又刪除了，這種情況下，這個 watch事件可能會被丟失。
六、使用者端註冊 Watcher實現
【1】呼叫 getData()/getChildren()/exist() 三個API，傳入Watcher物件；
【2】標記請求 request，封裝 Watcher到 WatchRegistration；
【3】封裝成 Packet物件，發伺服器端傳送 request；
【4】收到伺服器端響應後，將 Watcher註冊到 ZKWatcherManager中進行管理；
【5】請求返回，完成註冊；
七、伺服器端處理 Watcher實現
【1】伺服器端接收 Watcher並儲存：接收到使用者端請求，處理請求判斷是否需要註冊Watcher，需要的話將資料節點的節點路徑和 ServerCnxn（ServerCnxn代表一個使用者端和伺服器端的連線，實現了 Watcher的 process介面，此時可以看成一個 Watcher物件）儲存在 WatcherManager的 WatchTable和 watch2Paths中去。
【2】Watcher 觸發：以伺服器端接收到 setData() 事務請求觸發NodeDataChanged事件為例：
● 封裝 WatchedEvent：將通知狀態（SyncConnected）、事件型別（NodeDataChanged）以及節點路徑封裝成一個 WatchedEvent物件；
● 查詢 Watcher：從 WatchTable中根據節點路徑查詢 Watcher；
● 沒找到，說明沒有使用者端在該資料節點上註冊過 Watcher；
● 找到，提取並從 WatchTable和 Watch2Paths中刪除對應Watcher（從這裡可以看出Watcher在伺服器端是一次性的，觸發一次就失效了）；
【3】呼叫 process方法來觸發Watcher：這裡 process主要就是通過 ServerCnxn對應的 TCP連線傳送 Watcher事件通知。
八、使用者端回撥 Watcher
使用者端 SendThread執行緒接收事件通知，交由 EventThread執行緒回撥 Watcher。使用者端的 Watcher機制同樣是一次性的，一旦被觸發後，該 Watcher就失效了。
九、ZAB協定
ZAB協定是為分散式協調服務 Zookeeper專門設計的一種支援崩潰恢復的原子廣播協定。當整個 zookeeper叢集剛剛啟動或者 Leader伺服器宕機、重新啟動或者網路故障導致不存在過半的伺服器與 Leader伺服器保持正常通訊時，所有程序（伺服器）進入崩潰恢復模式，首先選舉產生新的 Leader伺服器，然後叢集中 Follower伺服器開始與新的 Leader伺服器進行資料同步，當叢集中超過半數機器與該 Leader伺服器完成資料同步之後，退出恢復模式進入訊息廣播模式，Leader伺服器開始接收使用者端的事務請求生成事物提案來進行事務請求處理。ZAB協定[連結]
十、Leader 選舉
詳細博文連結
十一、資料同步
整個叢集完成 Leader選舉後，Learner（Follower和Observer的統稱）會向 Leader伺服器進行註冊。當 Learner伺服器向 Leader伺服器完成註冊後，進入資料同步環節。
Zookeeper 的資料同步通常分為四類：
【1】直接差異化同步（DIFF同步）
【2】先回滾再差異化同步（TRUNC+DIFF同步）
【3】僅回滾同步（TRUNC同步）
【4】全量同步（SNAP同步）
進行資料同步前，Leader會完成資料同步初始化：
【1】peerLastZxid：Learner伺服器註冊時傳送的 ACKEPOCH訊息中提取 lastZxid（該Learner伺服器最後處理的ZXID）
【2】minCommittedLog：Leader伺服器 Proposal快取佇列 committedLog中最小ZXID；
【3】maxCommittedLog：Leader伺服器 Proposal快取佇列 committedLog中最大ZXID；
直接差異化同步（DIFF同步）：peerLastZxid介於 minCommittedLog 和 maxCommittedLog之間；
先回滾再差異化同步（TRUNC+DIFF同步）：當新的 Leader伺服器發現某個 Learner伺服器包含了一條自己沒有的事務記錄，那麼就需要讓該 Learner伺服器進行事務回滾，回滾到 Leader伺服器上存在的，同時也是最接近於 peerLastZxid的 ZXID；
僅回滾同步（TRUNC同步）：peerLastZxid 大於 maxCommittedLog；
全量同步（SNAP同步）：① peerLastZxid 小於 minCommittedLog；② Leader伺服器上沒有 Proposal快取佇列且 peerLastZxid不等於 lastProcessZxid；
十二、Zookeeper是如何保證事務的順序一致性的？
Zookeeper 採用了全域性遞增的事務ID 來標識，所有的 proposal（提議）都在被提出的時候加上了 zxid，zxid實際上是一個64位元的數位，高32位元是 epoch用來標識 Leader週期，如果有新的 Leader產生，epoch會自增，低32位元用來遞增計數。當新產生 proposal的時候，會依據資料庫的兩階段過程，首先會向其它的 server發出事務執行請求，如果超過半數的機器都能執行並且能夠成功，那麼就會開始執行。
十三、Zookeeper叢集管理（檔案系統、通知機制）
叢集管理包含兩點：是否有機器退出和加入、選舉 Master。
對於第一點，所有機器約定在父目錄下建立臨時目錄節點，然後監聽父目錄節點的子節點變化訊息。一旦有機器掛掉，該機器與 Zookeeper的連線斷開，其所建立的臨時目錄節點被刪除，所有其它機器都收到通知：某個兄弟目錄被刪除。新機器加入也類似，所有機器收到通知：新兄弟目錄加入節點。對於第二點，我們稍微改變一下，所有機器建立臨時順序編號目錄節點，每次選取編號最小的機器作為 Master就好。
十四、Zookeeper分散式鎖（檔案系統、通知機制）
有了 Zookeeper的一致性檔案系統，鎖的問題變得容易。鎖服務可以分為兩類，一是保持獨佔，另一個是控制時序。
對於第一類，我們將 Zookeeper上的一個 znode看作是一把鎖，通過 createznode的方式來實現。所有使用者端都去建立 /distribute_lock 節點，最終成功建立的那個使用者端也即擁有了這把鎖。用完刪除掉自己建立的distribute_lock 節點就釋放出鎖。
對於第二類， /distribute_lock 已經預先存在，所有使用者端在它下面建立臨時順序編號目錄節點，和選 Master一樣，編號最小的獲得鎖，用完刪除，依次方便。
十五、獲取分散式鎖的流程
在獲取分散式鎖的時候在 locker節點下建立臨時順序節點，釋放鎖的時候刪除該臨時節點。使用者端呼叫 createNode方法在 locker下建立臨時順序節點，然後呼叫 getChildren(「locker」)來獲取 locker下面的所有子節點，注意此時不用設定任何 Watcher。使用者端獲取到所有的子節點 path之後，如果發現自己建立的節點在所有建立的子節點序號最小，那麼就認為該使用者端獲取到了鎖。如果發現自己建立的節點並非 locker所有子節點中最小的，說明自己還沒有獲取到鎖，此時使用者端需要找到比自己小的那個節點，然後對其呼叫 exist()方法，同時對其註冊事件監聽器。之後，這個被關注的節點刪除，則使用者端的 Watcher會收到相應通知，此時再次判斷自己建立的節點是否是 locker子節點中序號最小的，如果是則獲取到了鎖，如果不是則重複以上步驟繼續獲取到比自己小的一個節點並註冊監聽。當前這個過程中還需要許多的邏輯判斷。
程式碼的實現主要是基於互斥鎖，獲取分散式鎖的重點邏輯在於 BaseDistributedLock，實現了基於 Zookeeper實現分散式鎖的細節。
十六、Zookeeper 使用那種設計模式？
觀察者模式【連結】
十七、叢集支援動態新增機器嗎？
其實就是水平擴容了，Zookeeper在這方面不太好。兩種方式：
【1】全部重新啟動：關閉所有 Zookeeper服務，修改設定之後啟動。不影響之前使用者端的對談。
【2】逐個重新啟動：在過半存活即可用的原則下，一臺機器重新啟動不影響整個叢集對外提供服務。這是比較常用的方式。
3.5版本開始支援動態擴容。
十八、Zookeeper資料複製
Zookeeper 作為一個叢集提供一致的資料服務，自然，它要在所有機器間做資料複製。資料複製的好處：
【1】容錯：一個節點出錯，不致於讓整個系統停止工作，別的節點可以接管它的工作；
【2】提高系統的擴充套件能力 ：把負載分佈到多個節點上，或者增加節點來提高系統的負載能力；
【3】提高效能：讓使用者端本地存取就近的節點，提高使用者存取速度。
從使用者端讀寫存取的透明度來看，資料複製叢集系統分下面兩種：
【1】寫主(WriteMaster) ：對資料的修改提交給指定的節點。讀無此限制，可以讀取任何一個節點。這種情況下使用者端需要對讀與寫進行區別，俗稱讀寫分離；
【2】寫任意(Write Any)：對資料的修改可提交給任意的節點，跟讀一樣。這種情況下，使用者端對叢集節點的角色與變化透明。
對 Zookeeper來說，它採用的方式是寫任意。通過增加機器，它的讀吞吐能力和響應能力擴充套件性非常好，而寫，隨著機器的增多吞吐能力肯定下降（這也是它建立 observer的原因），而響應能力則取決於具體實現方式，是延遲複製保持最終一致性，還是立即複製快速響應。