zookeeper學習

• zookeeper
• • 初識Zookeeper
  • • 1. 檔案系統
    • 2、 監聽通知機制
  • Zookeeper作用
• Zookeeper叢集模式
• • zookeeper的配置

zookeeper

初識Zookeeper

• 它是一個分布式服務架構，是Apache

  Hadoop的一個子項目，它主要是用來解決分布式應用中經常遇到的一些資料管理問題，如：統一命名服務、狀态同步服務、叢集管理、分布式應用配置項的管理等。

• 檔案系統+監聽通知機制

1. 檔案系統

Zookeeper維護一個類似檔案系統的資料結構：

每個子目錄項如 NameService 都被稱作為 znode(目錄節點)，和檔案系統一樣，我們能夠自由的增加、删除znode，在一個znode下增加、删除子znode，唯一的不同在于znode是可以存儲資料的。

有四種類型的znode：

• PERSISTENT-持久化目錄節點

用戶端與zookeeper斷開連接配接後，該節點依舊存在

• PERSISTENT_SEQUENTIAL-持久化順序編号目錄節點

用戶端與zookeeper斷開連接配接後，該節點依舊存在，隻是Zookeeper給該節點名稱進行順序編号

• EPHEMERAL-臨時目錄節點

用戶端與zookeeper斷開連接配接後，該節點被删除

• EPHEMERAL_SEQUENTIAL-臨時順序編号目錄節點

用戶端與zookeeper斷開連接配接後，該節點被删除，隻是Zookeeper給該節點名稱進行順序編号

2、 監聽通知機制

用戶端注冊監聽它關心的目錄節點，當目錄節點發生變化（資料改變、被删除、子目錄節點增加删除）時，zookeeper會通知用戶端。

就這麼簡單，下面我們看看Zookeeper能做點什麼呢？

Zookeeper作用

• zookeeper功能非常強大，可以實作諸如分布式應用配置管理、統一命名服務、狀态同步服務、叢集管理等功能，我們這裡拿比較簡單的分布式應用配置管理為例來說明。
• 假設我們的程式是分布式部署在多台機器上，如果我們要改變程式的配置檔案，需要逐台機器去修改，非常麻煩，現在把這些配置全部放到zookeeper上去，儲存在 zookeeper 的某個目錄節點中，然後所有相關應用程式對這個目錄節點進行監聽，一旦配置資訊發生變化，每個應用程式就會收到 zookeeper 的通知，然後從 zookeeper 擷取新的配置資訊應用到系統中。

Zookeeper叢集模式

zookeeper的配置

zoo_sample.cfg

配置說明

• tickTime：這個時間是作為 Zookeeper 伺服器之間或用戶端與伺服器之間維持心跳的時間間隔，也就是每個 tickTime 時間就會發送一個心跳。
• initLimit：這個配置項是用來配置 Zookeeper 接受用戶端（這裡所說的用戶端不是使用者連接配接 Zookeeper 伺服器的用戶端，而是 Zookeeper 伺服器叢集中連接配接到 Leader 的 Follower 伺服器）初始化連接配接時最長能忍受多少個心跳時間間隔數。當已經超過 10個心跳的時間（也就是 tickTime）長度後 Zookeeper 伺服器還沒有收到用戶端的傳回資訊，那麼表明這個用戶端連接配接失敗。總的時間長度就是 10*2000=20 秒

• syncLimit：這個配置項辨別 Leader 與 Follower 之間發送消息，請求和應答時間長度，最長不能超過多少個 tickTime 的時間長度，總的時間長度就是 5*2000=10秒

  dataDir：顧名思義就是 Zookeeper 儲存資料的目錄，預設情況下，Zookeeper 将寫資料的日志檔案也儲存在這個目錄裡。

• clientPort：這個端口就是用戶端連接配接 Zookeeper 伺服器的端口，Zookeeper 會監聽這個端口，接受用戶端的通路請求。
• server.n=ip : port : port2：其中 n 是一個數字，表示這個是第幾号伺服器；ip 是這個伺服器的 ip 位址；port 表示的是這個伺服器與叢集中的 Leader 伺服器交換資訊的端口；port2 表示的是萬一叢集中的 Leader 伺服器挂了，需要一個端口來重新進行選舉，選出一個新的 Leader，而這個端口就是用來執行選舉時伺服器互相通信的端口。如果是僞叢集的配置方式，由于 B 都是一樣，是以不同的 Zookeeper 執行個體通信端口号不能一樣，是以要給它們配置設定不同的端口号。

分布式消息服務RabbitMQ，Dubbo，kafka 、hbase 到hadoop等分布式大資料處理都會用到Zookeeper，是以在此将Zookeeper作為基礎來講解

zookeeper主要解決：統一命名服務、狀态同步服務、叢集管理、分布式應用配置項的管理

Zookeeper 的核心是廣播，這個機制保證了各個Server之間的同步。實作這個機制的協定叫做Zab協定。

　　Zab協定有兩種模式，它們分别是恢複模式（選主）和廣播 模式（同步）。當服務啟動或者在上司者崩潰後，Zab就進入了恢複模式，當上司者被選舉出來，且大多數Server完成了和leader的狀态同步以後， 恢複模式就結束了。

　　狀态同步保證了leader和Server具有相同的系統狀态。為了保證事務的順序一緻性，zookeeper采用了遞增的事務id号 （zxid）來辨別事務。

　　所有的提議（proposal）都在被提出的時候加上了zxid。實作中zxid是一個64位的數字，它高32位是epoch用 來辨別leader關系是否改變，每次一個leader被選出來，它都會有一個新的epoch，辨別目前屬于那個leader的統治時期。低32位用于遞增計數。

　　每個Server在工作過程中有三種狀态：

　　LOOKING：目前Server不知道leader是誰，正在搜尋。

　　LEADING：目前Server即為選舉出來的leader。

　　FOLLOWING：leader已經選舉出來，目前Server與之同步。

ZooKeeper的安裝模式分為三種，分别為：單機模式、叢集模式和叢集僞分布模式

1. 僞叢集模式

   所謂的僞叢集，就是同一台機器的zookeeper啟動3個不同端口号的程序

tickTime=2000 
initLimit=5 
syncLimit=2 
dataDir=/usr/local/zookeeper/data
dataLogDir=/usr/local/zookeeper/log
clientPort=2180
server.0=127.0.0.1:2888:3888
server.1=127.0.0.1:2889:3889 
server.2=127.0.0.1:2890:3890