這是ZK學習筆記的下篇, 主要希望可以分享一些 ZK 的應用以及其應用原理 我本人的學習告一段落, 不過還遺留了一些ZK相關的任務開發和性能測試的任務, 留待以後完成之後再通過其他文章來進行分享了 ZK應用場景: 1. 一個服務多台機器, 快速修改配置 2. 服務的消費者如何動態知道服務有多少個提供 ...
這是ZK學習筆記的下篇, 主要希望可以分享一些 ZK 的應用以及其應用原理
我本人的學習告一段落, 不過還遺留了一些ZK相關的任務開發和性能測試的任務, 留待以後完成之後再通過其他文章來進行分享了
ZK應用場景:
1. 一個服務多台機器, 快速修改配置
2. 服務的消費者如何動態知道服務有多少個提供者
3. 生產系統部署多少個業務系統以及每個業務系統提供多少介面ZK案例-配置管理:
服務端:
每次啟動, 會將提供的request都註冊到 ZK 中
客戶端:
啟動時讀取 ZK 中所有的 service 提供者,並且組裝出可用的 service
優化:
伺服器啟動註冊本地IP,使用臨時節點的方式, 一旦連接失效, 客戶端可以收到節點消失的通知ZK案例-分散式鎖
排他鎖:只能一個線程獲取.其他線程需要等待
ZK實現:
獲得鎖:構建目錄, 葉子節點創建成功則認為獲取鎖
排他鎖實現的核心思想:
通過只有一個線程可以創建一個同樣的葉子節點進行實現
線程可以成功創建葉子節點即認為獲取鎖成功,可以執行業務代碼
若線程無法成功創建葉子節點,則認為獲取鎖失敗, 需要進入等待, 多個其他線程創建失敗則多個線程進入等待
線程執行完業務代碼會刪除葉子節點,其他線程獲取到刪除通知,會釋放線程,再次嘗試獲取鎖
共用鎖:可以多個讀操作同時獲取鎖進行處理,一旦出現寫鎖,其他所有操作需要等待寫入完成之後重新獲取鎖
ZK實現:
讀時可以允許其他線程進行讀, 寫是其他線程不可進行其他操作
共用鎖實現的核心思想:
每個節點都向ZK寫入節點信息(Seq節點)
通過排名比較是否自己在第一個來進行判斷是否獲取到鎖
非第一個,則在本身和前面都是讀鎖的情況下才可以繼續,否則獲取失敗,進入等待
性能如何(待測試...)?
在連續不斷有請求到達時,最大TPS有多少, 區分同時有 10個線程競爭和同時有 100個線程競爭的時候ZK的使用和運維
ZK 配置說明:
基於log4j的日誌配置:
運行命令行增加: ZOO_LOG_DIR
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四字命令:
通過 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 更詳細, 包括請求的延遲情況, 服務區記憶體大小, 集群同步等...性能優化:
JVM優化 IO優化 加大 linux系統的文件句柄數和用戶線程數, linux 通過 ulimit 查看配置 業務併發高: 客戶創建多個客戶端連接, 用於不同的業務 減少資源消耗, 比如watcher的數量 提高帶寬擴容:
停機:直接增加節點 不停機: 新增節點: id需要比集群更大 新節點啟動, 加入集群且同步數據 mntr查看新的節點數據成功同步後再執行 依次id從小到大,關閉zk實例,修改配置,啟動實例監控:
zookeeper的事務日誌 磁碟IO 日誌清理:建議定期清理事務日誌和快照文件 連接數,避免過多 watchers 數量 ZK通知延時是否過大
ZK運維繫統
Taokeeper:
功能:
CPU
ZK日誌目錄磁碟空間監控
單機連接數
單機Watcher數量
節點健康狀態
少量統計報表
不足:
目錄查看
網路流量
磁碟IO監控
安裝:
源碼安裝:
包安裝:
初始化腳本:4張表sql
安裝步驟:
1. 修改機器,增加host
zk1node
zk2node
zk3node
個人意見: 無法達到生產使用的標準, 建議自行開發相應的監控系統, 或者運維人員通過四字命令手工監控==================自己總結===============
一些資料
Zookeeper 學習
http://www.open-open.com/lib/view/open1415453633887.htmlzookeeper簡介
http://www.open-open.com/lib/view/open1415453633887.htmlZK的應用,可以再細化:
http://blog.csdn.net/xinguan1267/article/details/38422149 http://cailin.iteye.com/blog/2014486/ (原理)心得
Zookeeper 的使用場景
Zookeeper完全可以解決我們的問題，分散式計算中的協調員，觀察者，分散式鎖 都可以作為zookeeper的關鍵詞 在系統中利用Zookeeper來處理事件通知,隊列,優先隊列,鎖,共用鎖等功能，利用這些特色在分散式計算中發揮重要的作用。 Zookeeper 可以做配置的動態更新（通知機制） 配置管理 & 集群服務管理 所有節點登錄後, 自行獲取配置(公共的,特有的(通過serviceId標示)) 一般節點啟動後負責在 某 path 中寫入自身的service等標誌, 如果已有則不再啟動 管理節點啟動後負責獲取所有其他節點寫入的一些數據, 來確定有多少其他節點正在工作一些疑問:
是否可以用於進行業務監控和系統監控 ? 數據是否可以序列處理? 是否有亂序 ? 寫入 ZK 的效率如何 ? 一個 ZK集群, 單個client 最快寫入效率?20個節點,最快寫入效率如何? 如果一個節點的數據更新了, client端獲取到watcher 事件, 但是還未處理完, 節點數據又更新了, 是否可能發生? 應該如何處理呢? server 端直接關閉, 會有何情況 ? 會導致連接上的客戶端, 不斷重試連接; 如果client 進行連接時, server 還未ready, 則會一直重試, 一旦 server ok ,則連接會成功 集群如果對應的 myid 不在, 會報錯, zoo.cfg 讀取失敗Todo :
ZK 源碼查看
服務端的啟動 服務端的整體結構 客戶端的連接 服務端接收到各類事件的處理 事務日誌的寫入 快照的寫入ZK 的應用開發
1) 設想 ET, 將配置文件存在ZK中,啟動時讀取,且響應更新 ; 以API jar 的方式提供, 可以用於各個項目中獲取 2) ZK 節點數據界面可視化開發 3) 監控工具打造:應用通過ZK將數據傳入,監控工具從ZK中獲取各個更新數據Zookeeper 的性能壓力測試
1) 單個client, 針對單個節點的連續寫入能力,測試寫入性能, 另外配合一個client註冊watcher, 看是否可以連續獲取到更新的數據 2) 單個client, 針對打個節點不斷寫入子節點,測試寫入性能, 另外註冊 watcher , 看是否可以獲取到更新的事件 3) 使用場景有些類似於 MQ 的使用, 對於ZK讀取數據的性能測試
