Zookeeper叢集搭建和簡介(二)

可好了發表於2018-03-05

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是節點儲存的值

      clipboard.png
      建立臨時節點
      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. 設定節點資料變動監聽
      clipboard.png
    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開始遞增,每次選舉對應一個值。 如果在同一次選舉中,這個值是一致的。
      這樣選舉的標準就變成：
      1、邏輯時鐘小的選舉結果被忽略，重新投票；
      2、統一邏輯時鐘後，資料id大的勝出；
      3、資料id相同的情況下，伺服器id大的勝出；

    相關文章