大數據的「動物管理員」 ZooKeeper

• 2019 年 10 月 6 日
• 筆記

Hadoop的框架裏面經常有聽到PIG（豬）、HIVE（小密蜂）、Hadoop（大象）……，就像是動物園的小動物，這些小動物的管理者就是ZooKeeper。玩笑講完了，我們還是回到正題。ZooKeeper的誕生主要是解決是集群的管理節點高可用。接下來，我們來看一看案例。

一、ZooKeeper的誕生歷程

1、傳統單機的環境，如Java程序調用Mysql數據源的IP、密碼一般是寫在一個配置文件中。

2、但數據源的IP地址會變化，因此我們將配置文件拿出來，作為一個共享文件進行集中管理。

3、配置節點將配置信息集中管理後，如果配置信息發生了變化，必須及時通知使用該信息的組件。因此增加了監聽的功能。

4、配置節點目前為單節點，存在故障隱患。因此將配置節點做成多個，之間保持數據的同步。但主用配置節點（具有寫入權限的節點）只有一個，其它從配置節點收到寫入命令後必須將命令傳送給主用配置。

二、ZooKeeper必須在配置節點和程序節點（組件節點）同時安裝

ZooKeeper組件節點可以同時配置多個服務源，當正在使用的服務源故障中斷後，可以自動與其它服務源進行連接，以保證ZK配置節點的高可用。

三、ZooKeeper的數據內容較簡單，小於1MB

ZooKeeper主要用於保存配置文件，一般是文本文件，因此數據量很小。在ZooKeeper中採用Znode作為數據管理的最小單元，且小於1MB。如下圖，方框部分就是一個Znode。

如app1就是一個Znode，Znode中存儲了server_ip的很多配置。

四、案例ZooKeeper在Mysql主備用庫選擇中的應用

常規，我們實現Mysql的主備用庫的高可用，一般是採用RoseHA、KeepAlived軟件等，實現方法是採用VIP浮動IP的方式。

如果我們用ZooKeeper來實現，原理則會發生變化。

我們在數據庫服務器上部署ZooKeeper的agent，該agent實例定時ping mysql實例，當mysql實例故障時，agent將在ZooKeeper配置節點刪除該Znode臨時節點。當某個Java程序連接數據庫源時，將通過ZooKeeper獲取當時能使用的mysql數據信息。通過以上方式實現了Mysql主備用庫的選擇。

看到這裡，大家應有所感悟，採用ZooKeeper與RoseHA進行Mysql的主備庫切換有很大的區別。而市面上一般採用RoseHA進行主備切庫，原因是簡單，Java程序基本不需要進行改造，甚至一般是將配置直接固定寫進了程序中或本地的INI文件中。而採用ZooKeeper的方式則必須重新編寫獲取配置的類，必實現ZooKeeper的接口。通過Java編程的方式，不僅是能實現主備切換，甚至能實現主主權重負載均衡。

附Java實現ZooKeeper接口的圖例