zookeeper架構(gòu)設(shè)計與角色分工是什么
這篇文章主要講解了“zookeeper架構(gòu)設(shè)計與角色分工是什么”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“zookeeper架構(gòu)設(shè)計與角色分工是什么”吧！
創(chuàng)新互聯(lián)專注于企業(yè)全網(wǎng)整合營銷推廣、網(wǎng)站重做改版、阜平網(wǎng)站定制設(shè)計、自適應(yīng)品牌網(wǎng)站建設(shè)、成都h5網(wǎng)站建設(shè)、購物商城網(wǎng)站建設(shè)、集團公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為阜平等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。
另外：follower和observer同時均為learner（學(xué)習(xí)者）角色，learner的分工是同步leader的狀態(tài)。
zookeeper的讀寫
??
zookeeper的各個復(fù)制集節(jié)點（follower，leader，observer）都包含了集群所有的數(shù)據(jù)且存在內(nèi)存中，像個內(nèi)存數(shù)據(jù)庫。更新操作會以日志的形式記錄到磁盤以保證可恢復(fù)性，并且寫入操作會在寫入內(nèi)存數(shù)據(jù)庫之前序列化到磁盤。
??每個ZooKeeper服務(wù)器都為客戶端服務(wù)。客戶端只連接到一臺服務(wù)器以提交請求。讀取請求由每個服務(wù)器數(shù)據(jù)庫的本地副本提供服務(wù)。更改服務(wù)狀態(tài)，寫請求的請求由zab協(xié)議處理。
??作為協(xié)議協(xié)議的一部分，來自客戶端的所有寫入請求都被轉(zhuǎn)發(fā)到稱為leader的單個服務(wù)器。其余的ZooKeeper服務(wù)器（稱為followers）接收來自領(lǐng)導(dǎo)者leader的消息提議并同意消息傳遞。消息傳遞層負(fù)責(zé)替換失敗的leader并將followers與leader同步。
??ZooKeeper使用自定義原子消息傳遞協(xié)議zab。由于消息傳遞層是原子的，當(dāng)領(lǐng)導(dǎo)者收到寫入請求時，它會計算應(yīng)用寫入時系統(tǒng)的狀態(tài)，并將其轉(zhuǎn)換為捕獲此新狀態(tài)的事務(wù)。
zk的CAP原則
??cap原則是指作為一個分布式系統(tǒng)，一致性，可用性，分區(qū)容錯性這三個方面，最多只能任意選擇兩種。就是必定會要有取舍。
一致性C
??Zookeeper是強一致性系統(tǒng)，同步數(shù)據(jù)很快。但是在不用sync()操作的前提下無法保證各節(jié)點的數(shù)據(jù)完全一致。zookeeper為了保證一致性使用了基于paxos協(xié)議且為zookeeper量身定做的zab協(xié)議。這兩個協(xié)議是什么東西之后的文章會講。
可用性A（高可用性和響應(yīng)能力）
??Zookeeper數(shù)據(jù)存儲在內(nèi)存中，且各個節(jié)點都可以相應(yīng)讀請求，具有好的響應(yīng)性能。Zookeeper保證了可用性,數(shù)據(jù)總是可用的,沒有鎖.并且有一大半的節(jié)點所擁有的數(shù)據(jù)是最新的,實時的。
分區(qū)容忍性P
??有2點需要分析的
節(jié)點多了會導(dǎo)致寫數(shù)據(jù)延時非常大（需要半數(shù)以上follower寫完提交）,因為需要多個節(jié)點同步.
節(jié)點多了Leader選舉非常耗時, 就會放大網(wǎng)絡(luò)的問題. 可以通過引入 observer節(jié)點緩解這個問題.
zookeeper在CAP問題上做的取舍
嚴(yán)格地意義來講zk把取舍這個問題拋給了開發(fā)者即用戶。
??為了協(xié)調(diào)CA（一致性和可用性），用戶可以自己選擇是否使用Sync()操作。使用則保證所有節(jié)點強一致，但是這個操作同步數(shù)據(jù)會有一定的延遲時間。反過來若不是必須保證強一致性的場景，可不使用sync，雖然zookeeper同步的數(shù)據(jù)很快，但是此時是沒有辦法保證各個節(jié)點的數(shù)據(jù)一定是一致的，這一點用戶要注意。實際的開發(fā)中就要開發(fā)者根據(jù)實際場景來做取舍了，看更關(guān)注一致性還是可用性。
??為了協(xié)調(diào)AP（一致性和擴展性），用戶可以自己選擇是否添加obsever以及添加個數(shù)，observer是3.3.0 以后版本新增角色，它不會參加選舉和投票過程，目的就是提高集群擴展性。因為follower的數(shù)量不能過多，follower需要參加選舉和投票，過多的話選舉的收斂速度會非常慢，寫數(shù)據(jù)時的投票過程也會很久。observer的增加可以提高可用性和擴展性，集群可接受client請求的點多了，可用性自然會提高，但是一致性的問題依然存在，這時又回到了上面CA的取舍問題上。
感謝各位的閱讀，以上就是“zookeeper架構(gòu)設(shè)計與角色分工是什么”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對zookeeper架構(gòu)設(shè)計與角色分工是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！
新聞標(biāo)題：zookeeper架構(gòu)設(shè)計與角色分工是什么
鏈接URL：http://m.jiaotiyi.com/article/jjdesp.html