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

來源：http://ningg.top/zookeeper-positioning

# 目標(biāo)

ZooKeeper 很流行，有個(gè)基本的疑問：

• ZooKeeper 是用來做什么的？
• 之前沒有ZK，為什么會(huì)誕生 ZK？

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

• ZooKeeper 是用于簡(jiǎn)化分布式應(yīng)用開發(fā)的，對(duì)開發(fā)者屏蔽一些分布式應(yīng)用開發(fā)過程中的底層細(xì)節(jié)
• ZooKeeper 對(duì)外暴露簡(jiǎn)單的 API，用于支持分布式應(yīng)用開發(fā)
• ZooKeeper 在提供上述功能的同時(shí)，其還是一個(gè) 高性能、高可用、高可靠的分布式集群

上面說這么多，總結(jié)一下，ZK 能解決分布式應(yīng)用開發(fā)的問題，ZK 能很好的解決問題。到這一步，疑問就更多了：

1. 分布式應(yīng)用開發(fā)，有哪些常見問題？ZK 是如何屏蔽這些底層細(xì)節(jié)的？
2. ZooKeeper 對(duì)外暴露了那些 API？這些 API 如何支持分布式應(yīng)用開發(fā)的？這些 API 還能簡(jiǎn)化嗎？API 的語義性怎么樣？
3. ZooKeeper 自身是一個(gè)高性能、高可用、高可靠的分布式集群，那有個(gè)簡(jiǎn)單的問題：
• 高性能是指什么？ZooKeeper 為了達(dá)到高性能，做了哪些工作？
• 高可用同上
• 高可靠同上

Note：本篇 wiki 就是為了解決上述第一個(gè)疑問的

# 為什么有 ZooKeeper

一個(gè)應(yīng)用程序，涉及多個(gè)進(jìn)程協(xié)作時(shí)，業(yè)務(wù)邏輯代碼中混雜有大量復(fù)雜的進(jìn)程協(xié)作邏輯。

上述多進(jìn)程協(xié)作邏輯，有 2 個(gè)特點(diǎn)：

• 處理復(fù)雜
• 處理邏輯可重用

因此，考慮將多進(jìn)程協(xié)作的共性問題拎出，作為基礎(chǔ)設(shè)施，讓 RD 更加專注業(yè)務(wù)邏輯開發(fā)，即：

ZooKeeper 就是上述多進(jìn)程協(xié)作基礎(chǔ)服務(wù)的一種。

# ZooKeeper 的特點(diǎn)

ZooKeeper 有幾個(gè)簡(jiǎn)單特點(diǎn)：

• ZooKeeper 的 API：從 文件系統(tǒng) API 得到的啟發(fā)，提供簡(jiǎn)單的 API
• ZooKeeper 運(yùn)行在專用服務(wù)器上，跟業(yè)務(wù)邏輯分離，保證了高容錯(cuò)性和可擴(kuò)展性

ZooKeeper 是存儲(chǔ)設(shè)施，但特別注意

• ZK上存儲(chǔ)的數(shù)據(jù)聚焦為：協(xié)作數(shù)據(jù)（元數(shù)據(jù)），而不是應(yīng)用數(shù)據(jù)，應(yīng)用數(shù)據(jù)有自己的存儲(chǔ)方案，例如 HDFS 等
• ZK 本質(zhì)上，可以看作一種特殊的 FS

特別說明：

應(yīng)用數(shù)據(jù)和元數(shù)據(jù)，由于使用場(chǎng)景不同，對(duì)一致性和持久性的要求有差異， 因此，架構(gòu)設(shè)計(jì)、數(shù)據(jù)治理過程中，應(yīng)將 2 類數(shù)據(jù)獨(dú)立看待、獨(dú)立存儲(chǔ)。

# ZooKeeper 的使命

ZK 要解決的核心問題：

ZK 目標(biāo)：簡(jiǎn)化分布式應(yīng)用開發(fā)中，多進(jìn)程協(xié)作問題。為分布式應(yīng)用，提供高效、可靠的分布式協(xié)調(diào)服務(wù)（基礎(chǔ)服務(wù)），例如：

• 統(tǒng)一的命名服務(wù)
• 分布式鎖
• 進(jìn)程崩潰檢測(cè)
• Leader 選舉
• 配置管理：配置變更時(shí)，及時(shí)下發(fā)到各個(gè) Client。

一個(gè)簡(jiǎn)單的問題：多進(jìn)程的協(xié)作是什么？尼瑪呀，有完沒完，啥問題你都有，面對(duì)這個(gè)掉咋天的腦殼，還是回答一下。

多進(jìn)程協(xié)作，整體分為 2 類：

1. 協(xié)作：多進(jìn)程需要一同處理某些事情，一些進(jìn)程采取行動(dòng)是的其他進(jìn)程能夠正常工作，例如：主從結(jié)構(gòu)，M 向 S 分配任務(wù)，S 才會(huì)執(zhí)行，否則 S 就保持空閑狀態(tài)
2. 競(jìng)爭(zhēng)：兩個(gè)進(jìn)程不能同時(shí)工作，一個(gè)進(jìn)程必須等待另個(gè)進(jìn)程執(zhí)行完畢，例如：主從結(jié)構(gòu)，M 節(jié)點(diǎn)失效后，很多 S 都想成為 M，這時(shí)，就需要互斥鎖，只有第一個(gè)獲得鎖的 S 成為 M

特別說明：

1. 不跨網(wǎng)絡(luò)協(xié)作：多進(jìn)程，可以在同一臺(tái)物理主機(jī)上，同步原語很方便(比如？管道、共享內(nèi)存、消息隊(duì)列、信號(hào)量)
2. 跨網(wǎng)絡(luò)協(xié)作：多進(jìn)程，分布在不同的物理主機(jī)上，ZK 關(guān)注這一類

跨網(wǎng)絡(luò)多進(jìn)程協(xié)作，進(jìn)程通信，基本思路有 2 個(gè)：

1. 消息機(jī)制：通過網(wǎng)絡(luò)，直接信息交換，多消息傳遞算法，實(shí)現(xiàn)同步原語
2. 共享存儲(chǔ)：利用外部共享存儲(chǔ)，實(shí)現(xiàn)多進(jìn)程協(xié)作，要求共享存儲(chǔ)提供有序訪問，ZK 采用這種方式

真實(shí)系統(tǒng)中，跨網(wǎng)絡(luò)通信，有幾個(gè)共性問題：

1. 消息延遲：由于網(wǎng)絡(luò)原因，后發(fā)送先到達(dá)
2. 處理器性能：由于系統(tǒng)調(diào)度原因，消息到達(dá)后，延遲處理
3. 時(shí)鐘偏移：不同物理主機(jī)，時(shí)鐘發(fā)生偏移

ZK 精心設(shè)計(jì)用于屏蔽上述 3 個(gè)共性問題，使得這些問題在應(yīng)用服務(wù)層面完全透明化。

# ZooKeeper 特性

ZooKeeper 解決的本質(zhì)問題

分布式系統(tǒng)的一致性問題：

1. 消息傳遞：延遲性，先發(fā)送的消息，不一定先到達(dá)；
2. 消息傳遞：丟失性，發(fā)送的消息，可能丟失；
3. 節(jié)點(diǎn)崩潰：分布式系統(tǒng)內(nèi)，任何一個(gè)節(jié)點(diǎn)都可能崩潰；

在這種情況下，如何保證數(shù)據(jù)的一致性？

1. 提案投票：基于投票策略，2PC
2. 選舉投票：基于投票策略，投出優(yōu)先級(jí)最高的節(jié)點(diǎn)（包含最新數(shù)據(jù)的節(jié)點(diǎn)）

Paxos 目標(biāo)：解決分布式一致性問題，提高分布式系統(tǒng)容錯(cuò)性的一致性算法。

Paxos 本質(zhì)：基于消息傳遞的高度容錯(cuò)的一致性算法

# ZooKeeper 定位

ZooKeeper 是：

1. 分布式協(xié)調(diào)服務(wù)
2. 高效、可靠
3. 方便應(yīng)用程序，聚焦業(yè)務(wù)邏輯開發(fā)，而不需要過多關(guān)注分布式進(jìn)程間協(xié)作細(xì)節(jié)

ZooKeeper 不直接暴露原語，而是，暴露一部分調(diào)用方法組成的 API，類似文件系統(tǒng)的 API，支持應(yīng)用程序?qū)崿F(xiàn)自己的原語。

# ZooKeeper 特性

ZooKeeper 可以保證如下分布式一致性特性：

• 順序一致性：同一個(gè) Client 發(fā)起的事務(wù)請(qǐng)求，嚴(yán)格按照發(fā)起順序執(zhí)行
• 原子性：事務(wù)請(qǐng)求，要么應(yīng)用到所有節(jié)點(diǎn)，要么一個(gè)節(jié)點(diǎn)都沒有應(yīng)用
• 單一視圖：Client 無論連接到哪個(gè)節(jié)點(diǎn)，看到的服務(wù)端數(shù)據(jù)都是一致的（Note：不準(zhǔn)確，其實(shí)是最終一致性）
• 可靠性：事務(wù)一旦執(zhí)行成功，狀態(tài)永久保留
• 實(shí)時(shí)性：事務(wù)一旦執(zhí)行成功，Client 并不能立即看到最新數(shù)據(jù)，但 ZooKeeper 保證最終一致性

# ZooKeeper 設(shè)計(jì)目標(biāo)

ZooKeeper 致力于提供高性能、高可用、順序一致性的分布式協(xié)調(diào)服務(wù)，保證數(shù)據(jù)最終一致性。

目標(biāo)一：高性能（簡(jiǎn)單的數(shù)據(jù)模型）

1. 采用樹形結(jié)構(gòu)組織數(shù)據(jù)節(jié)點(diǎn)；
2. 全量數(shù)據(jù)節(jié)點(diǎn)，都存儲(chǔ)在內(nèi)存中；
3. Follower 和 Observer 直接處理非事務(wù)請(qǐng)求；

目標(biāo)二：高可用（構(gòu)建集群）

1. 半數(shù)以上機(jī)器存活，服務(wù)就能正常運(yùn)行
2. 自動(dòng)進(jìn)行 Leader 選舉

目標(biāo)三：順序一致性（事務(wù)操作的順序）

1. 每個(gè)事務(wù)請(qǐng)求，都會(huì)轉(zhuǎn)發(fā)給 Leader 處理
2. 每個(gè)事務(wù)，會(huì)分配全局唯一的遞增id（zxid，64位：epoch + 自增 id）

目標(biāo)四：最終一致性

1. 通過提議投票方式，保證事務(wù)提交的可靠性
2. 提議投票方式，只能保證 Client 收到事務(wù)提交成功后，半數(shù)以上節(jié)點(diǎn)能夠看到最新數(shù)據(jù)

# ZooKeeper 出現(xiàn)之前

ZK 出現(xiàn)之前，分布式系統(tǒng)常用兩種方式，實(shí)現(xiàn)多進(jìn)程協(xié)作：

1. 分布式鎖管理器
2. 分布式數(shù)據(jù)庫

ZK 更專注于進(jìn)程協(xié)作，而不提供任何鎖接口和通用的存儲(chǔ)數(shù)據(jù)接口。（疑問：ZK 也可以提供啊，我們不使用就行了）

應(yīng)用服務(wù)器，常見的 2 種需求：

1. Master-Slave Leader 選舉：要求提供Master節(jié)點(diǎn)選舉功能
2. 進(jìn)程響應(yīng)跟蹤 崩潰檢測(cè)：要求提供進(jìn)程存活狀態(tài)的跟蹤
3. 分布式鎖：互斥排它鎖

ZK 為上述 2 種策略提供了基礎(chǔ) API。

ZooKeeper 不適用的場(chǎng)景：

海量數(shù)據(jù)存儲(chǔ)：ZK 本質(zhì)是特殊的 FS，但 ZK 用于存儲(chǔ)元數(shù)據(jù)，需要單獨(dú)存儲(chǔ)應(yīng)用數(shù)據(jù)。

# 術(shù)語介紹

# 參考資料

[1]ZooKeeper-Distributed Process Coordination: http://shop.oreilly.com/product/0636920028901.do

[2]從Paxos到Zookeeper分布式一致性原理與實(shí)踐: https://book.douban.com/subject/26292004

推薦閱讀
面試題：InnoDB 中一棵 B+ 樹能存多少行數(shù)據(jù)？【面試不翻車，翻車就跑路】
我畫了35張圖就是為了讓你深入 AQS
Map 集合怎么也有這么多坑？一不小心又踩了好幾個(gè)！