在開始閱讀之前颊乘，咱們先思考一個問題吮炕，Zookeeper是強一致性的嗎腊脱？還是最終一致性？
先直接給答案哈龙亲，Zookeeper是保證順序最終一致性陕凹！但為什么不是強一致性的呢？接下來鳄炉，帶著疑問往下看~
前置知識
在了解Zookeeper保證最終一致性之前杜耙，先看下涉及到的關(guān)鍵內(nèi)容。比如ZK內(nèi)為了保證事務(wù)消息拂盯，運用到2PC的思想佑女，實際處理寫請求的過程中，會經(jīng)過Proposal流程和Commit流程
2PC（Two-Phase Commit）
2PC即二階段提交谈竿，與二階段提交相似的团驱，還有三階段提交。二階段提交和三階段提交可以認(rèn)為是一種一致性協(xié)議空凸，保障在分布式系統(tǒng)中數(shù)據(jù)的一致性嚎花，主要用于分布式事務(wù)的場景中。
二階段提交呀洲，顧名思義就是分為兩個階段提交請求嘛紊选，其流程可以認(rèn)為是準(zhǔn)備階段和提交階段
以下是簡單的概括，其流程和原理實際上挺復(fù)雜的两嘴，但為了不跑偏文章的主題丛楚，就簡單的概括一下2PC是什么。
準(zhǔn)備階段：事務(wù)的發(fā)起者本地執(zhí)行事務(wù)憔辫，但不提交事務(wù)；然后給各個相關(guān)的服務(wù)發(fā)起分布式事務(wù)的提交請求仿荆，然后等待其他服務(wù)的響應(yīng)贰您；至于其他接收到提交請求非服務(wù)器坏平，會給事務(wù)發(fā)起者響應(yīng)ACK，可以簡單認(rèn)為是是否可以執(zhí)行
提交階段：當(dāng)事務(wù)發(fā)起者收到所有的響應(yīng)锦亦，如果所有的響應(yīng)都是YES（可以執(zhí)行）舶替，就提交本地事務(wù)并讓其他服務(wù)執(zhí)行事務(wù)請求；如果有部分響應(yīng)不是YES杠园，則回滾本地請求
Zookeeper處理事務(wù)流程
Proposal階段：Leader會將寫請求封裝為一個Proposal提案顾瞪，每個Proposal提案有一個全局Id，即zxid抛蚁；然后會發(fā)送到所有的Follower陈醒，當(dāng)Follower接收到后令漂，會給Leader響應(yīng)ACK
Commit階段：當(dāng)Leader接收到超過一半的Follower響應(yīng)的ACK锐想，就會認(rèn)為Proposal發(fā)送成功，執(zhí)行本地事務(wù)疆前，并發(fā)送Commit消息給所有Follower肚逸；當(dāng)Follower接收到Commit消息后爷辙，會將Follower內(nèi)本地消息提交。
寫請求事務(wù)處理
經(jīng)過上面的前置知識了解朦促，Zookeeper處理消息的事務(wù)流程膝晾，主要是Proposal和Commit階段。
接下來务冕，以文字結(jié)合圖片的形式玷犹，大致了解寫請求的過程。
-
客戶端發(fā)送寫請求洒疚，Leader接收到寫請求后歹颓，生成Proposal提案且生成全局的zxid，并將Proposal提案寫入磁盤事務(wù)日志文件油湖。但實際上巍扛，為了提高性能，會先將Proposal寫入os cache中乏德，再在某時機將os cache中的內(nèi)容寫入磁盤事務(wù)文件 【1】寫請求發(fā)送到Leader的過程.png
-
寫入Proposal提案后撤奸，Leader會廣播到每個Follower都獨有的FIFO隊列，這樣的話喊括，就能保證數(shù)據(jù)的順序執(zhí)行胧瓜；當(dāng)Follower接收到Proposal后，同樣會類似Leader那樣為了提高寫數(shù)據(jù)的性能郑什，先寫到Follower的os cache中府喳，然后在某時機寫入磁盤事務(wù)日志文件；當(dāng)Follower寫入Proposal后蘑拯，會給Leader響應(yīng)ACK 【2】寫請求發(fā)送到Leader的過程.png
當(dāng)Leader接收到的ACK超過集群的一半钝满，就會認(rèn)為Proposal提交成功兜粘。Leader本地就會執(zhí)行事務(wù)，將數(shù)據(jù)封裝為Znode寫到內(nèi)存中弯蚜，并發(fā)送commit命令給所有Follower孔轴，當(dāng)其它Follower接收到commit命令后，同樣會將數(shù)據(jù)封裝為Znode寫到內(nèi)存中碎捺。
目前為止路鹰，就可以認(rèn)為寫請求處理完畢，客戶端可以從Leader讀取剛剛的寫請求收厨，但如果客戶端從Follower讀取的話晋柱，一定能讀取到嗎？
這就要回到文章開始的一個思考題帽氓，其答案是Zookeeper不能保證強一致性趣斤，只能保證順序的最終一致性。咱們回過頭想下寫請求的事務(wù)處理過程黎休。
當(dāng)寫請求生成的Proposal被廣播到每一個Follower浓领，只是先寫到os cache或磁盤事務(wù)日志文件中，這時候并沒有生成Znode寫到內(nèi)存势腮，對于客戶端來說是讀取不到的联贩；如果Leader發(fā)出commit請求的時候，由于網(wǎng)絡(luò)原因或者Follower短暫的失去與Leader的連接捎拯，其實都有可能出現(xiàn)短暫的消息不一致泪幌，這是如果客戶端請求訪問還沒生成Znode數(shù)據(jù)的話，肯定讀取不到署照。所以這就解釋了祸泪，為什么Zookeeper并不能保證強一致性。
但為什么說Zookeeper能保證順序最終一致性呢建芙？
這是因為Leader與Follower提交Proposal都是經(jīng)過FIFO的隊列没隘，其保證了數(shù)據(jù)有序。除此之外禁荸，如果Leader提交commit后右蒲，F(xiàn)ollower沒有及時接收到commit，會有其他保障機制赶熟，保證最后集群內(nèi)所有服務(wù)器都趨于數(shù)據(jù)一致瑰妄。
以上就是寫請求落在Leader上的大致經(jīng)過，如果寫請求落在Follower是怎樣呢映砖？其實流程上是沒什么區(qū)別的间坐，只不過是Follower將寫請求轉(zhuǎn)發(fā)給Leader，由Leader去處理寫請求，然后就和上訴的流程一樣眶诈，最后達到數(shù)據(jù)最終一致涨醋。
如果覺得文章不錯的話瓜饥，麻煩點個贊哈逝撬，你的鼓勵就是我的動力！對于文章有哪里不清楚或者有誤的地方乓土，歡迎在評論區(qū)留言~
