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

微信掃一掃加我為好友
QQ號聯(lián)系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
