背景知識
這部分主要介紹什麼是分佈式系統以及分佈式系統存在哪些問題。
分佈式
互聯網技術的發展，導致大型網站需要的計算能力和存儲能力越來越高。網站架構逐漸從集中式轉變成分佈式。
什麼是分佈式
把一個計算任務分解為若干個計算單元，並分派到若干個不同的計算機中去執行，然後再彙總計算結果。
分佈式的工作方式有點類似於團隊合作。當有一項任務分配到某個團隊之後，團隊內部的成員開始各司其職，然後把工作結果統一彙總給團隊主管，由團隊主管再整理團隊的工作成果彙報給公司。
分佈式存在的問題
雖然分佈式和集中式系統相比有很多優勢，比如能提供更強的計算、存儲能力，避免單點故障等問題。但是由於採用分佈式部署的方式，就經常會出現網絡故障等問題，並且如何在分佈式系統中保證數據的一致性和可用性也是一個比較關鍵的問題。
比如在集中式系統中，有一些關鍵的配置信息，可以直接保存在服務器的內存中，但是在分佈式系統中，如何保存這些配置信息，又如何保證所有機器上的配置信息都保持一致，又如何保證修改一個配置能夠把這次修改同步到所有機器中呢？
再比如，在集中式系統中，進行一個同步操作要寫同一個數據的時候，可以直接使用事務+鎖來管理保證數據的ACID。但是，在分佈式系統中如何保證多臺機器不會同時寫同一條數據呢？
還有很多諸如此類的問題，大部分都是圍繞著分佈式系統中的數據的一致性問題。
在前一部分的Zookeeper背景知識中介紹過，隨著網站的不斷髮展，逐漸從集中式演變到分佈式。但是，在分佈式系統中存在著很多數據一致性的問題。那麼，有沒有什麼系統或者組件能夠幫助我們解決這些一致性問題呢？本文將簡單介紹一個分佈式服務協調組件——Zookeeper。
Zookeeper概述
什麼是Zookeeper
Zookeeper是一個開放源碼的分佈式服務協調組件，是Google Chubby的開源實現。是一個高性能的分佈式數據一致性解決方案。他將那些複雜的、容易出錯的分佈式一致性服務封裝起來，構成一個高效可靠的原語集，並提供一系列簡單易用的接口給用戶使用。
Zookeeper提供了哪些特性
他解決的分佈式數據一致性問題，提供了順序一致性、原子性、單一視圖、可靠性、實時性等。
順序一致性：客戶端的更新順序與他們被髮送的順序相一致；
原子性：更新操作要麼全部成功，要麼全部失敗；
單一試圖：無論客戶端連接到哪一個服務器，都可以看到相同的ZooKeeper視圖；
可靠性：一旦一個更新操作被應用，那麼在客戶端再次更新它之前，其值將不會被改變；
實時性：在特定的一段時間內，系統的任何變更都將被客戶端檢測到；
Zookeeper工作過程
上圖中，一個Zookeeper集群中有五臺機器，在整個集群剛剛啟動的時候，會進行Leader選舉，當Leader確定之後，其他機器自動成為Follower，並和Leader建立長連接，用於數據同步和請求轉發等。當有客戶端機器的寫請求落到follower機器上的時候，follower機器會把請求轉發給Leader，由Leader處理該請求，比如數據的寫操作，在請求處理完之後再把數據同步給所有的follower。
CAP理論
在分佈式領域，有一個著名的理論——CAP理論。CAP理論的核心觀點是任何軟件系統都無法同時滿足一致性、可用性以及分區容錯性。
值得一提的是，作為一個分佈式系統，分區容錯性是一個必須要考慮的關鍵點。一個分佈式系統一旦喪失了分區容錯性，也就表示放棄了擴展性。因為在分佈式系統中，網絡故障是經常出現的，一旦出現在這種問題就會導致整個系統不可用是絕對不能容忍的。所以，大部分分佈式系統都會在保證分區容錯性的前提下在一致性和可用性之間做權衡。
在CAP這三個關鍵的性質中，同時滿足CA兩點的是著名的數據庫中ACID、同時滿足AP兩點的是註明的BASE理論。
Zookeeper和CAP的關係
上面介紹過，沒有任何一個分佈式系統可以同時滿足CAP，Zookeeper一般以集群的形式對外提供服務，那麼Zookeeper在CAP中是如何取捨的呢？
ZooKeeper是個CP（一致性+分區容錯性）的，即任何時刻對ZooKeeper的訪問請求能得到一致的數據結果，同時系統對網絡分割具備容錯性;但是它不能保證每次服務請求的可用性(注：也就是在極端環境下，ZooKeeper可能會丟棄一些請求，消費者程序需要重新請求才能獲得結果)。但是別忘了，ZooKeeper是分佈式協調服務，它的 職責是保證數據(注：配置數據，狀態數據)在其管轄下的所有服務之間保持同步、一致;所以就不難理解為什麼ZooKeeper被設計成CP而不是AP特性的了，如果是AP的，那麼將會帶來恐怖的後果(注：ZooKeeper就像交叉路口的信號燈一樣，你能想象在交通要道突然信號燈失靈的情況嗎?)。而且， 作為ZooKeeper的核心實現算法 Zab，就是解決了分佈式系統下數據如何在多個服務之間保持同步問題的。
如果 ZooKeeper下所有節點都斷開了，或者集群中出現了網絡分割的故障(注：由於交換機故障導致交換機底下的子網間不能互訪);那麼ZooKeeper 會將它們都從自己管理範圍中剔除出去，外界就不能訪問到這些節點了，即便這些節點本身是“健康”的，可以正常提供服務的;所以導致到達這些節點的服務請求 被丟失了。
好了，本篇文章到此就結束了。後續會伺機推出Zookeeper其它相關內容，以供參考
閱讀更多 牛旦教育IT課堂 的文章
