Zookeeper學習筆記(下)

這是ZK學習筆記的下篇, 主要但願能夠分享一些 ZK 的應用以及其應用原理
我本人的學習告一段落, 不過還遺留了一些ZK相關的任務開發和性能測試的任務, 留待之後完成以後再經過其餘文章來進行分享了

---

ZK應用場景:

1. 一個服務多臺機器, 快速修改配置
2. 服務的消費者如何動態知道服務有多少個提供者
3. 生產系統部署多少個業務系統以及每一個業務系統提供多少接口

ZK案例-配置管理:

服務端:
    每次啓動, 會將提供的request都註冊到 ZK 中

客戶端:
    啓動時讀取 ZK 中全部的 service 提供者,而且組裝出可用的 service
    
優化:
    服務器啓動註冊本地IP,使用臨時節點的方式, 一旦鏈接失效, 客戶端能夠收到節點消失的通知

ZK案例-分佈式鎖

排他鎖:只能一個線程獲取.其餘線程須要等待
    ZK實現:
        得到鎖:構建目錄, 葉子節點建立成功則認爲獲取鎖

    排他鎖實現的核心思想:
        經過只有一個線程能夠建立一個一樣的葉子節點進行實現
        線程能夠成功建立葉子節點即認爲獲取鎖成功,能夠執行業務代碼
        若線程沒法成功建立葉子節點,則認爲獲取鎖失敗, 須要進入等待, 多個其餘線程建立失敗則多個線程進入等待
        線程執行完業務代碼會刪除葉子節點,其餘線程獲取到刪除通知,會釋放線程,再次嘗試獲取鎖

共享鎖:能夠多個讀操做同時獲取鎖進行處理,一旦出現寫鎖,其餘全部操做須要等待寫入完成以後從新獲取鎖
    ZK實現:
        讀時能夠容許其餘線程進行讀, 寫是其餘線程不可進行其餘操做
    共享鎖實現的核心思想: 
        每一個節點都向ZK寫入節點信息(Seq節點)
        經過排名比較是否本身在第一個來進行判斷是否獲取到鎖
        非第一個,則在自己和前面都是讀鎖的狀況下才能夠繼續,不然獲取失敗,進入等待
    
性能如何(待測試...)?
    在接二連三有請求到達時,最大TPS有多少, 區分同時有 10個線程競爭和同時有 100個線程競爭的時候

ZK的使用和運維

ZK 配置說明:

1. 基於log4j的日誌配置:

   運行命令行增長: ZOO_LOG_DIR

2. zoo.conf

   dataLogDir : 事務日誌文件存儲目錄, 高併發下, 和 dataDir 配置在不一樣磁盤上, 提升 IO
    snapCount : 兩次事務日誌的記錄數量
    preAllocSize : 默認64MB, 與 snapCount相關, 
    minSessionTimeout , maxSessionTimeout : 2倍和20倍 ticktime
    maxClientCnxns: socket層限制客戶端和單臺服務器的併發鏈接數, 只控制單臺機器,不能控制總鏈接
    Jute.maxbuffer:配置單個節點最大數據大小, 默認10MB, 須要客戶端和服務端同時配置生效
    Autopurge.snapRetainCount: 自動清理快照和事務日誌須要保留文件數
    Autopurge.purgeInterval:清理的週期
    fsync.warningthresholdms:事務日誌刷新到磁盤的閾值, 默認1000ms , fsync超過此時間會報警
    forceSync : 日誌提交時是否強制刷磁盤, 默認true, 能夠false

3. 四字命令:

   經過 telnet ip port 進入 , 打印命令

   經過 nc 進入: echo 命令 |nc localhost port

   conf : 查看配置
    cons : 輸出當前客戶端全部鏈接的詳細信息
        queued : 待處理的請求
        recved : 接受到的
        sent : 已處理的
        sid
        lop : 最近操做
   
    crst : 重置客戶端鏈接統計信息
    dump : 當前集羣全部會話信息, 包括id, 臨時節點, 會話超時時間(leader節點)
    envi : 運行時當前環境信息
    ruok : 輸出zk服務器運行是否正常
    stat : 服務端運行情況, zk服務版本, 延遲, 節點信息等
    srvr : 相似 stat , 無會話信息
    srst : 重置服務端統計信息
    wchs : 輸出服務器管理的 watcher 的概要信息, zk構造器建立的 watcher 不會被計入統計中
    wchc : 管理的 watcher 的詳細信息, 以 session 爲視角
    wchp : 以node爲視角
    mntr : 比 stat 更詳細, 包括請求的延遲狀況, 服務區內存大小, 集羣同步等...

4. 性能優化:

   JVM優化
    IO優化
    加大 linux系統的文件句柄數和用戶線程數, linux 經過 ulimit 查看配置
    業務併發高: 客戶建立多個客戶端鏈接, 用於不一樣的業務
    減小資源消耗, 好比watcher的數量
    提升帶寬

5. 擴容:

   停機:直接增長節點
    不停機:
        新增節點: id須要比集羣更大
        新節點啓動, 加入集羣且同步數據
        mntr查看新的節點數據成功同步後再執行
        依次id從小到大,關閉zk實例,修改配置,啓動實例

6. 監控:

   zookeeper的事務日誌
        磁盤IO
        日誌清理:建議按期清理事務日誌和快照文件
    鏈接數,避免過多
    watchers 數量
    ZK通知延時是否過大

ZK運維繫統

Taokeeper:

功能:
    CPU
    ZK日誌目錄磁盤空間監控
    單機鏈接數
    單機Watcher數量
    節點健康狀態
    少許統計報表
不足:
    目錄查看
    網絡流量
    磁盤IO監控
安裝:
    源碼安裝:
    包安裝:
        初始化腳本:4張表sql


安裝步驟:
    1. 修改機器,增長host
        zk1node
        zk2node
        zk3node

我的意見: 沒法達到生產使用的標準, 建議自行開發相應的監控系統, 或者運維人員經過四字命令手工監控

---

==================本身總結===============

1. 一些資料

   Zookeeper 學習

   http://www.open-open.com/lib/view/open1415453633887.html

   zookeeper簡介

   http://www.open-open.com/lib/view/open1415453633887.html

   ZK的應用,能夠再細化:

   http://blog.csdn.net/xinguan1267/article/details/38422149
    http://cailin.iteye.com/blog/2014486/ (原理)

2. 心得

   Zookeeper 的使用場景

   Zookeeper徹底能夠解決咱們的問題，分佈式計算中的協調員，觀察者，分佈式鎖  均可以做爲zookeeper的關鍵詞
    在系統中利用Zookeeper來處理事件通知,隊列,優先隊列,鎖,共享鎖等功能，利用這些特點在分佈式計算中發揮重要的做用。
   
    Zookeeper 能夠作配置的動態更新（通知機制）
   
   
    配置管理 & 集羣服務管理
        全部節點登陸後, 自行獲取配置(公共的,特有的(經過serviceId標示))
        通常節點啓動後負責在 某 path 中寫入自身的service等標誌, 若是已有則再也不啓動
        管理節點啓動後負責獲取全部其餘節點寫入的一些數據, 來肯定有多少其餘節點正在工做

   一些疑問:

   是否能夠用於進行業務監控和系統監控 ?
    數據是否能夠序列處理? 是否有亂序 ? 寫入 ZK 的效率如何 ?  一個 ZK集羣, 單個client 最快寫入效率?20個節點,最快寫入效率如何?
    若是一個節點的數據更新了, client端獲取到watcher 事件, 可是還未處理完, 節點數據又更新了, 是否可能發生? 應該如何處理呢?
    server 端直接關閉, 會有何狀況 ? 
        會致使鏈接上的客戶端, 不斷重試鏈接; 若是client 進行鏈接時, server 還未ready, 則會一直重試, 一旦 server ok ,則鏈接會成功
    集羣若是對應的 myid 不在, 會報錯, zoo.cfg 讀取失敗

3. Todo :

   • ZK 源碼查看

     服務端的啓動
       服務端的總體結構
       客戶端的鏈接
       服務端接收到各種事件的處理
       事務日誌的寫入
       快照的寫入

   • ZK 的應用開發

     1) 設想 ET, 將配置文件存在ZK中,啓動時讀取,且響應更新 ; 以API jar 的方式提供, 能夠用於各個項目中獲取
       2) ZK 節點數據界面可視化開發
       3) 監控工具打造:應用經過ZK將數據傳入,監控工具從ZK中獲取各個更新數據

   • Zookeeper 的性能壓力測試

     1) 單個client, 針對單個節點的連續寫入能力,測試寫入性能, 另外配合一個client註冊watcher, 看是否能夠連續獲取到更新的數據
       2) 單個client, 針對打個節點不斷寫入子節點,測試寫入性能, 另外註冊 watcher , 看是否能夠獲取到更新的事件
       3) 使用場景有些相似於 MQ 的使用, 對於ZK讀取數據的性能測試