Zookeeper集羣搭建和簡介(二)

Zookeeper集羣搭建和簡介(二)

本文主要涉及一下知識.
1.linux虛擬機安裝和linux基本設置
2.linux間免密登陸
3.linux搭建zookeeper環境
4.zookeeper的介紹

書接上回

3.linux搭建zookeeper環境

在搭建zookeeper以前.咱們先作些準備工做
修改linux之間的名稱和配置hosts文件. 當咱們遠程鏈接時,就不用輸入密碼了.
在linux1中,修改/etc/hosts文件
192.168.1.1(linux1的ip) znode1
192.168.1.2(linux2的ip) znode2
192.168.1.3(linux3的ip) znode3
若是咱們想連接znode2,就能夠ssh znode2 就能夠.不用再輸入ip啦.

第一步:
把zookeeper的壓縮包上傳到/export/software/目錄下.
解壓 tar zxvf zookeeper.jar.gz /export/server/(解壓文件到/export/server/目錄下)
進入到conf目錄下.看到zoo_sample.cfg文件 修更名稱
mv zoo_sample.cfg zoo_sample.cfg
修改zoo.cfg文件
執行命令 : vim z00.cfg
找到dataDir,後面修改爲這個路徑 . zookeeper的日誌文件就會輸出到這個目錄下.
dataDir=/export/data/zookeeper
光標移動到最後,添加如些內容 . znode1-znode3是linux的名稱 2888,3888是通信端口號和選舉端口號.保存退出
server.1=znode1:2888:3888
server.2=znode2:2888:3888
server.3=znode3:2888:3888

第二步:
進入到/export/data目錄下.建立zookeeper目錄,進入到目錄中
執行 echo 1 > myid . 這個1就是上面server後面的數字,上面寫幾,這就寫幾,要對應上.

第三步:
修改環境變量. 執行 vim /etc/profile
在最後添加
export ZOOKEEPER_HOME=/export/server/zookeeper #(zookeeper安裝目錄路徑)
export PATH=$PATH:$ZOOKEEPER_HOME/bin
保存退出,刷新下文件 source /etc/profile

第四步:
把/export/server/zookeeper 文件拷貝到znode2和znode3一份
scp -r /export/server/zookeeper znode2:/export/server
scp -r /export/server/zookeeper znode3:/export/server
再把/etc/profile文件拷貝一下,這樣就不用再添加環境變量了
scp /etc/profile znode2:/etc/
scp /etc/profile znode3:/etc/
注意,在znode2和znode3裏要刷新文件哦.要不環境變量不生效

第五步:
進入到znode2 /export/data/zookeeper目錄下.
執行 echo 2 > myid
進入到znode3 /export/data/zookeeper目錄下.
執行 echo 3 > myid

到如今,zookeeper安裝基本完成了.
啓動zookeeper.znode1,znode2,znode3都要啓動起來
zkServer.sh start
查看zookeeper狀態,zkServer.sh status

Zookeeper介紹

一 zookeeper認識:

1.Zookeeper是一個分佈式協調服務的開源框架。主要用來解決分佈式集羣中應用系統的一致性問題，

2.ZooKeeper本質上是一個分佈式的小文件存儲系統。提供基於相似於文件系統的目錄樹方式的數據存儲，而且能夠對樹中的節點進行有效管理。從而用來維護和監控你存儲的數據的狀態變化。經過監控這些數據狀態的變化，從而能夠達到基於數據的集羣管理。諸如：統一命名服務、分佈式配置管理、分佈式消息隊列、分佈式鎖、分佈式協調等功能

二 zookeeper特性

1. 全局數據一致：集羣中每一個服務器保存一份相同的數據副本，client不管鏈接到哪一個服務器，展現的數據都是一致的，這是最重要的特徵
2. 可靠性：若是消息被其中一臺服務器接受，那麼將被全部的服務器接受
3. 順序性：包括全局有序和偏序兩種：全局有序是指若是在一臺服務器上消息a在消息b前發佈，則在全部Server上消息a都將在消息b前被髮布；偏序是指若是一個消息b在消息a後被同一個發送者發佈，a必將排在b前面。
4. 數據更新原子性：一次數據更新要麼成功（半數以上節點成功），要麼失敗，不存在中間狀態
5. 實時性：Zookeeper保證客戶端將在一個時間間隔範圍內得到服務器的更新信息，或者服務器失效的信息。

   三 zookeeper集羣角色

6. Leader : Zookeeper集羣工做的核心.事務請求（寫操做）的惟一調度和處理者，保證集羣事務處理的順序性； 集羣內部各個服務器的調度者。
7. Follower : 處理客戶端非事務（讀操做）請求，轉發事務請求給Leader； 參與集羣Leader選舉投票
8. Observer : 觀察者角色. 觀察Zookeeper集羣的最新狀態變化並將這些狀態同步過來，其對於非事務請求能夠進行獨立處理，對於事務請求，則會轉發給Leader服務器進行處理.不會參與任何形式的投票只提供非事務服務，一般用於在不影響集羣事務處理能力的前提下提高集羣的非事務處理能力

四 zookeeper shell操做

1. 連接zookeeper zkCli.sh -server ip. 運做zk shell,會提示用法.
2. 建立節點
   create [-s] [-e] path data acl
   -s或-e分別指定節點特性，順序或臨時節點，若不指定，則表示持久節點；acl用來進行權限控制
   例如 : create -s /Test 2018 -s表示節點是序列化節點,/Test表示在根目錄下建立Test節點, 2018是節點存儲的值

   
   建立臨時節點
   create -e /Test01 2018
   建立永久節點
   create /Test02 2019

1. 節點讀取
   ls 命令能夠列出Zookeeper指定節點下的全部子節點，只能查看指定節點下的第一級的全部子節點
   get 命令能夠獲取Zookeeper指定節點的數據內容和屬性信息。
   查看zookeeper根節點目錄 : ls /
   查看節點詳細信息: get /Test02
2. 更新節點
   set /Test02 2020
3. 刪除節點 . 若刪除節點存在子節點，那麼沒法刪除該節點，必須先刪除子節點，再刪除父節點
   delete /Test02
   遞歸刪除節點 rmr path
4. quota 對節點添加限制
   setquota -n|-b val path
   n:表示子節點的最大個數 b:表示數據值的最大長度 val:子節點最大個數或數據值的最大長度 path:節點路徑
5. listquota 查看指定節點限制 listquota path
   delquota [-n|-b] path 刪除quota
6. history 列出歷史命令
   redo : 該命令能夠從新執行指定命令編號的歷史命令,命令編號能夠經過history查看

三 zookeeper數據模型

1. ZooKeeper的數據模型，在結構上和標準文件系統的很是類似，擁有一個層次的命名空間，都是採用樹形層次結構，ZooKeeper樹中的每一個節點被稱爲—Znode。和文件系統的目錄樹同樣，ZooKeeper樹中的每一個節點能夠擁有子節點。
2. Znode兼具文件和目錄兩種特色 既像文件同樣維護着數據、元信息、ACL、時間戳等數據結構，又像目錄同樣能夠做爲路徑標識的一部分，並能夠具備子Znode。用戶對Znode具備增、刪、改、查等操做（權限容許的狀況下）。
3. Znode具備原子性操做 讀操做將獲取與節點相關的全部數據，寫操做也將替換掉節點的全部數據。另外，每個節點都擁有本身的ACL(訪問控制列表)，這個列表規定了用戶的權限，即限定了特定用戶對目標節點能夠執行的操做
4. Znode存儲數據大小有限制. Znode存儲的配置文件信息、狀態信息、聚集位置等等都很小,一般以KB爲大小單位,ZooKeeper的服務器和客戶端都被設計爲嚴格檢查並限制每一個Znode的數據大小最多1M.
5. Znode經過路徑引用,路徑必須是絕對的,所以他們必須由斜槓字符來開頭

四 zookeeper數據結構

1. 每個節點均可以建立子節點,每一個子節點還能夠保存信息,全部節點造成樹形結構樹.每一個節點叫znode,每一個znode有三部分組成
   stat：此爲狀態信息, 描述該Znode的版本, 權限等信息
   data：與該Znode關聯的數據
   children：該Znode下的子節點

五 zookeeper 節點類型

1. Znode有兩種，分別爲臨時節點和永久節點
2. 節點的類型在建立時即被肯定，而且不能改變。
3. 臨時節點：該節點的生命週期依賴於建立它們的會話。一旦會話結束，臨時節點將被自動刪除，固然能夠也能夠手動刪除。臨時節點不容許擁有子節點。
4. 永久節點：該節點的生命週期不依賴於會話，而且只有在客戶端顯示執行刪除操做的時候，他們才能被刪除
5. Znode還有一個序列化的特性，若是建立的時候指定的話，該Znode的名字後面會自動追加一個不斷增長的序列號。序列號對於此節點的父節點來講是惟一的，這樣便會記錄每一個子節點建立的前後順序。它的格式爲「%10d」(10位數字，沒有數值的數位用0補充，例如「0000000001」)。
6. 這樣便會存在四種類型的Znode節點，分別對應：
   PERSISTENT：永久節點
   EPHEMERAL：臨時節點
   PERSISTENT_SEQUENTIAL：永久節點、序列化
   EPHEMERAL_SEQUENTIAL：臨時節點、序列化

六 zookeeper 節點屬性
每一個znode都包含了一系列的屬性，經過命令get，能夠得到節點的屬性

1. dataVersion：數據版本號，每次對節點進行set操做，dataVersion的值都會增長1（即便設置的是相同的數據），可有效避免了數據更新時出現的前後順序問題。
2. cversion ：子節點的版本號。當znode的子節點有變化時，cversion 的值就會增長1。
3. aclVersion ：ACL的版本號。
4. cZxid ：Znode建立的事務id。
5. mZxid ：Znode被修改的事務id，即每次對znode的修改都會更新mZxid。 對於zk來講，每次的變化都會產生一個惟一的事務id，zxid（ZooKeeper Transaction Id）。經過zxid，能夠肯定更新操做的前後順序。
6. ctime：節點建立時的時間戳.
7. mtime：節點最新一次更新發生時的時間戳.
8. ephemeralOwner:若是該節點爲臨時節點, ephemeralOwner值表示與該節點綁定的session id. 若是不是, ephemeralOwner值爲0.

七 ZooKeeper Watcher
概念: ZooKeeper提供了分佈式數據發佈/訂閱功能，一個典型的發佈/訂閱模型系統定義了一種一對多的 訂閱關係，能讓多個訂閱者同時監聽某一個主題對象，當這個主題對象自身狀態變化時，會通知全部訂閱者，使他們可以作出相應的處
ZooKeeper中，引入了Watcher機制來實現這種分佈式的通知功能。ZooKeeper容許客戶端向服務端註冊一個Watcher監聽，當服務端的一些事件觸發了這個Watcher，那麼就會向指定客戶端發送一個事件通知來實現分佈式的通知功能。觸發事件種類不少，如：節點建立，節點刪除，節點改變，子節點改變等.
總的來講能夠歸納Watcher爲如下三個過程：客戶端向服務端註冊Watcher、服務端事件發生觸發Watcher、客戶端回調Watcher獲得觸發事件狀況

1. Watch機制特色
   一次性觸發 : 事件發生觸發監聽，一個watcher event就會被髮送到設置監聽的客戶端，這種效果是一次性的，後續再次發生一樣的事件，不會再次觸發
   事件封裝 : ZooKeeper使用WatchedEvent對象來封裝服務端事件並傳遞。 WatchedEvent包含了每個事件的三個基本屬性： 通知狀態（keeperState），事件類型（EventType）和節點路徑（path）
   event異步發送 : atcher的通知事件從服務端發送到客戶端是異步的。
   先註冊再觸發 : Zookeeper中的watch機制，必須客戶端先去服務端註冊監聽，這樣事件發送纔會觸發監聽，通知給客戶端。
2. 通知狀態和事件類型. 同一個事件類型在不一樣的通知狀態中表明的含義有所不一樣.看圖
   ![圖片上傳中...]

3. Shell 客戶端設置watcher

1. 設置節點數據變更監聽
   
2. 改節點數據
   ![圖片上傳中...]
3. 此時設置監聽的節點收到通知：
   ![圖片上傳中...]

八 ZooKeeper選舉機制

1. zookeeper默認的算法是FastLeaderElection，採用投票數大於半數則勝出的邏輯。
2. 服務器ID : 好比有三臺服務器，編號分別是1,2,3。 編號越大在選擇算法中的權重越大。

3. 選舉狀態 :

   LOOKING，競選狀態
           FOLLOWING，隨從狀態,同步leader狀態，參與投票 
           OBSERVING，觀察狀態,同步leader狀態，不參與投票 
           LEADING，領導者狀態

4. 數據ID : 服務器中存放的最新數據version。 值越大說明數據越新，在選舉算法中數據越新權重越大。
5. 邏輯時鐘 : 也叫投票的次數，同一輪投票過程當中的邏輯時鐘值是相同的。每投完一次票這個數據就會增長，而後與接收到的其它服務器返回的投票信息中的數值相比，根據不一樣的值作出不一樣的判斷。

全新集羣選舉
假設目前有5臺服務器，每臺服務器均沒有數據，它們的編號分別是1,2,3,4,5,按編號依次啓動，它們的選擇舉過程以下：

1. 服務器1啓動，給本身投票，而後發投票信息，因爲其它機器尚未啓動因此它收不到反饋信息，服務器1的狀態一直屬於Looking。
2. 服務器2啓動，給本身投票，同時與以前啓動的服務器1交換結果，因爲服務器2的編號大因此服務器2勝出，但此時投票數沒有大於半數，因此兩個服務器的狀態依然是LOOKING。
3. 服務器3啓動，給本身投票，同時與以前啓動的服務器1,2交換信息，因爲服務器3的編號最大因此服務器3勝出，此時投票數正好大於半數，因此服務器3成爲領導者，服務器1,2成爲小弟。
4. 服務器4啓動，給本身投票，同時與以前啓動的服務器1,2,3交換信息，儘管服務器4的編號大，但以前服務器3已經勝出，因此服務器4只能成爲小弟。
5. 服務器5啓動，後面的邏輯同服務器4成爲小弟。

非全新集羣選舉
對於運行正常的zookeeper集羣，中途有機器down掉，須要從新選舉時，選舉過程就須要加入數據ID、服務器ID和邏輯時鐘。

1. 數據ID：數據新的version就大，數據每次更新都會更新version。
2. 服務器ID：就是咱們配置的myid中的值，每一個機器一個。
3. 邏輯時鐘：這個值從0開始遞增,每次選舉對應一個值。 若是在同一次選舉中,這個值是一致的。這樣選舉的標準就變成： 一、邏輯時鐘小的選舉結果被忽略，從新投票； 二、統一邏輯時鐘後，數據id大的勝出； 三、數據id相同的狀況下，服務器id大的勝出；