爲啥這麼多公司用 ZooKeeper？它到底解決了什麼問題？

目標

ZooKeeper 很流行，有個基本的疑問：

• ZooKeeper 是用來作什麼的？
• 以前沒有ZK，爲何會誕生 ZK？

OK，解答一下上面的疑問：（下面是憑直覺說的）

• ZooKeeper 是用於簡化分佈式應用開發的，對開發者屏蔽一些分佈式應用開發過程當中的底層細節
• ZooKeeper 對外暴露簡單的 API，用於支持分佈式應用開發
• ZooKeeper 在提供上述功能的同時，其仍是一個 高性能、高可用、高可靠的分佈式集羣

上面說這麼多，總結一下，ZK 能解決分佈式應用開發的問題，ZK 能很好的解決問題。到這一步，疑問就更多了：

• 分佈式應用開發，有哪些常見問題？ZK 是如何屏蔽這些底層細節的？
• ZooKeeper 對外暴露了那些 API？這些 API 如何支持分佈式應用開發的？這些 API 還-能簡化嗎？API 的語義性怎麼樣？
• ZooKeeper 自身是一個高性能、高可用、高可靠的分佈式集羣，那有個簡單的問題：
• 高性能是指什麼？ZooKeeper 爲了達到高性能，作了哪些工做？
• 高可用同上
• 高可靠同上

爲何有ZooKeeper

一個應用程序，涉及多個進程協做時，業務邏輯代碼中混雜有大量複雜的進程協做邏輯。上述多進程協做邏輯，有 2 個特色：

• 處理複雜
• 處理邏輯可重用

所以，考慮將多進程協做的共性問題拎出，做爲基礎設施，讓 RD 更加專一業務邏輯開發，即：ZooKeeper 就是上述多進程協做基礎服務的一種。

ZooKeeper的特色

ZooKeeper 有幾個簡單特色：

• ZooKeeper 的 API：從 文件系統 API 獲得的啓發，提供簡單的 API
• ZooKeeper 運行在專用服務器上，跟業務邏輯分離，保證了高容錯性和可擴展性

ZooKeeper 是存儲設施，但特別注意

• ZK上存儲的數據聚焦爲：協做數據（元數據），而不是應用數據，應用數據有本身的存儲方案，例如 HDFS 等
• ZK 本質上，能夠看做一種特殊的 FS

特別說明：應用數據和元數據，因爲使用場景不一樣，對一致性和持久性的要求有差別， 所以，架構設計、數據治理過程當中，應將 2 類數據獨立看待、獨立存儲。

ZooKeeper的使命

ZK 要解決的核心問題：

ZK 目標：簡化分佈式應用開發中，多進程協做問題。爲分佈式應用，提供高效、可靠的分佈式協調服務（基礎服務），例如：

• 統一的命名服務
• 分佈式鎖
• 進程崩潰檢測
• Leader 選舉

配置管理：配置變動時，及時下發到各個 Client。

一個簡單的問題：多進程的協做是什麼？尼瑪呀，有完沒完，啥問題你都有，面對這個掉咋天的腦袋，仍是回答一下。

多進程協做，總體分爲 2 類：

• 協做：多進程須要一同處理某些事情，一些進程採起行動是的其餘進程可以正常工做，例如：主從結構，M 向 S 分配任務，S 纔會執行，不然 S 就保持空閒狀態
• 競爭：兩個進程不能同時工做，一個進程必須等待另個進程執行完畢，例如：主從結構，M 節點失效後，不少 S 都想成爲 M，這時，就須要互斥鎖，只有第一個得到鎖的 S 成爲 M

特別說明：

• 不跨網絡協做：多進程，能夠在同一臺物理主機上，同步原語很方便(好比？管道、共享內存、消息隊列、信號量)
• 跨網絡協做：多進程，分佈在不一樣的物理主機上，ZK 關注這一類

跨網絡多進程協做，進程通訊，基本思路有 2 個：

• 消息機制：經過網絡，直接信息交換，多消息傳遞算法，實現同步原語
• 共享存儲：利用外部共享存儲，實現多進程協做，要求共享存儲提供有序訪問，ZK 採用這種方式

真實系統中，跨網絡通訊，有幾個共性問題：

• 消息延遲：因爲網絡緣由，後發送先到達
• 處理器性能：因爲系統調度緣由，消息到達後，延遲處理
• 時鐘偏移：不一樣物理主機，時鐘發生偏移

ZK 精心設計用於屏蔽上述 3 個共性問題，使得這些問題在應用服務層面徹底透明化。

ZooKeeper 特性

ZooKeeper 解決的本質問題

分佈式系統的一致性問題：

• 消息傳遞：延遲性，先發送的消息，不必定先到達；
• 消息傳遞：丟失性，發送的消息，可能丟失；
• 節點崩潰：分佈式系統內，任何一個節點均可能崩潰；

在這種狀況下，如何保證數據的一致性？

• 提案投票：基於投票策略，2PC
• 選舉投票：基於投票策略，投出優先級最高的節點（包含最新數據的節點）

Paxos 目標：解決分佈式一致性問題，提升分佈式系統容錯性的一致性算法。

Paxos 本質：基於消息傳遞的高度容錯的一致性算法

ZooKeeper 定位

ZooKeeper 是：

• 分佈式協調服務
• 高效、可靠
• 方便應用程序，聚焦業務邏輯開發，而不須要過多關注分佈式進程間協做細節

ZooKeeper 不直接暴露原語，而是，暴露一部分調用方法組成的 API，相似文件系統的 API，支持應用程序實現本身的原語。

ZooKeeper 特性

ZooKeeper 能夠保證以下分佈式一致性特性：

• 順序一致性：同一個 Client 發起的事務請求，嚴格按照發起順序執行
• 原子性：事務請求，要麼應用到全部節點，要麼一個節點都沒有應用
• 單一視圖：Client 不管鏈接到哪一個節點，看到的服務端數據都是一致的（Note：不許確，實際上是最終一致性）
• 可靠性：事務一旦執行成功，狀態永久保留
• 實時性：事務一旦執行成功，Client 並不能當即看到最新數據，但 ZooKeeper 保證最終一致性

ZooKeeper 設計目標

ZooKeeper 致力於提供高性能、高可用、順序一致性的分佈式協調服務，保證數據最終一致性。

目標一：高性能（簡單的數據模型）

• 採用樹形結構組織數據節點；
• 全量數據節點，都存儲在內存中；
• Follower 和 Observer 直接處理非事務請求；

目標二：高可用（構建集羣）

• 半數以上機器存活，服務就能正常運行
• 自動進行 Leader 選舉

目標三：順序一致性（事務操做的順序）

• 每一個事務請求，都會轉發給 Leader 處理
• 每一個事務，會分配全局惟一的遞增id（zxid，64位：epoch + 自增 id）

目標四：最終一致性

• 經過提議投票方式，保證事務提交的可靠性
• 提議投票方式，只能保證 Client 收到事務提交成功後，半數以上節點可以看到最新數據

ZooKeeper 出現以前

ZK 出現以前，分佈式系統經常使用兩種方式，實現多進程協做：

• 分佈式鎖管理器
• 分佈式數據庫

ZK 更專一於進程協做，而不提供任何鎖接口和通用的存儲數據接口。（疑問：ZK 也能夠提供啊，咱們不使用就好了）

應用服務器，常見的 2 種需求：

• Master-Slave Leader 選舉：要求提供Master節點選舉功能
• 進程響應跟蹤崩潰檢測：要求提供進程存活狀態的跟蹤
• 分佈式鎖：互斥排它鎖

ZK 爲上述 2 種策略提供了基礎 API。

ZooKeeper 不適用的場景：

海量數據存儲：ZK 本質是特殊的 FS，但 ZK 用於存儲元數據，須要單獨存儲應用數據

專業術語介紹

文章來源：http://ningg.top/zookeeper-po...