概念
ZooKeeper是一個分佈式的，開放源碼的分佈式應用程序協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個為分佈式應用提供一致性服務的軟件，提供的功能包括:配置維護、域名服務、分佈式同步、組服務等。
ZooKeeper的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。
背景介紹
zookeeper實際上是yahoo開發的，用於分佈式中一致性處理的框架。最初其作為研發Hadoop時的副產品。由於分佈式系統中一致性處理較為困難，其他的分佈式系統沒有必要 費勁重複造輪子，故隨後的分佈式系統中大量應用了zookeeper。故隨後的大部分分佈式系統中大量應用了zookeeper，以至於zookeeper成為了各種分佈式系統的基礎組件，其地位之重要，可想而知。
zookeeper一致性
實際上就是圍繞著“看見”來的。誰能看見？能否看見？什麼時候看見？舉個例子：淘寶後臺賣家，在後臺上架一件大促的商品，通過服務器A提交到主數據庫，假設剛提交後立馬就有用戶去通過應用服務器B去從數據庫查詢該商品，就會出現一個現象，賣家已經更新成功了，然而買家卻看不到；而經過一段時間後，主數據庫的數據同步到了從數據庫，買家才能查到。
使用建議
- 不要強依賴Zookeeper，也就是Zookeeper出現問題業務已然可以正常運行。Zookeeper是一個分佈式的協調框架，主要做的事情就是分佈式環境的一致性。這是一個非常苛刻的事情，所以它的穩定性受很多方面的影響。比如我們常常使用Zookeeper做服務發現，那麼服務發現其實是不需要嚴格的一致性的，我們可以緩存server list，當Zookeeper出現問題的時候已然可以正常工作，在這方面etcd要做的更好一些，Zookeeper如果出現分區，少數派是不能提供任何服務的，讀都不可以，而etcd的少數派仍然可以提供讀服務，這在服務發現的時候還是不錯的。
- 不要將很多東西塞到Zookeeper裡，這個上面已經提到過。
- 不要使用Zookeeper做細粒度鎖，比如很多業務在訂單這個粒度上使用Zookeeper做分佈式鎖，這會頻繁的和Zookeeper交互，對Zookeeper壓力較大，而且一旦出現問題影響面廣。但是可以使用粗粒度的鎖(其實leader選舉也是一種鎖)。
- 不建議做通用配置的第二個理由是，通用配置要提供給特別多特別多系統使用，而且一些公共配置甚至所有系統都會使用，一旦這樣的配置發生變更，Zookeeper會廣播給所有的watcher，然後所有Client都來拉取，瞬間造成非常大的網絡流量，引起所謂的『驚群』。而自己實現通用配置系統的時候，一般會對這種配置採取排隊或分批通知的方式。
分享到:
閱讀更多 咱小二 的文章
