zookeeper的觀察者詳解

1 人贊了文章

閱讀本文之前，推薦閱讀：

基於zookeeper leader選舉方式一

Kafka源碼系列之源碼分析zookeeper在kafka的作用

觀察者簡介

回顧一下Zookeeper的運行時的角色。

觀察者的設計是希望能動態擴展zookeeper集群又不會降低寫性能。

雖然通過讓客戶端直接連接到集群的投票成員，ZooKeeper也表現得非常好，但是這種架構使得很難擴展到有大量的客戶端情況。問題是，隨著我們添加更多投票成員，寫入性能也會隨著下降。這是因為寫操作需要（通常）需要集群中至少一半的節點投票達成一致，因此隨著更多投票者的加入，投票的成本會顯著增加。

這裡引入一種新zookeeper節點類型，叫做觀察者，觀察者的引入幫助解決了上面的問題同時大大增加了zookeeper的動態擴展能力。觀察者不參與投票，只聽取投票結果。除了這個簡單的區別，Observers的功能與Followers完全相同 - 客戶端可以連接到它們並向它們發送讀寫請求。Observer會像follower一樣將消息轉發給leader，但是Observer只會聽取投票結果，不參與投票。由於這點，我們可以增加任意數量的Observer，同時不會影響我們集群的性能。

Observer還有其它優點。因為他們不投票，所以他們不是ZooKeeper集群的重要組成部分。 因此，它們可以失敗，或者與集群斷開連接，而不會損害ZooKeeper服務的可用性。對用戶的好處是Observer相比Follower來說更能通過不太可靠的網路鏈接進行連接。實際上，Observers可用於與另一個數據中心的ZooKeeper伺服器通信。Observers的客戶端可以快速讀取，因為所有讀取都在本地提供，並且寫入消耗最小的網路流量，因為在沒有投票協議的情況下所需的消息數量較少。

如何使用觀察者

在zookeeper集群中使用觀察者是非常簡單的，僅僅需要修改配置文件里的兩個配置即可。

在所有將會配置為zookeeper觀察者的節點，添加下面一行：

peerType=observer

這行配置告訴zookeeper這台伺服器將會成為一個Observers。

其次，在所有的伺服器節點，在server定義處需要在末尾增加:observer。例如：

server.1:localhost:2181:3181:observer

這會告訴其它服務server.1是一個observer，不會參與投票。

運行下面的命令即可鏈接到集群：

bin/zkCli.sh -server localhost:2181

使用案例

關於observer下面舉兩個使用案例。實際上，無論您希望擴展ZooKeeper集群的客戶端數量，還是希望將集群的關鍵部分與處理客戶端請求的負載隔離開來，Observers都是一個很好的架構選擇。

1， 作為一個數據中心橋樑(datacenterbridge)：為兩個數據中心構建同一套zookeeper集群是會費很大勁的，因為數據中心之間網路延遲的高度變化可能會導致故障檢測的誤報和集群分區。但是如果集群完全部署到一個數據中心，另一個數據中心用Observers，則分區問題不會出現了。Client依然可以看到和發布提案。

2，作為消息匯流排的鏈接：一些公司表示有興趣將ZK用作持久可靠消息匯流排的組件。 觀察者將為這項工作提供一個自然的集成點：插件機制可用於將觀察者看到的提案流附加到發布 - 訂閱系統，同樣不載入核心集群。