?
從年后拿到這本書開始閱讀，到準備系統分析師考試之前，終于讀完了一遍，對Zookeeper有了一個全面的認識，整本書從理論到應用再到細節的闡述，內容安排從邏輯性和實用性上都是很優秀的，對全面認識Zookeeper很有幫助，建議大家閱讀。本人看書秉承先把書看薄，再把書講厚的原理，一般喜歡在看的過程中 用筆 在紙上勾勾畫畫，加點注釋增強理解，看完后會從整體知識結構上整理出我的理解，不求詳細，但求關鍵知識點的串聯，最后通過整理的知識點想象自己給別人講解一遍，對照書中目錄，看是否也能像作者面面俱到，調理清晰，對哪塊知識點不明確再翻書復讀，以求透徹理解掌握。以下是我整理的關于此書的筆記，以饗讀者：
(一)分布式基礎知識
- 分布式的特點：分布性、對等性、并發性、缺乏全局時鐘、故障總會發生
- 分布式環境下的各種問題：通訊異常、網絡分區、成功失敗超時三態、節點故障
- 從ACID到BASE的變化
- 一致性協議：
- 2pc（請求處理-->提交確認）與3pc（事務處理能力詢問-->處理后待提交-->提交確認）的特點及優缺點比較
- Paxos協議的原理及在Chubby、Hypertable上的實踐。
(二)Zookeeper可以保證的分布式一致性特性：
- 順序一致性：同一個客戶端發起的事務請求，嚴格按其順序處理
- 原子性：事務請求處理的原子性
- 單一視圖：無論客戶端連接到哪個服務器，看到的數據模型是一致的
- 可靠性：對事務的處理完成并反饋后，狀態會一致保留直到被其他事務改變
- 實時性：一定時間段內，客戶端最終一定能從服務器上讀取到最新的數據狀態
(三)
Zookeeper中的核心概念/特性：
- 全部存儲在內存中的樹形數據節點ZNode，分為持久（順序）型與臨時（順序）節點（生命周期與客戶端會話綁定），每個ZNode只能由一臺服務器創建，且節點的sequential自增數字保障兄弟節點按順序無重復
- 三種集群角色
- Leader：處理事務請求并保證事務請求的順序性（事務指能夠改變Zookeeper服務狀態的操作，一般包括數據節點的創建刪除與內容更新、客戶端會話創建與失效。每一個事務有全局唯一的ZXID）；集群內部各服務器的調度
- Follower:處理客戶端非事務請求、轉發事務請求給Leader、參與事務請求Proposal投票、參與Leader選舉投票
- Observer：只處理非事務服務，不參與任何形式的投票
- Stat數據結構維護當前ZNode的三個數據版本：當前版本version、當前子節點版本cversion、ACL版本aversion
- 客戶端與服務端TCP長連接的會話Session管理，分桶管理策略通過設定固定周期的超時檢查，批量清理超時會話。客戶端利用API可對數據節點進行如下操作：創建會話、創建節點、刪除節點、讀取數據、更新數據、檢測節點是否存在、權限控制。常用開源的兩款zookeeper客戶端：ZkClient、Curator。
- Watcher事件監聽：客戶端通過監聽特點節點上的特定事件，實現分布式協調服務
- ACL：類似于UNIX文件系統的權限控制，包括增、刪、讀、寫、admin設置等五種權限
- Jute為序列化組件
- Zookeeper將所有節點的路徑、數據內容、ACL等信息組成DataTree全部存儲在內存中，其底層數據結構是ConcurrentHashMap,其key是數據節點的path，而value則是真正的數據內容DataNode。通過ZKDatabase管理所有會話、DataTree存儲和事務日志，并定時dump快照到磁盤，同時也方便在啟動時從磁盤上的事務日志和快照數據文件恢復成一個完整的內存數據庫
?
(四)
Zookeeper的核心協議ZAB:
- 主備模型架構保證同一時刻只有一個主進程處理事務請求并廣播狀態，并能保證全局的變更系列被順序應用；
- 所有事務請求必須由一個全局唯一的服務器Leader來協調處理，其他事務請求按照類似兩階段提交的過程向Follower服務器發送proposal提議；
- ZAB協議包括兩種基本模式：崩潰恢復和消息廣播
- 崩潰恢復：當服務啟動、Leader網絡中斷或退出、重啟等進去恢復模式，選舉產生Leader并在過半的機器從該Leader中國完成了數據同步后退出此模式進行消息廣播模式并提供服務，因此只要集群中存在過半的服務器能夠彼此進行正常通信，就可以選舉出新的Leader并再次進入消息廣播模式；
- 消息廣播：Leader為每個事物請求生成ZXID的事務proposal廣播給Follower，Follower接收到后以事務日志的形式寫入本地磁盤并ACK響應，當Leader接收到過半Follower的ACK后，廣播一個commit消息給所有的Follower通知事務提交，同時自身提交，Follower接到commit后也完成提交從而完成這個事務處理。
?
（五）ZAB協議與Paxos算法的區別于聯系：
- 聯系：都有Leader、Follower、epoch值；
- 區別：
- Paxos在新選舉的主進程中會進行兩階段的工作，第一階段讀階段主進程通過和其他進程的通信來收集上一個主進程的提案并提交；第二階段為寫階段即新主進程開始提出自己的提案；
- ZAB協議在讀階段之后額外引入一個同步階段，在此階段中新的Leader會確保存在過半的Follower已經提交了之前Leader周期中所有的事務proposal，從而保證在新Leader提交proposal之前，所有的Follower都完成了對之前所有事務proposal的提交。同步階段完成后再進入寫階段。
?
（六）ZooKeeper典型8大應用場景及對應的特性：
- 數據發布訂閱：對統一配置信息等數據可以通過在Zookeeper創建一個數據節點并讓客戶端進行監聽，主要利用了Zookeeper的Watcher監聽特性；
- 負載均衡：創建一個節點，負載應用把自己的服務地址寫到此節點下，如果此應用掛掉，則此子節點消失
- 命名服務：利用Zookeeper創建順序無重復子節點的特性；
- 分布式協調/通知：不同客戶端都對Zookeeper上的同一個數據節點進行watcher注冊，監聽數據節點的變化，當發生變化所有訂閱的客戶端接收到通知并進行處理；
- 集群管理：利用了watcher監聽與臨時節點在會話失效自動清除的特性。同時，各服務器可以講運行狀態信息寫入到臨時節點中進而有助于Leader收集負載信息；
- Master選舉：所有客戶端創建同一個path的數據節點，只有一個能成功，即為Master；
- 分布式鎖：創建臨時節點，誰成功即獲得鎖。另外，根據創建時不同的類型-序號，根據一定的規則可以模擬出共享鎖、讀寫鎖等；
- 分布式隊列：每個客戶端在指定節點下創建臨時節點，然后獲取該指定節點下的所有子節點并判斷自己是否是序號最小的節點，如果是則可以進行處理，如果不是則進入等待并監聽比自己序號小的最后一個節點，待接到watcher通知后，重復檢查。
（七）細節信息：
- 單機版服務器啟動流程圖：
-
- 集群版啟動流程圖：
-
- Zookeeper服務端對于會話創建的處理，大致分為請求接受、會話創建、預處理、事務處理、事務應用和會話響應6大環節，如圖：
-
?
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
