zookeeper源碼分析和運維總結(jié)老師

Zookeeper架構(gòu)及FastLeaderElection機 是一個分布式協(xié)調(diào)服務(wù)，可用于服務(wù)發(fā)現(xiàn)，分布式鎖，分布 ，配置管理等這一切的基礎(chǔ)，都是oeper提供了一個類似于ux文件系統(tǒng)的樹形結(jié)構(gòu)（可認(rèn)為是輕量級的內(nèi)存文件系統(tǒng)，但只適合存少量信息，完全適合大量文或者大件），時提供對于每節(jié)點的通知機制。 集群是一個基于主 的高可用集群，每個服務(wù)器承擔(dān)如下三種角色中的一Leader一個Zookeeper集群同一時間只會有一個實際工作的Leader，它會發(fā)起并 跳。所有的寫操作必須要通過Leader完成再由Leader將寫操作廣播給其它服務(wù)器。lwer一個oeper集群可能同時存在多個Flwer，它會響應(yīng)eder的心跳。lwer可直接處理并返回客戶端的讀請求，同時會將寫請求轉(zhuǎn)發(fā)給eaer處理，并且負(fù)責(zé)在Leer處理寫請求時對請求進(jìn)行投票。Observer角色與Follower為了保證寫操作的一致性與可用性 專門設(shè)計了一種名為原子廣播（ZAB）的支 恢復(fù)的一致性協(xié)議?；谠搮f(xié)議 實現(xiàn)了一種主從模式的系統(tǒng)架構(gòu)來保持集群中各個副本之間根據(jù)ZAB協(xié)議，所有的寫操作都必須通過Leader完成，Leader寫入本地日志后 到所有的Follower節(jié)點一旦Leader節(jié)點無法工作，ZAB協(xié)議能夠自動從Follower節(jié)點中重新選出一個合適的替代者，即新的Leader，該過程即為 舉。該過程，是ZAB協(xié)議中最為重要和復(fù)雜的過程。通過Leader進(jìn)行寫操作流程如下圖所由上圖可見，通過Leader進(jìn)行寫操作，主要分為五步客戶端向Leader發(fā)起寫請Leader將寫請求以Proposal的形式發(fā)給所有Follower并等待Follower收到Leader的Proposal后返回Leader得到過半數(shù)的ACK（Leader對自己默認(rèn)有一個ACK）后向所有的Follower和Observer發(fā)送Leader將處理結(jié)果返回給客戶這里要注Leader并不需要得到Observer的ACK，即ObserverLeader不需要得到所有Follower的ACK，只要收到過半的ACK即可，同時Leader本身對自己有一個ACK。上圖中有4個Follower，只需其中兩個返回ACK即可，因為(2+1)/(4+1)>1/2Observer雖然無投票權(quán)，但仍須同步Leader的數(shù)據(jù)從而在處理讀請求時通過Follower/Observer進(jìn)行寫操作流程如下圖從上圖可Follower/Observer均可接受寫請求，但不能直接處理，而需要將寫請求轉(zhuǎn)發(fā)給Leader處除了多了一步請求轉(zhuǎn)發(fā)，其它流程與直接寫Leader無任何區(qū) 都可直接處理讀請求，從本地內(nèi)存 數(shù)據(jù)并返回給客戶端即可由于處理讀請求不需要服務(wù)器之間的交互 越多，整體可處理的讀請求量越大，也即讀性能越好每個Zookeeper服務(wù)器，都需要在數(shù)據(jù)文件夾下創(chuàng)建一個名myid的文件，該文件包含整個Zookeeper集群唯一的ID（整數(shù)）。例如某Zookeeper集群包含三臺服務(wù)器，hostname分別zoo1、zoo2zoo3，其myid分別1、23，則在配置文件中其ID與hostname必須一一對應(yīng)，如下所示。在該配置文件中，server.后面的數(shù)據(jù)即為myid類似于RDBMS中的事ID，用于標(biāo)識一次更新操作的ProposalID。為了保證順序性，zkid必須單調(diào)遞增。因此Zookeeper使序號，每次epoch變化，都將低32位的序號重置。這樣保證了zkid的全局遞增性?？赏ㄟ^electionAlg配置項設(shè)置Zookeeper用于的算法。到3.4.10版本為止，可選項有0基于UDP1基于UDP2基于UDP和認(rèn)證的3基于TCP在3.4.10版本中，默認(rèn)值為3，也即基于TCP的FastLeaderElection。另外三種算法已經(jīng)被棄用，并且有計劃在之后的版本中將們徹底刪除而不再支持 算法是標(biāo)準(zhǔn)的FastPaxos算法實現(xiàn)，可解決 算法收斂速度慢的問題服務(wù)器狀LOOKING不確定Leader狀態(tài)。該狀態(tài)下的服務(wù)器認(rèn)為當(dāng)前集群中沒有Leader，會發(fā)起FOLLOWING跟隨者狀態(tài)。表明當(dāng)前服務(wù)器角色是Follower，并且它知道Leader是 者狀態(tài)。表明當(dāng)前服務(wù)器角色是Leader，它 與Follower間的心OBSERVING觀察者狀態(tài)。表明當(dāng)前服務(wù)器角色是Observer，與Folower唯一的不同在于不參與 選票數(shù)據(jù)結(jié)每個服務(wù)器在進(jìn) 時，會發(fā)送如下關(guān)鍵信logicClock每個服務(wù)器會一個自增的整數(shù)，名為logicClock，它表示這是該服務(wù)器發(fā)起的第多少輪state當(dāng)前服務(wù)器的狀self_id當(dāng)前服務(wù)器的self_zxid當(dāng)前服務(wù)器上所保存的數(shù)據(jù)的最大vote_id被推舉的服務(wù)器的vote_zxid被推舉的服務(wù)器上所保存的數(shù)據(jù)的最大投票流自 輪Zookeeper規(guī)定所有有效的投票都必須在同一輪次中。每個服務(wù)器在開始新一輪投票時，會先對自 的logicClock進(jìn)行自增操作初始化選每個服務(wù)器在廣播自己的選票前，會將自己的投票箱清空。該投票箱記錄了所收到的選票。例：服務(wù)器2投票給服務(wù)器3，服務(wù)器3票給服務(wù)器1，則服務(wù)器1的投票箱為(2,3),(3,1),(1,1)。票箱中只會記錄每一投票者的最后一票，如投票者更新自己的選票，其它服務(wù)器收到該新選票后會在自己票箱中更新該服務(wù)器的選發(fā)送初始化選每個服務(wù)器最開始都是通過廣播把票投給自己接收外服務(wù)器會嘗試從其它服務(wù)器獲取投票，并記入自己的投票箱內(nèi)。如果無法獲取任何外部投票，則會確認(rèn)自己是否與集群中其它服務(wù)器保持著有效連接。如果是，則再次發(fā)送自己的投票；如果否，則馬上與之建立連接。判 輪收到外部投票后，首先會根據(jù)投票信息中所包含的logicClock來進(jìn)行不同處外部投票的logicClock大于自己的logicClock。說明該服務(wù)器的輪次于其它服務(wù)器的輪次，立即清空自己的投票箱并將自己的logicClock更新為收到的logicClock，然后再對比自己之前的投票與收到的投票以確定是否需要變更自己的外部投票的logicClock小于自己的logicClock。當(dāng)前服務(wù)器直接忽略該投票，繼續(xù)處外部投票的logickClock與自己的相等。當(dāng)時進(jìn)行選票PK選票,外部投票的logicClock大于自己的logicClock，則將自己的logicClock及自己的選票的logicClock變更為收到的更新為收到的票中的vote_zxid與vote_myid并廣去，另外將收到的票及自己更新后的票放入自己的票箱。如果票箱內(nèi)已存在(self_myid,self_zxid)相同的選票，則直接覆蓋若二者vote_zxid一致，則比較二者的vote_myid，若外部投票的vote_myid比較大，則將自己的票vote_myid更新為收到的票中的vote_myid并廣去，另外將收到的票及自己更新后的票放入自己的票箱統(tǒng)計選如果已經(jīng)確定有過半服務(wù)器認(rèn)可了自己的投票（可能是更新后的投票），則終止投票。否則繼續(xù)接收其它服務(wù)器的投票更新服務(wù)器狀 集群啟初始投票給集群剛啟動時，所有服務(wù)器的logicClock都為1，zxid都為0各服務(wù)器初始化后，都投票給自己，并將自己的一票存入自己的票箱，如下圖所示在上圖中，(1,1,0)第一位數(shù)代表投出該選票的服務(wù)器的logicClock，第二位數(shù)代表被推薦的服務(wù)器的myid，第三位代表被推薦的務(wù)器的最大的zx。由于該步驟中所有選票都投給自己，所以第二位的myd即是自己的my，第三位的zxd即是自己的zx。此時給更新選服務(wù)器收到外部投票后，進(jìn)行選 PK，相應(yīng)更新自己的選票并 去，并將合適的選票存入自己的票箱，如下圖所示服務(wù)器1收到服務(wù)器2的選票（1,2,0）和服務(wù)器3的選票（1,3,0）后，由于所有的logicClock都相等，所有的zxid都相等因此根據(jù)myid判斷應(yīng)該將自己的選票按照服務(wù)器3的選票更新為（1,3,0），并將自己的票箱全部清空，再將服務(wù)器3的選票與自 去。此時服務(wù)器1票箱內(nèi)的選票為(1,3)，(3,3)。同理，服務(wù)器2收到服務(wù)器3的選票后也將自己的選票更新為（1,3,0）并存入票箱然后廣播。此時服務(wù)器2票箱內(nèi)的選票為(2,服務(wù)器3根據(jù)上述規(guī)則，無須更新選票，自身的票箱內(nèi)選票仍為（3,3）服務(wù)器1與服務(wù)器2更新后的選票 去后，由于三個服務(wù) 選票都相同，最后三者的票箱內(nèi)都包含三張投給服務(wù)器3的選票根據(jù)選票確定角根據(jù)上述選票，三個服務(wù)器一致認(rèn)為此時服務(wù)器3應(yīng)該是Leader。因此服務(wù)器1和2都進(jìn)入FOLLOWING狀態(tài)，而服務(wù)器3進(jìn)LEADING狀態(tài)。之后Leader發(fā)起 與Follower間的心跳FollowerFollower重啟投票給Follower重啟，或者發(fā)生網(wǎng)絡(luò)分區(qū)后找不到Leader，會進(jìn)入LOOKING狀態(tài)并發(fā)起新的一輪發(fā)現(xiàn)已有Leader后成為服務(wù)器3收到服務(wù)器1的投票后，將自己的狀態(tài)LEADING以及選票返回給服務(wù)器1。服務(wù)器2收到服務(wù)器1的投票后，將自己的器3確實得到了超過半數(shù)的選票。因此服務(wù)器1進(jìn)入FOLLOWING狀態(tài)。Leader重Follower發(fā)起新投eer（服務(wù)器）宕機后，F(xiàn)lwer（服務(wù)器1和）發(fā)現(xiàn)Leer不工作了，因此進(jìn)入KIG狀態(tài)并發(fā)起新的一輪投票，并給自己。廣播更新選服務(wù)器1和2根據(jù)外部投票確定是否要更新自身的選票。這里有兩服務(wù)12zxid相同。例如在服務(wù)3宕機前服務(wù)12完全與之同步。此時選票的更新主要取決于myid的大服務(wù)12zxid不同。在舊Leader宕機之前，其所主導(dǎo)的寫操作，只需過半服務(wù)器確認(rèn)即可，而不需所有服務(wù)器確認(rèn)。換句話說，服務(wù)12可能一個Leader同步（即zxid與之相同）另一個不同步（zxid比之?。?。此時選票的更新主要取決于誰的zxid較大在上圖中，服務(wù)器1的zxid為11，而服務(wù)器2的zxid為10，因此服務(wù)器2將自身選票更新為（3,1,11），如下圖所示選出新經(jīng)過上一步選票更新后，服務(wù)器1與服務(wù)器2均將選票投給服務(wù)器1，因此服務(wù)器2成為Follower，而服務(wù)器1成為新的Leader與服務(wù)器2的心跳舊Leader恢復(fù)后發(fā)舊的Leader恢復(fù)后，進(jìn)入LOOKING狀態(tài)并發(fā)起新一 ，并將選票投給自己。此時服務(wù)器1會將自己的LEADING狀態(tài)選票（3,1,11）返回給服務(wù)器3，而服務(wù)器2將自己的FOLLOWING狀態(tài)及選票（3,1,11）返回給服務(wù)器3。如下圖所示Leader成為服務(wù)器3了解到Leader為服務(wù)器1，且根據(jù)選票了解到服務(wù)器1確實得到過半服務(wù)器的選票，因此自己進(jìn)入FOLLOWING狀態(tài)ZAB協(xié)議保證了在 的過程中，已經(jīng)被Commit的數(shù)據(jù)不會丟失，未被Commit的數(shù)據(jù)對客戶端不可見Failover前狀為更好演示LeaderFailover過程，本例中共使用5Zookeeper服務(wù)器。A作Leader，共收到P1、P2、P3三條消息，并且Commit12，且總體順序為P1、P2、C1、P3、C2。根據(jù)順序性原則，其它Follower收到的消息的順序肯定與之相同。其中B與A完全同步，C收到P1、P2、C1，D收到P1、P2，E收到P1，如下圖所示。這里要注由于A沒有C3，意味著收到P3的服務(wù)器的總個數(shù)不會超過一半，也即包含A在內(nèi)最多只有兩臺服務(wù)器收到P3。在這里A和B收到P3，其它服務(wù)器均未收到P3由于A已寫入C1、C2，說明它已經(jīng)CommitP1、P2，因此整個集群有超過一半的服務(wù)器，即最少三個服務(wù)器收到P1、P2。在這里所有服務(wù)器都收到了P1，除E外其它服務(wù)器也都收到了P2選出新Leader也即A宕機后，其它服務(wù)器根據(jù)上述FastLeaderElection算法選B作為新的Leader。C、DE成為Follower且以B為Leader后，會主動將自己最大的zxid發(fā)送給B，B會將Followerzxid與自身zxid間的所Commit過的消息同步給在上圖P1和P2都被ACommit，因此B會通過同步保證P1、P2、C1與C2都存在于C、D和EP3由于未被ACommit，同時幸存的所有服務(wù)器中P3未存在于大多數(shù)據(jù)服務(wù)器中，因此它不會被同步到其它通知Follower可對外服同步完數(shù)據(jù)后，B會向D、CE發(fā)NEWLEADER命令并等待大多數(shù)服務(wù)器的ACK（下圖DE已返回ACK，加上B自身，已經(jīng)占集群的大多數(shù)），然后向所有服務(wù)器廣播UPTODATE命令。收到該命令后的服務(wù)器即可對外提供服務(wù)。在上例中，P3未被ACommit過，同時因為沒有過半的服務(wù)器收到P3B也未CommitP3（如果有過半服務(wù)器收到P3，即使A未CommitP3，B會主動CommitP3，即C3），所以它不會將P3廣去。具體做法是，B在成為Leader后，先判斷自身未Commit的消息（本例中即P3）是否存在于大多數(shù)服務(wù)器中從而決定是否要將其Commit。然后B可得出自身所包含的被Commit過的消息中的最小zxid（記為min_zxid）與最大zxid（記為max_zxid