配置管理在我們的應用中除了程式碼外，還有一些就是各種配置。比如資料庫連線等。一般我們都是使用配置檔案的方式，在程式碼中引入這些配置檔案。當我們只有一種配置，只有一臺伺服器，並且不經常修改的時候，使用配置檔案是一個很好的做法，但是如果我們配置非常多，有很多伺服器都需要這個配置，這時使用配置檔案就不是個好主意了。這個時候往往需要尋找一種集中管理配置的方法，我們在這個集中的地方修改了配置，所有對這個配置感興趣的都可以獲得變更。Zookeeper 就是這種服務，它使用 Zab 這種一致性協議來提供一致性。現在有很多開源專案使用 Zookeeper 來維護配置，比如在 HBase中，客戶端就是連線一個 Zookeeper，獲得必要的 HBase 叢集的配置資訊，然後才可以進一步操作。還有在開源的訊息佇列 Kafka 中，也使用 Zookeeper 來維護 broker 的資訊。在 Alibaba 開源的 SOA 框架 Dubbo 中也廣泛的使用 Zookeeper 管理一些配置來實現服務治理。名字服務名字服務這個就很好理解了。比如為了透過網路訪問一個系統，我們得知道對方的IP 地址，但是 IP 地址對人非常不友好，這個時候我們就需要使用域名來訪問。但是計算機是不能是域名的。怎麼辦呢？如果我們每臺機器裡都備有一份域名到 IP 地址的對映，這個倒是能解決一部分問題，但是如果域名對應的 IP 發生變化了又該怎麼辦呢？於是我們有了 DNS 這個東西。我們只需要訪問一個大家熟知的(known)的點，它就會告訴你這個域名對應的 IP 是什麼。在我們的應用中也會存在很多這類問題，特別是在我們的服務特別多的時候，如果我們在本地儲存服務的地址的時候將非常不方便，但是如果我們只需要訪問一個大家都熟知的訪問點，這裡提供統一的入口，那麼維護起來將方便得多了。分散式鎖其實在第一篇文章中已經介紹了 Zookeeper 是一個分散式協調服務。這樣我們就可以利用 Zookeeper 來協調多個分散式程序之間的活動。比如在一個分散式環境中，為了提高可靠性，我們的叢集的每臺伺服器上都部署著同樣的服務。但是，一件事情如果叢集中的每個伺服器都進行的話，那相互之間就要協調，程式設計起來將非常複雜。而如果我們只讓一個服務進行操作，那又存在單點。通常還有一種做法就是使用分散式鎖，在某個時刻只讓一個服務去幹活，當這臺服務出問題的時候鎖釋放，立即 fail over 到另外的服務。這在很多分散式系統中都是這麼做，這種設計有一個更好聽的名字叫 LeaderElection(leader 選舉)。比如 HBase 的 Master 就是採用這種機制。但要注意的是分散式鎖跟同一個程序的鎖還是有區別的，所以使用的時候要比同一個程序裡的鎖更謹慎的使用。叢集管理在分散式的叢集中，經常會由於各種原因，比如硬體故障，軟體故障，網路問題，有些節點會進進出出。有新的節點加入進來，也有老的節點退出叢集。這個時候，叢集中其他機器需要感知到這種變化，然後根據這種變化做出對應的決策。比如我們是一個分散式儲存系統，有一箇中央控制節點負責儲存的分配，當有新的儲存進來的時候我們要根據現在叢集目前的狀態來分配儲存節點。這個時候我們就需要動態感知到叢集目前的狀態。還有，比如一個分散式的 SOA 架構中，服務是一個叢集提供的，當消費者訪問某個服務時，就需要採用某種機制發現現在有哪些節點可以提供該服務(這也稱之為服務發現，比如Alibaba 開源的 SOA 框架 Dubbo 就採用了 Zookeeper 作為服務發現的底層機制)。還有開源的 Kafka 佇列就採用了 Zookeeper 作為 Cosnumer 的上下線管理。