Observers：在不傷害寫性能的情況下擴展Zookeeper

雖然通過Client直接連接到Zookeeper集群的性能已經很好了，可是這樣的架構假設要承受超大規模的Client，就必須添加Zookeeper集群的Server數量，隨著Server的添加，Zookeeper集群的寫性能必定下降。我們知道Zookeeper的Znode變更是要過半數投票通過，隨著機器的添加，因為網絡消耗等原因必定導致投票成本添加，從而導致寫性能的下降。

Observer是一種新型的Zookeeper節點。能夠幫助解決上述問題，提供Zookeeper的可擴展性。Observer不參與投票，僅僅是簡單的接收投票結果。因此我們添加再多的Observer，也不會影響集群的寫性能。除了這個區別，其它的和Follower基本上全然一樣。

比如：Client都能夠連接到他們，而且都能夠發送讀寫請求給他們，收到寫請求都會上報到Leader。

Observer有另外一個優勢，由於它不參與投票，所以他們不屬於Zookeeper集群的關鍵部位，即使他們Failed，或者從集群中斷開，也不會影響集群的可用性。

依據Observer的特點。我們能夠使用Observer做跨數據中心部署。假設把Leader和Follower分散到多個數據中心的話，由於數據中心之間的網絡的延遲。勢必會導致集群性能的大幅度下降。使用Observer的話，將Observer跨機房部署。而Leader和Follower部署在單獨的數據中心，這樣更新操作會在同一個數據中心來處理，並將數據發送的其它數據中心（包括Observer的），然後Client就能夠在其它數據中心查詢數據了。可是使用了Observer並不是就能全然消除數據中心之間的延遲，由於Observer還得接收Leader的同步結果合Observer有更新請求也必須轉發到Leader，所以在網絡延遲非常大的情況下還是會有影響的，它的優勢就為了本地讀請求的高速響應。

使用Observer

假設要使用Observer模式，能夠在相應節點的配置文件加入例如以下配置：

peerType=observer

server.1:localhost:2181:3181:observer

眼下我的工作中就用到了Observer，大致的架構例如以下圖：

Zookeeper之基於Observer部署架構