在學習的過程當中,咱們總須要一個來自靈魂的拷問: 爲何?node
這個問題有深度,那要從五百萬年提及,在遙遠的塞伯坦星球.....算法
扯遠了...服務器
在遙遠在單機單服務的時代 , 想要擴展服務 , 只能增長硬件配置 . 如今看來 ,有如下問題:架構
這時候,分佈式應運而生,將業務拆分開來,好比:倉庫,訂單,支付等等,各管各的 , 風險拆分, 好比: 訂單服務掛了,不影響倉庫和支付.分佈式
這是分佈式的初始模式, 風險少了, 再用個Nginx作個代理,集羣化.而後彷佛大概也許Mybe能夠 浪裏個浪了 ~~工具
當項目愈來愈大,模塊愈來愈多.又來問題了.性能
一開始的服務拆分並不必定很理想, 再加後期業務迭代, 可能產生不少個模塊,各模塊間的調用混亂 , 一條業務線中不知道串了多少個模塊.學習
下圖參考下: T_T代理
當你想了解一條線的時候,內心可不止一萬個那啥...server
那麼急需,迫切的須要一個能夠把這個東西治理一下的工具.
buling~ buling ~ zookeeper來啦
先來感覺下使用zookeeper後的趕腳
啊.kimoji...
Zookeeper是一個高性能的分佈式系統的協調服務
最終一致性
保證各個節點服務器數據可以最終達成一致,zk的招牌功能
順序性
從同一客戶端發起的事務請求,都會最終被嚴格的按照其發送順序被應用到zk中,這也是zk選舉leader的依據之一
可靠性
凡是服務器成功的使用一個事務,並完成了客戶端的響應,那麼這個事務所引發的服務端狀態變動會被一直保留下去
實時性
zk不能保證多個客戶端能同時獲得剛更新的數據,因此若是要最新數據,須要在讀數據以前強制調用sync接口來保證數據的實時性
原子性
數據更新要麼成功要麼失敗
單一視圖
不管客戶端連的是哪一個節點,看到的數據模型對外一致
Leader
更新系統狀態,處理事務請求,負責進行投票的發起和決議
Leaner
處理客戶端非事務請求,並向客戶端返回結果. 將寫事務請求轉發給Leader,同步Leadker的狀態. 選舉過程當中參與投票.可被選舉.
接收客戶端讀請求,將客戶端寫請求轉發給Leader,不參與投票過程,只同步Leader狀態.目的是爲了擴展系統,提升讀取速度.
Client
請求發起方
數據寫入最終一致性ZAB算法 .
Leader負責處理寫事務請求,Follower負責向Leader轉發寫請求,響應Leader提出的提議.
先了解幾個關鍵字:
狀態
事務ID
流程
znode是zk特有的數據模型,是zk中數據最小單元,znode上能保存數據,經過掛載子節點造成一個樹狀的層次結構。根由/斜槓開始。
節點類型
主要用來經過版本號來實現分佈式鎖的一些控制
znode watch機制也是zk的核心功能之一,是配置管理功能的基石。client端經過註冊watch對象後,只要相應的znode觸發更改,watch管理器就會向客戶端發起回調,可藉此機制實現配置管理的分佈式更新和同步隊列等場景。
[1]洛神獨舞:Zookeeper架構原理和使用場景總結