Zookeeper監控的原理

之前寫的負載均衡伺服器專案，只能在啟動時配置結點，執行狀態時節點當機倒是可以刪除它。但是不能實時得檢測節點資訊，尤其是如果新增節點還要伺服器重啟重新配置，本文的 Zookeeper 給了我一個思路。

當服務越來越多，規模越來越大時，對應的機器數量也越來越大，單靠人工來管理和維護服務及地址的配置地址資訊，已經很困難了，並且，依賴單一的硬體負載均衡裝置或者使用LVS.nginx等軟體方案進行路由和負載均衡排程，單點故障的問題也開始凸顯，一旦服務路由或者負載均衡伺服器當機，依賴他的所有服務均將失效。

         此時，需要一個能夠動態註冊和獲取服務資訊的地方。來統一管理服務名稱和其對應的伺服器列表資訊，稱之為服務配置中心，服務提供者在啟動時，將其提供的服務名稱、伺服器地址註冊到服務配置宗新，服務消費者通過服務配置中心來獲得需要呼叫的服務的機器列表。通過相應的負載均衡演算法，選取其中一臺伺服器進行呼叫。當伺服器當機或者下線時，相應的機器需要能夠動態地從服務配置中心裡面溢位，並通知相應的服務消費者，否則服務消費者就有可能因為呼叫到已經失效服務而發生錯誤，在這個過程中，服務消費者只有在第一次呼叫服務時需要查詢服務配置中心，然後將查詢到的資訊快取到本地，後面的呼叫直接使用本地快取的服務地址列表資訊，而不需要重新發起請求道服務配置中心去獲取相應的服務地址列表，直到服務的地址列表有變更（機器上線或者下線）。這種無中心化的結構解決了之前負載均衡裝置所導致的單點故障問題，並且大大減輕了服務配置中心的壓力

         基於Zookeeper的持久和非持久節點，我們能夠近乎實時地感知到後端伺服器的狀態（上線、下線、當機）通過叢集間的zab協議，使得服務配置資訊能夠保持一致。而zookeeper本身容錯特性和leader選舉機制，能保障我們方便進行擴容，通過zookeeper來實現服務動態註冊。機器上線和下線的動態感知，擴容方便，容錯性好，且無中心化結構能夠解決之前使用負載均衡裝置所帶來的單點故障問題，只有當配置資訊更新時才會去zookeeper上獲取最新的服務地址列表，其他時候使用本地快取即可。
 
         一旦伺服器與zookeeper叢集斷開連線，節點也就不存在了，通過註冊相應的watcher，服務消費者能夠第一時間獲知服務提供者機器資訊的變更，利用其znode的特點和watcher機制，將其作為動態註冊和獲取服務資訊的配置中心，統一管理服務名稱和其對應的伺服器列表資訊，我們能夠近乎實時地感知到後端伺服器的狀態（上線、下線、當機）.zookeeper叢集間通過zab協議，服務配置資訊能夠保持一致，而zookeeper本身容錯特性和leader選舉機制，能夠保障我們方便的擴容。


--from《大型分散式網站架構設計與實踐》

轉自：http://blog.csdn.net/yusiguyuan/article/details/47682537