Zookeeper 概述（1）

Zookeeper 概述（1）

前言

關係數據庫的ACID

• Atomicity原子性：      一個事務中全部操做都必須所有完成，要麼所有不完成；
• Consistency一致性：  在事務開始或結束時，數據庫應該在一致狀態；
• Isolation隔離層：       事務間不影響;
• Durability持久性:        事務一旦完成必須持久化，不能返回。

SOA

面向服務的體系結構，將應用程序的不一樣功能單元（服務）分佈在網絡計算機上，並經過定義好的接口（協議）進行網絡通信。

CPA理論 

• Consistency 一致性:    
       分佈式數據視圖必須一致
• Availability 可用性:  
       有限時間內必返回明確響應。正常的響應結果可以明確反映請求的處理結果
• Partition tolerance 分區容錯性:
       分佈式系統在遇到任何網絡分區故障仍能保證對外提供知足一致性和可用性的服務，除非整個網絡環境都發生故障。

CA	放棄分區容錯性，增強一致性和可用性，其實就是傳統的單機數據庫的選擇
AP	放棄強一致性，追求分區容錯性和可用性，這是不少分佈式系統設計時的選擇，例如不少NoSQL系統就是如此
CP	放棄可用性，追求一致性和分區容錯性，基本不會選擇，網絡問題會直接讓整個系統不可用

定理：任何分佈式系統只可同時知足二點，無法三者兼顧。

BASE理論

• Basically Available 基本可用：
         當異常時，保證主要功能不掛，或者響應稍微延時些；
• Soft state 軟狀態：  
         可存在中間狀態，不影響系統的總體可用性，即容許系統在不一樣節點的數據副本之間的數據同步存在延時；
• Eventually consistent  最終一致性：
         弱一致性，保證最終一致而不是實時一致

 tip: 基於上述理論，如何作好HA（高可用集羣），分佈式系統間的信息同步，容災？

Zookeeper

       高性能分佈式應用功能單元服務協調服務，分佈式數據一致性解決方案。 主要用途： 統一命名服務、分佈式鎖、狀態同步服務、集羣管理、 分佈式應用配置管理等。

特性

• 最終一致性： 不管鏈接在zookeeper集羣中的哪一個服務器，返回的視圖都是一致的；
• 順序性：  消息的傳遞保證FIFIO，且在每一臺服務器上的順序都是同樣的；
• 原子性：  更新只能所有服務都成功或者失敗，沒有中間狀態；
• 可靠傳輸： 消息被一臺服務器接受，則確定能被全部服務器接受；
• 實時性：   在必定時間內能獲取服務端返回數據；
• 慢的或者失效的客戶端不干預快的客戶端的請求，使得每一個客戶端能有效等待。

存儲結構

存儲相似於文件目錄格式的樹型結構Znode，但存儲在內存中。每一個節點下保存stat對象(節點狀態信息)。

Stat

用於保證分佈式數據的原子性操做，表示對數據節點數據內容的變動次數，強調的是變動次數，所以就算數值沒有發生變化，version的值也會遞增。 Zookeeper的版本做用就是相似於樂觀鎖機制，用於實現樂觀鎖機制的「寫入校驗」。

• czxid：建立節點的事務的zxid
• mzxid： 最後修改時的zxid
• ctime：以距離時間原點(epoch)的毫秒數表示的znode建立時間
• mtime：以距離時間原點(epoch)的毫秒數表示的znode最近修改時間
• pzxid: 子節點列表最後一次被修改的事務ID， 只有子節點列表變動了纔會更新pzxid，子節點內容變動不影響。
• cversion：           znode子節點列表變動版本
• dataVersion：     znode數據的修改版本
• aclVersion：        znode的ACL修改版本
• ephemeralOwner：  若znode爲臨時節點，則指示節點全部者的會話ID；不然爲零。
• dataLength：       znode數據長度。
• numChildren：     znode子節點個數。

znode類型

• 持久節點： 一般用來保存應用的持久化數據。 可用delete和rmr來刪除。
• 臨時節點： 不容許有子節點。除了客戶端主動刪除該節點時消失外，客戶端會話失效會自動被清除掉，所以經常使用來檢測會話的有效性。
• 有序節點：  建立時，一個會自動遞增的序號會加到路徑以後，
  eg:  客戶端建立一個有序znode並指定路徑爲/tasks/task，則第一個建立的節點是/tasks/task-0000000001，該節點消亡後再建立這樣的節點會產生/tasks/task-0000000002，以此類推。有序znode提供了建立具備惟一命名的znode的方式。

經常使用命令

• create [-s] [-e] path data [acl]   
          -s或-e分別指定節點特性，順序或臨時節點，默認持久節點；acl用來進行權限控制
• delete path [version]  
           當有子節點時不能刪除
• rmr path
          遞歸刪除節點
• set path data [version]
• getAcl   / setAcl  
• connect host:port
  

權限

• CREATE(c):   建立權限，能夠在在當前node下建立child node;
• DELETE(d):   刪除權限，能夠刪除當前的node;
• READ(r):      讀權限，能夠獲取當前node的數據，能夠list當前node全部的child nodes;
• WRITE(w):   寫權限，能夠向當前node寫數據;
• ADMIN(a):  管理權限，能夠設置當前node的permission;

ACL

• world
     默認方式， world:anyone  都能訪問 ;
     
• auth
     表明已經認證經過的用戶;
• digest
      用戶名和密碼進行認證. 對應爲username:BASE64(SHA1(password));
• ip
     客戶機的IP地址
  
   

1. 增長一個認證用戶: addauth digest 用戶名:密碼明文
2. 設置權限:   
   1. setAcl /path digest:用戶名:密碼密文:權限
   2. setAcl /path auth:用戶名:密碼明文:權限 <測試沒發現怎麼使用>

缺陷：ACL 並沒有遞歸機制，任何一個 znode 建立後，都須要單獨設置 ACL，沒法繼承父節點的 ACL設置。

SuperDigest 

修改 zkServer.sh <zkServer.cmd> 加入 super 權限後， 重啓使用 super:super 進行認證：

-Dzookeeper.DigestAuthenticationProvider.superDigest=super:gG7s8t3oDEtIqF6DM9LlI/R+9Ss=

Zookeeper quota

支持節點個數（ znode ）和空間大小（字節數）。

• -n : 表示設置 節點個數的限制，包括 本身自己。
           這裏表示 /test 這個 path 下的 znode count 個數限制爲 5 ；
• -b ： 表示設置 znode 數據的字節大小限制. 包括 本身自己。

看 zookeeper 的日誌，發現有 Quota exceeded 的日誌， zookeeper 的 Quota機制是比較溫和的，即便超限了，只是在日誌中報告一下，並不會限制 Client 的行爲， Client 能夠繼續操做 znode 。在實際項目中， Client 能夠查看 /zookeeper/quota 目錄下的數據來肯定是否超出 quota 限制，由此來作一些告警

限制

ZK單個node節點默認的最大數據量上限是1M 大於1M時拋異常：Unable to read additional data from server sessionid 0x15dd29d55b00004, likely server has closed socket, closing socket connection and attempting reconnect， 可是能夠修改zkServer.sh啓動腳原本調整這個閥值；