一篇文章帶你深入理解Zookeeper
隨著網際網路技術的發展，大型網站需要的計算能力和儲存能力越來越高。網站架構逐漸從集中式轉變成分散式。
雖然分散式和集中式系統相比有很多優勢，比如能提供更強的計算、儲存能力，避免單點故障等問題。但是由於採用分散式部署的方式，就經常會出現網路故障等問題，並且如何在分散式系統中保證資料的一致性和可用性也是一個比較關鍵的問題。
分散式的工作方式有點類似於團隊合作。當有一項任務分配到某個團隊之後，團隊內部的成員開始各司其職，然後把工作結果統一彙總給團隊主管，由團隊主管再整理團隊的工作成果彙報給公司。
但是，日常工作中，如果兩個員工或使用者對某件事產生了分歧，通常我們的做法是找上級，去做資料和資訊的同步。
那麼對於我們的服務呢，多個節點之間資料不同步如何處理？
對於分散式叢集來說，這個時候，我們通常一個能夠在 各個服務或節點之間 進行 協調 的 服務或中間人
架構設計中，沒有一個問題不能通過增加一個 抽象層 來解決的，如果有，那就增加兩層。
叢集管理
我們可以一起看看，協調服務中的佼佼者--ZooKeeper
zookeeper起源
最初，在Hadoop生態中，會存在很多的服務或元件（比如hive、pig等），每個服務或元件之間進行協調處理是很麻煩的一件事情，急需一種高可用高效能資料強一致性的協調框架。
因此雅虎的工程師們創造了這個中間程式，但中間程式的命名卻愁死了開發人員，突然想到hadoop中的大多是動物名字，似乎缺乏一個管理員，這個程式的功能有是如此的相似。因此zookeeper誕生。
Zookeeper是一個開放原始碼的分散式服務協調元件，是Google Chubby的開源實現。是一個高效能的分散式資料一致性解決方案。他將那些複雜的、容易出錯的分散式一致性服務封裝起來，構成一個高效可靠的原語集，並提供一系列簡單易用的介面給使用者使用。
zookeeper提供了哪些特性，以便於能夠很好的完成協調能力的處理呢？
功能與特性
資料儲存
zookeeper提供了類似Linux檔案系統一樣的資料結構。每一個節點對應一個Znode節點，每一個Znode節點都可以儲存1MB（預設）的資料。
客戶端對zk的操作就是對Znode節點的操作。
zookeeper資料結構
· Znode:包含ACL許可權控制、修改/訪問時間、最後一次操作的事務Id(zxid)等等
· 說有資料儲存在記憶體中，在記憶體中維護這麼一顆樹。
· 每次對Znode節點修改都是保證順序和原子性的操作。寫操作是原子性操作。
舉個例子，在註冊中心中，可以通過路徑"/fsof/服務名1/providers"找到"服務1"的所有提供者。
每一個Znode節點又根據節點的 生命週期 與 型別 分為4種節點。
· 生命週期：當客戶端會話結束的時候，是否清理掉這個會話建立的節點。持久-不清理，臨時-清理。
· 型別：每一個會話，建立單獨的節點（例子：正常節點：rudytan,順序編號節點：rudytan001,rudytan002等等）
監聽機制
zookeeper除了提供對Znode節點的處理能力，還提供了對節點的變更進行監聽通知的能力。
監聽機制的步驟如下：
1.任何session(session1,session2)都可以對自己感興趣的znode監聽。
2.當znode通過session1對節點進行了修改。
3.session1,session2都會收到znode的變更事件通知。
節點常見的事件通知有：
· session建立成功事件
· 節點新增
· 節點刪除
· 節點變更
· 子節點列表變化
需要特別說明的是：
一次監聽事件，只會被觸發一次，如果想要監聽到znode的第二次變更，需要重新註冊監聽。
到這裡，我們瞭解到zookeeper提供的能力，那我們在哪些場景可以使用它？如何使用它呢？
應用場景
zookeeper用得比較多的地方可能是，微服務的叢集管理與服務註冊與發現。
註冊中心
· 依賴於 臨時節點
· 消費者啟動的時候，會先去註冊中心中全量拉取服務的註冊列表。
· 當某個服務節點有變化的時候，通過 監聽機制 做資料更新。
· zookeeper掛了，不影響消費者的服務呼叫。
目前還有個比較流行的服務Eureka也可以做註冊中心，他們有什麼優勢和劣勢呢？
註冊中心的對比
通過上面的架構圖，可以發現Eureka不同於zk中的節點，Eureka中的節點每一個節點對等。是個AP系統，而不是zk的CP系統。 在註冊中心的應用場景下，相對於與強資料一致性，更加關心可用性。
分散式鎖
· 依賴於 臨時順序節點
· 判斷當前client的順序號是否是最小的，如果是獲取到鎖。
· 沒有獲取到鎖的節點監聽最小節點的刪除事件（比如lock_key_001）
· 鎖釋放，最小節點刪除，剩餘節點重新開始獲取鎖。
· 重複步驟二到四。
redis和db也能建立分散式鎖，那有什麼異同呢？
分散式鎖的對比
具體差異比較：
從理解的難易程度角度（從低到高） 資料庫 > 快取（Redis） > Zookeeper
從實現的複雜性角度（從低到高） Zookeeper >= 快取（Redis） > 資料庫
從效能角度（從高到低） 快取（Redis） > Zookeeper >= 資料庫
從可靠性角度（從高到低） Zookeeper > 快取（Redis） > 資料庫
叢集管理與master選舉
· 依賴於 臨時節點
· zookeeper保證 無法重複建立一個已存在的資料節點 ，建立成功的client為master。
· 非master，在已經建立的節點上 註冊節點刪除事件 監聽。
· 當master掛掉後，其他叢集節點收到節點刪除事件，進行重新選舉
· 重複步驟二到四
當然還有其他應用場景，不一一列舉了。
有人說，zookeeper可以做分散式配置中心、分散式訊息佇列，看到這裡的小夥伴們，你們覺得合適麼？
到這裡，可以基本上滿足基於zk應用開發的理論知識儲備。
高效能高可用強一致性保障
高效能-分散式叢集
高效能，我們通常想到的是通過叢集部署來突破單機的效能瓶頸。對於zk來說，就是通過部署多個節點共同對外提供服務，來提供讀的高效能。
· Master/Slave模式。
· 在zookeeper中部署多臺節點對外提供服務，客戶端可以連線到任意一個節點。
· 每個節點的資料都是一樣的。
· 節點根據角色分為Leader節點與Learner節點（包括Follower節點與Observer節點）。
· 叢集中，只有一個Leader節點，完成所有的寫請求處理。
· 每次寫請求都會生成一個全域性的唯一的64位整型的事務ID(可以理解為全域性的資料的版本號)。
· Learner節點可以有很多，每個Leaner可以獨自處理讀請求，轉寫請求到Leader節點。
· 當Leader節點掛掉後，會從Follower節點中通過選舉方式選出一個Leader提供對外服務。
· Follower節點與Observer節點區別在於不參與選舉和提議的事務過半處理。
· 叢集通常是按照奇數個節點進行部署（偶然太對容災沒啥影響，浪費機器）。
資料一致性（zab協議-原子廣播協議）
通過叢集的部署，根據CAP原理，這樣，可能導致同一個資料在不同節點上的資料不一致。zookeeper通過zab原子廣播協議來保證資料在每一個節點上的一致性。原子廣播協議（類似2PC提交協議）大概分為3個步驟。
· Leader包裝寫請求，生成唯一zxid，發起提議，廣播給所有Follower。
· Follower收到提議後，寫入本地事務日誌，根據自身情況，是否同意該事務的提交。
· Leader收到過半的Follower同意，自己先新增事務。然後對所有的Learner節點發送提交事務請求。
需要說明的是，zookeeper對資料一致性的要求是：
· 順序一致性：嚴格按照事務發起的順序執行寫操作。
· 原子性：所有事務請求的結果在叢集中的所有節點上的應用情況是一致的。
· 單一檢視：客戶端訪問任何一個節點，看到的資料模型都是一致的。
· 實時性：保證在極小一段時間客戶端最終可以從服務讀取最新資料狀態（如果要實時，需要客戶端呼叫syn方法）。
可用性-leader選舉（zab協議-崩潰恢復協議）
在整個叢集中，寫請求都集中在一個Leader節點上，如果Leader節點掛了咋辦呢？
當叢集初始化或Follower無法聯絡上Leader節點的時候，每個Follower開始進入選舉模式。選舉步驟如下：
1.Follower節點第一次投票先投自己，然後將自己的選票廣播給剩餘的Follower節點。
2.Follower節點接收到其他的選票。
3.選票比較：比較自己的與接收的選票的投票更有。
4.如果資金的選票不是最優選票，變更自己的選票，投最優選票的節點。
5.統計自己收到的選票，如果某個節點獲得了過半的節點的投票。確認該節點為新的Leader節點。
6.確認Leader節點後，每個節點變更自己的角色。完成投票選舉。
選舉原則：誰的資料最新，誰就有優先被選為Leader的資格。
舉個例子，假如現在zk叢集有5個節點，然後掛掉了2個節點。剩餘節點S3,S4,S6開始進行選舉，他們的最大事務ID分別是6,2,6。定義投票結構為（投票的節點ID，被投節點ID，被投節點最大事務ID）。
1.初始狀態，S3,S4,S5分別投自己，並帶上自己的最大事務ID。
2.S3,S4,S5分別對自己收到的2票與自己的1票做比較。
3.S5發現自己的是最優投票，不變更投票，S3,S4發現S5的投票是最優解，更改投票。
4.S3,S4廣播自己變更的投票。
5.最後大家都確認了S5是Leader，S5節點狀態變更為Leader節點，S3,S4變更為Follower節點。
到這裡，就是選舉的主要過程。
資料的持久化
· zookeeper所有資料都存在記憶體中。
· zookeeper會定期將記憶體dump到磁碟中，形成 資料快照 。
· zookeeper每次的事務請求，都會先接入到磁碟中，形成 事務日誌 。
· 全量資料 = 資料快照 + 事務日誌。
Zookeeper和CAP的關係
前面提到了zk在可用性、資料一致性、效能等方面都表現的很優秀，也介紹了其中的原理。
但是分散式系統的CAP理論告訴我們：任何軟體系統都無法同時滿足一致性、可用性以及分割槽容錯性。
那麼，Zookeeper其實也是一個分散式系統，那麼也就要滿足CAP理論，也就是說，雖然在各個方面，ZK可以說是做了很多努力，但是在極端情況下，Zookeeper也需要在這三者之間有一些權衡，那麼Zookeeper在CAP中是如何取捨的呢？
ZooKeeper是個CP（一致性+分割槽容錯性）的，即任何時刻對ZooKeeper的訪問請求能得到一致的資料結果，同時系統對網路分割具備容錯性，但是它不能保證每次服務請求的可用性(注：也就是在極端環境下，ZooKeeper可能會丟棄一些請求，消費者程式需要重新請求才能獲得結果)。
但是別忘了，ZooKeeper是分散式協調服務，它的職責是保證資料(注：配置資料，狀態資料)在其管轄下的所有服務之間保持同步、一致，所以就不難理解為什麼ZooKeeper被設計成CP而不是AP特性的了。
如果是AP的，那麼將會帶來恐怖的後果(注：ZooKeeper就像交叉路口的訊號燈一樣，你能想象在交通要道突然訊號燈失靈的情況嗎?)。
而且， 作為ZooKeeper的核心實現演算法 Zab，就是解決了分散式系統下資料如何在多個服務之間保持同步問題的。
如果 ZooKeeper下所有節點都斷開了，或者叢集中出現了網路分割的故障(注：由於交換機故障導致交換機底下的子網間不能互訪)。
那麼ZooKeeper 會將它們都從自己管理範圍中剔除出去，外界就不能訪問到這些節點了，即便這些節點本身是“健康”的，可以正常提供服務的;所以導致到達這些節點的服務請求被丟失了。
那麼，再來深入原理看一下Zookeeper是如何在CAP之間做權衡的呢？
感悟
最後，說說在整個學習和使用zk過程中的一個感悟吧。
· 沒有銀彈，每一種技術或方案都有其優點和缺點。
· 做一件事情很簡單，做好一件事件很難。