前言

在一年前我曾經有做過一些Zookeeper的相關總結，現在我們再把它撿回來，重新的把一些前因後果都扯得更加明白。

一、分布式系統與Zookeeper的關系

1.1集中式服務

我們先從服務部署架構的發展歷程說起，其實無非就是集中式和分布式，集中式就是說，什麽我都是由一台機器搞定的。分布式就是多台服務器聯合完成。所以在一開始的時候一般都是從一台服務器開始，將我們的服務部署上去，然後就是一些老套路，Web應用就部署在Tomcat上開放8080端口提供服務，然後它需要的一個數據庫服務就開放3306端口提供。它的優點就在於結構，部署，項目架構都比較簡單。

然後再根據業務的發展去擴展，那擴展同樣也可以分為兩種方式，一種是橫向擴展，一種為縱向擴展。既然一台搞不定，那就要不提升這個服務器的性能，要不就整多幾台一起上。但是我們想想，也不是個人就會把服務器安排的服服帖帖的呀，這台機子一掛，那就全掛了。而且大型主機的購買，還有研發，維護人才，那都是得花大價錢的。這裡給大家擴展一個“摩爾定律”

反正簡單點來說，就是我花兩倍的錢，根本買不到兩倍的性能。但是橫向擴展就不一樣了，一個人打不過，叫多幾個人一起打不就行了?

1.2去IOE運動

阿裡巴巴搞出來的一個口號，具體點就是IBM小型機，Oracle數據庫，EMC的高端存儲，有興趣的也可以了解一下。因為當時面臨的問題是，企業如果需要提升單機處理能力，成本會很高且性價比極低。還整天怕這怕那的，一宕機就整個服務停掉。慢慢的國內很多公司跟著一起響應，分布式就起來了。

1.3分布式服務

分布式系統有著它具體的定義:分布式系統是一個硬件或者軟件組件分布在不同的網絡計算機上，彼此之間僅通過消息傳遞進行通信和協調的系統。所以就是一堆計算機聯合起來對外提供服務，但是對於用戶來說，像是一台機子在完成這事。

特點很多，大致就是下面5個:分布:這個就是多台計算機都被放置在了不同的位置對等:集群中的多個工作節點都是一個貨色，乾的都一樣的活兒。而且存在副本概念並發:多個機器同時操作一份數據可能會引發的數據不一致問題全局時鍾:多個主機上的事件先後順序會對結果產生影響，這也是分布式場景中非常複雜的一個問題各種故障:某節點宕機，網絡不好···突發情況

1.4分布式場景中經常遇到的幾個問題通信異常:其實就是網絡問題，導致多節點狀態下數據不一致網絡孤立:這個其實就是各個子網絡內部正常，但是整個系統的網絡是不正常的。導致局部數據不一致的問題

節點宕機問題分布式三態:成功，失敗，超時這3種狀態引出的各個問題。請求發送和結果響應都有可能丟失，無法確定消息是否發送/處理成功數據丟失:這個一般通過副本機制，從其它節點讀取解決，或者對於有狀態的節點來說丟失數據就可以通過恢復狀態來解決。異常處理原則:任何在設計階段考慮到的異常情況都必須假設一定會在實際運行中發生

1.5衡量分布式系統的性能標準性能:主要就是吞吐能力，響應延遲，並發能力。系統某一時間可以處理的數據總量，通常是用系統每秒處理的總數據量衡量，而響應延遲指的是完成某一功能所需要的的時間。

並發能力就是同時完成某一功能的能力，通常就是用QPS衡量可用性:在面對各種異常時可以正確提供服務的能力。比如我們常說的5個9就是指一年內只有5分鍾的宕機時間。6個9就是31秒可擴展性:指可以通過擴大機器規模達到提高系統性能的效果一致性:副本管理

但是這些標準都是一個方面要求太高之後會帶動另外一方面變差，比如說我們需要做到高可用，可能需要多個副本，但是多個副本的狀態下，對於數據的一致性又很難去做到了。然後高吞吐下又很難做到低延遲，所以我們需要針對自己的業務場景去進行考量。

1.6對於一致性的擴展強一致性:寫操作完成之後，讀操作一定能讀到最新數據，在分布式場景中這樣是非常難實現的，比如Paxos算法，Quorum機制，ZAB協議都是乾這個事的。弱一致性:不承諾可以立即讀到寫入的值，也不承諾多久之後數據能夠達到一致，但會盡可能的保證到某個時間級別(比如XX時，XX分，XX秒後)，數據可達到一致性狀態。

它還有一個特例叫做最終一致性，就是盡可能快的保證數據的一致。但是這個快到底是多快，就沒有準確定義了。好比女票想要吃到炸雞，你給點了份外賣，可是美團騎手，餓了嗎騎手也說不準什麽時候送到，他只能說保證盡快送到。就這麽個意思。

因為最終一致性實在是太弱了所以我們還有一些特例情況會出現讀寫一致性，它是指用戶讀取自己寫入的結果永遠可以第一時間看到自己更新的內容，這個就像微信朋友圈一樣的，我們發出來的東西，微信是一定會讓我們看到的，可是朋友們是不是你發了立刻就能看到，那可就說不準了。

還有一些單調讀一致性，因果一致性就不展開說明了，有興趣的小夥伴可以自行搜索。

總而言之，為了保證系統的高可用，防止單點故障引發的問題，並能夠讓分布在不同節點上的副本都能正常為用戶提供服務，這時，我們的Zookeeper就應運而生了。它就能幫助我們解決這個分布式系統中數據一致性的問題

需要解決這個問題我們需要了解分布式事務，分布式一致性算法，Quorum機制，CAP和BASE理論，接下來我們慢慢去展開

二、分布式事務

事務:單機存儲系統中用來保證存儲系統的數據狀態一致性，這是不是讀起來有點拗口，沒事，我們換個說法，廣義上的事務，就是指一個事情的所有操作，要不全部成功，要不全部失敗，沒有中間狀態。狹義一點，那就是數據庫做的那些操作。特征也很簡單，就是耳熟能詳的ACID。

分布式系統中每個節點都僅僅知道自己的操作是否成功，但是不知道其它節點是個啥情況，這就有可能導致各節點的狀態可能是不一致的，所以為了實現跨越多節點且保證事務的ACID時，需要引入一個協調者，然後參與事務的各個節點都叫做參與者

典型的套路就是2PC和3PC，接下來我們慢慢展開

2.12PC是個什麽東西

在事務的參與過程中會產生多個角色，暫時我們先這麽理解，協調者負責事務的發起，而參與者負責執行事務。

假定存在上面的3個角色，分別是一個協調和兩個參與，此時我們需要A，B執行一個事務，並且要求這個事務，要麽同時成功，要麽同時失敗。

2PC階段一:執行事務

此時協調者會先發出一個命令，要求參與者A，參與者B都都去執行這個事務，但是不提交

說的再詳細一點，就會產生寫redo，undo的日志，鎖定資源，執行事務。但是執行完了之後，直接向協調者打報告，詢問一下，大哥我能提交嗎?

這個在日常寫Java的過程中應該經常遇到，就是前面寫了一大堆操作，但是等到最後一定會寫一個()這樣的東西，這就是所謂的執行但不提交

2PC階段二:提交事務

當協調者收到第一階段中的所有事務參與者(圖中的A，B)的反饋(這個反饋簡單理解為，告訴協調者前面的第一階段執行成功了)時，就發送命令讓所有參與者提交事務。

如果要說的再細一點，那就是協調者收到反饋，且所有參與者均響應可以提交，則通知參與者進行commit，否則rollback

所以2PC也叫做二階段提交，其實就是這麽簡單分成了兩步，一步執行，一步提交。

2PC的4個缺點:性能

整個流程看下來就知道這明顯產生了同步阻塞，各個需要操作數據庫的節點都佔用了數據庫的資源。只有當協調者收到所有節點都準備完畢的反饋，事務協調者才會通知commitorrollback，而參與者執行完這個commitorrollback的操作後，才會去釋放資源。

2PC的4個缺點:單點故障

那我們剛剛也知道了，協調者才是這個事務的核心。假如此時協調者故障宕機，會導致通知無法傳達到參與者的問題，比如收不到那個commitorrollback，整一個事務便會停滯。

2PC的4個缺點:數據不一致

協調者在第二階段會發送commitorrollback。可是這並不能保證每一個節點都正常收到這個命令，所以會可能竄在，參與者A收到了命令，提交了事務，但是參與者B沒有。所以網絡波動是永恆的病因，你永遠無法躲開這個因素。

2PC的4個缺點:不存在容錯機制

這個協調者需要收到所有的節點反饋準備完成才會下達commit的指示，任意一個參與者的響應沒有收到，協調者就會進行等待，而且只要存在一個宕機的節點，都會使得整個事務失敗回滾。

2.23PC是個啥東西

在2PC的前提下進行了一個改良，將2PC中的準備階段進行拆分，形成，，三個階段。

並且引入超時機制，一旦事務參與者在指定時間內沒有收到協調者的commitorrollback指令，就會自動進行本地commit，解決協調者的單點故障問題

3PC第一階段

協調者先詢問:哎你們這幫人到底能不能行?參與者就根據自身的實際情況回答yesorno。

3PC第二階段

如果參與者都是返回同意，協調者則向所有參與者發送預提交請求，並進入準備階段，這裡的準備階段其實就是讓參與者鎖定資源，等待指令的意思，然後就是事務的執行，此時也像2PC一樣，執行但不提交。然後等待協調者的指令，此時如果遲遲等不到指令，一段時間後就會自行本地提交

但是這樣也會存在弊端，比如協調者成功給1，2參與者都發送回滾，然後3剛好就沒收到，那麽3就自動提交了，所以超時機制其實並不能完全保證數據的一致性

三、分布式一致性算法

3.1Paxos算法

不知道大家有沒有看到我上一年的那篇從零開始的高並發(三)---Zookeeper集群的搭建和leader選舉如果需要詳細了解，推薦跳轉到那篇哦。

Paxos算法是一個名字叫提出的一種基於消息傳遞且具有高度容錯特性的一致性算法

是不是覺得繞口?沒事，我們只需要知道，分布式系統中不可避免的會發生進程被kill，消息延遲，重複，丟失···一系列問題，Paxos算法就是在這些異常情況下的仍然保證數據一致性的東西。那這東西和Zookeeper有啥關系呢?Zookeeper是存在一個ZAB協議的，但是這個ZAB協議底層就是封裝了Paxos算法的。

3.2Paxos中存在的角色及與Zookeeper集群的關系Proposer提議者:顧名思義就是發起提案的人接受者:它們是可以表決的，可以接受或者否決提案Learner學習者:提案被超過半數的接受的話，就學習這個提案

映射到Zookeeper集群中，就分別是leader，follower，observer，它們有點像是主席，人大代表，和全國老百姓的關系，主席提出一個提案，人大代表參與投票，全國老百姓被動接受，大概就是這麽個感覺。相比於之前的2PC，3PC，它只需要半數通過即可提交。所以這種屬於弱一致性，2PC，3PC這些就屬於強一致性

3.3Raft算法

請點擊這個鏈接，相信你一定能夠很快掌握。我這裡還是小小的說明一下吧，這個是一個PPT的形式，告訴你，Raft到底是個什麽東西，非常好懂，我這裡跳過前面的一些東西，直奔主題

這裡說到了，Raft是實現分布式共識算法的一個協議

這裡假設一個節點有3種不同的狀態

第一種，followerstate(無線條)

第二種，candidatestate(虛線)

第三種，leaderstate(實線)記住leader是從candidate候選人那裡選出來的

首先我們一上來，所有的節點都是followerstate

接下來，所有的follower節點都尋找leader，當他們找不到的時候，就會自發成為候選人發起投票(問其它人是否讚成我成為leader)，什麽情況才會找不到呢?那肯定就是leader掛了嘛

此時它就發送給其它節點投票的提案，然後其它節點也會給予它反饋，當它接收到超過半數的節點的反饋的時候，它就可以順理成章的成為leader了。

之後寫數據的請求就會直接發給leader，由leader廣播給其它的follower，此時也是只要超過半數節點返回正反饋，那這個寫數據的事務就會被執行，然後leader再給它們發送提交命令，事務就算執行成功了。

3.4ZAB協議

內容在從零開始的高並發(四)---Zookeeper的分布式隊列

Zookeeper的底層實現就是ZAB協議，它實現了崩潰恢復(leader崩潰)和消息廣播(客戶端寫數據Zookeeper要保證多節點都成功寫入)功能。主要就是保證在leader服務器上提交的事務最終讓所有服務器都提交，並確保丟棄掉只在leader服務器上所提出的事務

3.5QuorumNWR機制

QuorumNWR:Quorum機制是分布式場景中常用的，用來保證數據安全，並且在分布式環境中實現最終一致性的投票算法。這種算法的主要原理來源於鴿巢原理。它最大的優勢，既能實現強一致性，而且還能自定義一致性級別。

鴿巢原理，又名狄利克雷抽屜原理、鴿籠原理。

其中一種簡單的表述法為:若有n個籠子和n+1隻鴿子，所有的鴿子都被關在鴿籠裡，那麽至少有一個籠子有至少2隻鴿子。

另一種為:若有n個籠子和kn+1隻鴿子，所有的鴿子都被關在鴿籠裡，那麽至少有一個籠子有至少k+1隻鴿子。

為什麽從抽屜原理說起?一來大家對這個比較熟悉，也容易理解，二來它與Quorum機制有異曲同工的地方。抽屜原理，2個抽屜每個抽屜最多容納2個蘋果，現在有3個蘋果無論怎麽放，其中的一個抽屜裡面肯定會有2個蘋果。那麽我們把抽屜原理變變型，2個抽屜一個放了2個紅蘋果，另一個放了2個青蘋果，我們取出3個蘋果，無論怎麽取至少有1個是紅蘋果，這個理解起來也很簡單。我們把紅蘋果看成更新了的有效數據，青蘋果看成未更新的無效數據。便可以看出來，不需要更新全部數據(並非全部是紅蘋果)我們就可以得到有效數據，當然我們需要讀取多個副本(取出多個蘋果)。

回到QuorumNWR機制的NWR到底指什麽

N:複製的節點數，即一份數據被保存的副本數。W:寫操作成功的節點數，即每次數據寫入寫成功的副本數。W肯定是小於等於N的。R:讀操作獲取最新版本數據所需的最小節點數，即每次讀取成功至少需要讀取的副本數。

總結:這三個因素決定了可用性，一致性和分區容錯性。只要保證(W+R>N)就一定能讀取到最新的數據，數據一致性級別完全可以根據讀寫副本數的約束來達到強一致性！

分以下三種情況討論:前提，當N已經固定了。

W=1，R=N，WriteOnceReadAll

在分布式環境中，寫一份，那麽如果要讀取到最新數據，就必須要讀取所有節點，然後取最新版本的值了。寫操作高效，但是讀操作效率低。一致性高，分區容錯性差，可用性低

R=1，W=N，ReadOnlyWriteAll

在分布式環境中，所有節點都同步完畢，才能讀取，所以只要讀取任意一個節點就可以讀取到最新數據。讀操作高效，但是寫操作效率低。分區容錯性好，一致性差，實現難度更高，可用性高

W=Q，R=QwhereQ=N/2+1

可以簡單理解為寫超過一半節點，那麽讀也超過一半節點，取得讀寫性能平衡。一般應用適用，讀寫性能之間取得平衡。如N=3，W=2，R=2，分區容錯性，可用性，一致性取得一個平衡。而ZooKeeper就是這麽去設計的

需要補充的是，Zookeeper並沒有實現必須要客戶端讀取超過半數的節點，所以它是允許客戶端讀取到的不是最新同步完成的數據的，但是可能性比較小。數據沒有同步完成的節點其實客戶端也大概率是連接不上的，因為無論是網絡問題還是機器問題導致leader發送數據過去它做不了的話，客戶端肯定也連不上它。要是剛好就是在同步數據的中間狀態客戶端發起了訪問的話，也是有辦法解決的，可以自己了解一下。

3.6CAP理論CAP理論:2000年7月份被首次提出，CAP理論告訴我們，一個分布式系統不可能同時滿足C，A，P三個需求C:Consistency，強一致性，分布式環境中多個數據副本保持一致A:，高可用性，系統提供的服務必須一直處於可用，對於用戶的每一個操作請求總是能在有限時間內返回結果P:分區容錯性，分布式系統在遇到任何網絡分區故障時，仍然需要能夠保證對外提供滿足一致性和可用性的服務

既然一個分布式系統不能同時滿足C，A，P三個需求，我們就要就我們的需求去取舍了。放棄P:最簡單的極端做法，就是放置在一個節點上，也就只有一個數據副本，所有讀寫操作就集中在一台服務器上，有單點故障問題。放棄P也就意味著放棄了系統的可擴展性，所以分布式系統一般來說，都會保證P放棄A:一旦系統遇到網絡分區或者其他故障時，服務需要等待一段時間，在等待時間內就無法正常對外提供服務，即服務不可用放棄C:事實上，放棄一致性是指放棄數據的強一致性，而保留最終一致性，具體多久達到數據同步取決於存儲系統的設計

CAP只能3選2，因為在分布式系統中，容錯性P肯定是必須有的，所以這時候無非就兩種情況，網絡問題導致要麽錯誤返回，要麽阻塞等待，前者犧牲了一致性，後者犧牲了可用性。舉個例子，比如HBase就是追求數據的一致性的，而Cassandra則是可用性。

經驗總結:不要花費精力浪費在設計同時滿足CAP的分布式系統分區容錯性往往是分布式系統必然要面對和解決的問題。所以應該把精力放在如何根據業務特點在A和C之間尋求平衡。對於單機軟件，因為不用考慮P，所以肯定是CA型，比如MySQL對於分布式軟件，因為一定會考慮P，所以又不能兼顧A和C的情況下，只能在A和C做權衡，比如HBase，Redis等。做到服務基本可用，並且數據最終一致即可。

所以，就產生了BASE理論。

3.7BASE理論

多數情況下，其實我們也並非一定要求強一致性，部分業務可以容忍一定程度的延遲一致，所以為了兼顧效率，發展出來了最終一致性理論BASE，來自ebay的架構師提出。BASE理論全稱:全稱:(基本可用)，Softstate(軟狀態)，和(最終一致性)三個短語的縮寫。核心思想是:即使無法做到強一致性，但每個應用都可以根據自身業務特點，采用適當的方式來使系統達到最終一致性。一句話概括，做事別走極端，BASE是對CAP理論中的C和A進行權衡得到的結果。

不是強一致，而是最終一致。不是高可用，而是基本可用。

(基本可用):基本可用是指分布式系統在出現故障的時候，允許損失部分可用性，即保證核心可用

例如淘寶雙11，為保護系統穩定性，正常下單，其他邊緣服務可暫時不可用。部分非核心服務宕機此時是允許的。

SoftState(軟狀態):軟狀態是指允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。分布式存儲中一般一份數據至少會有三個副本，允許不同節點間副本同步的延時就是軟狀態的體現。通俗的講:允許存在不同節點同步數據時出現延遲，且出現數據同步延遲時存在的中間狀態也不會影響系統的整體性能

(最終一致):最終一致性是指系統中的所有數據副本經過一定時間後，最終能夠達到一致的狀態。弱一致性和強一致性相反，最終一致性是弱一致性的一種特殊情況，要求最終達到一致，而不是實時強一致

Finally

總的來說，我們提到了集中式和分布式服務部署架構的分析，設計分布式系統會遇到的各種難題:數據一致性的問題

2PC和3PC是通用的思路實現，還是有缺點。PaxosRaftZAB就算出現了分布式網絡通信異常等相關棘手的問題，以上這些算法也能實現一致性

議會製QuorumNWR機制:R+W>N===>少數服從多數

一致性和可用性的衝突問題，CAP和BASE:分布式系統一定要滿足P，只能在C和A中做權衡

絕大部分系統都是BASE系統(基本可用+最終一致)

【編輯推薦】

【責任編輯:未麗燕

TEL:(010)68476606】
點讚0