有一段時間沒寫博客，今天想着把自己近幾個月做的筆記分享一波。
前兩個月我一直在看zk的視頻：https://coding.imooc.com/learn/list/201.html 從開始看這位老師的視頻，到現在有一年多，覺得這位老師講的很不錯，所以分享一波，接下來，我們步入正題。
第一：zookeeper主要目錄結構
bin：主要的一些運行命令
conf：存放配置文件，其中需要修改zk.cfg
contrib:附加的一些功能
dist-maven:mvn編譯后目錄
docs：文檔
recipes：案例demo代碼
src：源碼
第二：配置文件簡介
zoo.cfg配置
ticktime：用於計算的時間單元。比如session超時：N*ticktime
initLimit：用於集群，允許從節點連接並同步到master節點的初始化時間，以ticktime的倍數來表示。
syncLimit：用於集群，master主節點與從節點之間發送消息，請求和應答時間長度。（心跳機制）
dataDir：必須配置 zk相關存儲的數據
dataLogDir：日志目錄，不配置會和dataDir共用目錄。
clientPort：連接服務器端口，默認2181
第三：zk數據模型
zk:是一個樹形結構，類似於前段開發組件tree.js
zk的數據模型也可以理解為Linux/unix文件目錄：/usr/local.../
每個節點都稱之為znode，它可以有子節點，也可以有數據
每個節點分為臨時節點和永久節點，臨時節點在客戶端斷開后就消失
每個zk節點都各自的版本號，可以通過命令行來顯示節點信息
每個節數據發生變化，那么該節點的版本號會累加（樂觀鎖）
刪除/修改過時節點，版本號不匹配則會報錯
每個zk節點存儲的數據不宜過大，幾k即可
節點可以設備權限acl，可以通過權限來限制用戶的訪問。
第四：zk作用體現
一：master節點選舉，主節點掛了以后，從節點就會接受工作，並保證這個節點是唯一的，這也是所謂的首腦模式，從而保證我們的集群是高可用的。
二：統一配置文件管理，即只需要不熟一台服務器，則可以把相同配置文件同步更新到其他所喲與的服務器，次操作在雲計算中用的特別的多（假設修改了redis統一配置）
三：發布與訂閱，類似消息隊列MQ（amq，rmq。。），dubbo發布者把數據存在znode上，訂閱者會讀取這個數據。
四：提供分布式鎖，分布式環境不同進程之間爭奪資源，類似於多線程中的鎖。
五：集群管理，集群保證數據的強一致性。 主節點數據會同步到附屬節點 客戶端不管鏈接任何客戶端的時候都會保證讀取數據的一致性。