目錄

• 概念
• 背景介紹
• zookeeper一致性
• 使用建議

概念

ZooKeeper是一個開源的分散式協調服務，它為分散式應用提供了高效且可靠的分散式協調服務，提供的功能包括:配置維護、域名服務、分散式同步、組服務等。

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都來拉取，瞬間造成非常大的網路流量，引起所謂的『驚群』。而自己實現通用配置系統的時候，一般會對這種配置採取排隊或分批通知的方式。

Apache：