作者：寶爺 校對：DJ

1、緒論

etcd作為華為云PaaS的核心部件，實現(xiàn)了PaaS大多數(shù)組件的數(shù)據(jù)持久化、集群選舉、狀態(tài)同步等功能。如此重要的一個部件，我們只有深入地理解其架構(gòu)設(shè)計和內(nèi)部工作機制，才能更好地學(xué)習(xí)華為云Kubernetes容器技術(shù)，笑傲云原生的“江湖”。本系列將從整體框架再細(xì)化到內(nèi)部流程，對etcd的代碼和設(shè)計進(jìn)行全方位解讀。本文是《深入淺出etcd》系列的第二篇，重點解析etcd的心跳和選舉機制，下文所用到的代碼均基于etcd v3.2.X版本。

另，由華為云容器服務(wù)團(tuán)隊傾情打造的《云原生分布式存儲基石：etcd深入解析》一書已正式出版，各大平臺均有發(fā)售，購書可了解更多關(guān)于分布式存儲和etcd的相關(guān)內(nèi)容！

?

2、什么是etcd的選舉

選舉是raft共識協(xié)議的重要組成部分，重要的功能都將是由選舉出的leader完成。不像Paxos，選舉對Paxos只是性能優(yōu)化的一種方式。選舉是raft集群啟動后的第一件事，沒有l(wèi)eader，集群將不允許任何的數(shù)據(jù)更新操作。選舉完成以后，集群會通過心跳的方式維持leader的地位，一旦leader失效，會有新的follower起來競選leader。

?

3、etcd選舉詳細(xì)流程

選舉的發(fā)起，一般是從Follower檢測到心跳超時開始的，v3支持客戶端指定某個節(jié)點強行開始選舉。選舉的過程其實很簡單，就是一個candidate廣播選舉請求，如果收到多數(shù)節(jié)點同意就把自己狀態(tài)變成leader。下圖是選舉和心跳的詳細(xì)處理流程。我們將在下文詳細(xì)描述這個圖中的每個步驟。

3.1 tick

raftNode的創(chuàng)建函數(shù)newRaftNode會創(chuàng)建一個Ticker。傳入的heartbeat默認(rèn)為100ms，可以通過--heartbeat-interval配置。?

這里要介紹一下代碼中出現(xiàn)的幾個變量，我把這幾個變量都翻譯成XXX計數(shù)，是因為這些值都是整數(shù)，初始化為0，每次tick完了以后會遞增1。因此實際這是一個計數(shù)。也就是說實際的時間是這個計數(shù)值乘以tick的時間。

1.?選舉過期計數(shù)(electionElapsed)：主要用于follower來判斷l(xiāng)eader是不是正常工作，如果這個值遞增到大于隨機化選舉超時計數(shù)(randomizedElectionTimeout)，follower就認(rèn)為leader已掛，它自己會開始競選leader。

2.?心跳過期計數(shù)(heartbeatElapsed)：用于leader判斷是不是要開始發(fā)送心跳了。只要這個值超過或等于心跳超時計數(shù)(heartbeatTimeout)，就會觸發(fā)leader廣播heartbeat信息。?

3.?心跳超時計數(shù)(heartbeatTimeout)：心跳超時時間和tick時間的比值。當(dāng)前代碼中是寫死的1。也就是每次tick都應(yīng)該發(fā)送心跳。實際上tick的周期就是通過--heartbeat-interval來配置的。?

4.?隨機化選舉超時計數(shù)(randomizedElectionTimeout)：這個值是一個每次任期都不一樣的隨機值，主要是為了避免分裂選舉的問題引入的隨機化方案。這個時間隨機化以后，每個競選者發(fā)送的競選消息的時間就會錯開，避免了同時多個節(jié)點同時競選。從代碼中可以看到，它的值是[electiontimeout, 2*electiontimeout-1] 之間，而electionTimeout就是下圖中的ElectionTicks，是ElectionMs相對于TickMs的倍數(shù)。ElectionMs是由--election-timeout來配置的，TickMs就是--heartbeat-interval。?

raftNode的start()方法啟動的協(xié)程中，會監(jiān)聽ticker的channel，調(diào)用node的Tick方法，該方法往tickc通道中推入一個空對象。（流程圖中1）?

node啟動時是啟動了一個協(xié)程，處理node的里的多個通道，包括tickc，調(diào)用tick()方法。該方法會動態(tài)改變，對于follower和candidate，它就是tickElection，對于leader和，它就是tickHeartbeat。tick就像是一個etcd節(jié)點的心臟跳動，在follower這里，每次tick會去檢查是不是leader的心跳是不是超時了。對于leader，每次tick都會檢查是不是要發(fā)送心跳了。

3.2 發(fā)送心跳

當(dāng)集群已經(jīng)產(chǎn)生了leader，則leader會在固定間隔內(nèi)給所有節(jié)點發(fā)送心跳。其他節(jié)點收到心跳以后重置心跳等待時間，只要心跳等待不超時，follower的狀態(tài)就不會改變。?具體的過程如下：

1.?對于leader，tick被設(shè)置為tickHeartbeat，tickHeartbeat會產(chǎn)生增長遞增心跳過期時間計數(shù)(heartbeatElapsed)，如果心跳過期時間超過了心跳超時時間計數(shù)(heartbeatTimeout)，它會產(chǎn)生一個MsgBeat消息。心跳超時時間計數(shù)是系統(tǒng)設(shè)置死的，就是1。也就是說只要1次tick時間過去，基本上會發(fā)送心跳消息。發(fā)送心跳首先是調(diào)用狀態(tài)機的step方法。(流程圖中2)?

2.?step在leader狀態(tài)下為stepLeader()，當(dāng)收到MsgBeat時，它會調(diào)用bcastHeartbeat()廣播MsgHeartbeat消息。構(gòu)造MsgHeartbeat類型消息時，需要在Commit字段填入當(dāng)前已經(jīng)可以commit的消息index，如果該index大于peer中記錄的對端節(jié)點已經(jīng)同步的日志index，則采用對端已經(jīng)同步的日志index。Commit字段的作用將在接收端處理消息時詳細(xì)介紹。(流程圖中3)

3.?send方法將消息append到msgs數(shù)組中。(流程圖中4)

4.?node啟動的協(xié)程會收集msgs中的消息，連同當(dāng)前未持久化的日志條目、已經(jīng)確定可以commit的日志條目、變化了的softState、變化了的hardState、readstate一起打包到Ready數(shù)據(jù)結(jié)構(gòu)中。這些都是會引起狀態(tài)機變化的，所以都封裝在一個叫Ready的結(jié)構(gòu)中，意思是這些東西都已經(jīng)沒問題了，該持久化的持久化，該發(fā)送的發(fā)送。(流程圖中5)

5.?還是raftNode.start()啟動的那個協(xié)程，處理readyc通道。如果是leader，會在持久化日志之前發(fā)送消息，如果不是leader，則會在持久化日志完成以后發(fā)送消息。(流程圖中6)

?

6.?transport的Send一般情況下都是調(diào)用其內(nèi)部的peer的send()方法發(fā)送消息。peer的send()方法則是將消息推送到streamWriter的msgc通道中。

7.?streamWriter有一個協(xié)程處理msgc通道，調(diào)用encode，使用protobuf將Message序列化為bytes數(shù)組，寫入到連接的IO通道中。(流程圖中7)

8.?對方的節(jié)點有streamReader會接收消息，并反序列化為Message對象。然后將消息推送到peer的recvc或者propc通道中。(流程圖中8)

9.?peer啟動時啟動了兩個協(xié)程，分別處理recvc和propc通道。調(diào)用Raft.Process處理消息。EtcdServer是這個接口的實現(xiàn)。(流程圖中9)

10.?EtcdServer判斷消息來源的節(jié)點是否被刪除，沒有的話調(diào)用Step方法，傳入消息，執(zhí)行狀態(tài)機的步進(jìn)。而接收heartbeat的節(jié)點狀態(tài)機正常情況下都是follower狀態(tài)。因此就是調(diào)用stepFollower進(jìn)行步進(jìn)。(流程圖中10)

follower對heatbeat消息的處理是：先將選舉過期時間計數(shù)(electionElapsed)歸零。這個時間會在每次tickElection調(diào)用時遞增。如果到了electionTimeout，就會重新選舉。另外，我們還可以看到這里handleHeartbeat中，會將本地日志的commit值設(shè)置為消息中帶的Commit。這就是第2步說到設(shè)置Commit的目的，heartbeat消息還會把leader的commit值同步到follower。同時，leader在設(shè)置消息的Commit時，是取它對端已經(jīng)同步的日志最新index和它自己的commit值中間較小的那個，這樣可以保證如果有節(jié)點同步比較慢，也不會把commit值設(shè)置成了它還沒同步到的日志。

最后，follower處理完以后會回復(fù)一個MsgHeartbeatResp消息。

11.?回復(fù)消息的中間處理流程和心跳消息的處理一致，因此不再贅述。leader收到回復(fù)消息以后，最后會調(diào)用stepLeader處理回復(fù)消息。(流程圖中11)

12.?stepLeader收到回復(fù)消息以后，會判斷是不是要繼續(xù)同步日志，如果是，就發(fā)送日志同步信息。另外會處理讀請求，這部分的處理將在linearizable讀請求的流程中詳細(xì)解讀。

3.3 選舉

檢測到選舉超時的follower，會觸發(fā)選舉流程，具體的流程如下：

1.?依然從tick開始，對于follower(或candidate)。tick就是tickElection，它的做法是，首先遞增選舉過期計數(shù)(electionElapsed)，如果選舉過期計數(shù)超過了選舉超時計數(shù)。則開始發(fā)起選舉。發(fā)起選舉的話，實際是創(chuàng)建一個MsgHup消息調(diào)用狀態(tài)機的Step方法。(流程圖中13)

2.?Step方法處理MsgHup消息，查看當(dāng)前本地消息中有沒有沒有作用到狀態(tài)機的配置信息日志，如果有的話，是不能競選的，因為集群的配置信息有可能會出現(xiàn)增刪節(jié)點的情況，需要保證各節(jié)點都起作用以后才能進(jìn)行選舉操作。從圖上可以看到，如果有PreVote的配置，會有一個PreElection的分支。這個放在最后我們介紹。我們直接看campaign()方法，它首先將自己變成candidate狀態(tài)，becomeCandidate會將自己Term+1。然后拿到自己當(dāng)前最新的日志Term和index值。把這些都包在一個MsgVote消息中，廣播給所有的節(jié)點。最新的日志Term和index值是非常重要的，它能保證新選出來的leader中一定包含之前已經(jīng)commit的日志，不會讓已經(jīng)commit的日志被新leader改寫。這個在后面的流程中還會講到。(流程圖中14)

3.?選舉消息發(fā)送的流程和所有消息的流程一樣，不在贅述。(流程圖中15)

4.?心跳消息到了對端節(jié)點以后，進(jìn)行相應(yīng)的處理，最終會調(diào)到Step方法，進(jìn)行狀態(tài)機步進(jìn)。Step處理MsgVote方法的流程是這樣的：

? ? - 首先，如果選舉過期時間還沒有超時，將拒絕這次選舉請求。這是為了防止有些follower自己的原因沒收到leader的心跳擅自發(fā)起選舉。

? ? - 如果r.Vote已經(jīng)設(shè)置了，也就是說在一個任期中已經(jīng)同意了某個節(jié)點的選舉請求，就會拒絕選舉

? ? - 如果根據(jù)消息中的LogTerm和Index，也就是第2步傳進(jìn)來的競選者的最新日志的index和term，發(fā)現(xiàn)競選者比當(dāng)前節(jié)點的日志要舊，則拒絕選舉。

? ? - 其他情況則贊成選舉。回復(fù)一個贊成的消息。(流程圖中16)

5.?競選者收到MsgVoteResp消息以后，stepCandidate處理該消息，首先更新r.votes。r.votes是保存了選票信息。如果同意票超過半數(shù)，則升級為leader，否則如果已經(jīng)獲得超過半數(shù)的反對票，則變成follower。(流程圖中18)

?

4、PreVote

PreVote是解決因為某個因為網(wǎng)絡(luò)分區(qū)而失效的節(jié)點重新加入集群以后，會導(dǎo)致集群重新選舉的問題。問題出現(xiàn)的過程是這樣的，假設(shè)當(dāng)前集群的Term是1，其中一個節(jié)點，比如A，它因為網(wǎng)絡(luò)分區(qū)，接收不到leader的心跳，當(dāng)超過選舉超時時間以后，它會將自己變成Candidate，這時候它會把它的Term值變成2，然后開始競選。當(dāng)然這時候是不可能競選成功的。可是當(dāng)網(wǎng)絡(luò)修復(fù)以后，無論是它的競選消息，還是其他的回復(fù)消息，都會帶上它的Term，也就是2。而這時候整個集群里其他機器的Term還是1，這時候的leader發(fā)現(xiàn)已經(jīng)有比自己Term高的節(jié)點存在，它就自己乖乖降級為follower，這樣就會導(dǎo)致一次重新選舉。這種現(xiàn)象本身布常見，而且出現(xiàn)了也只是出現(xiàn)一次重選舉，對整個集群的影響并不大。但是如果希望避免這種情況發(fā)生，依然是有辦法的，辦法就是PreVote。

PreVote的做法是：當(dāng)集群中的某個follower發(fā)現(xiàn)自己已經(jīng)在選舉超時時間內(nèi)沒收到leader的心跳了，這時候它首先不是直接變成candidate，也就不會將Term自增1。而是引入一個新的環(huán)境叫PreVote，我們就將它稱為預(yù)選舉吧。它會先廣播發(fā)送一個PreVote消息，其他節(jié)點如果正常運行，就回復(fù)一個反對預(yù)選舉的消息，其他節(jié)點如果也失去了leader，才會有回復(fù)贊成的消息。節(jié)點只有收到超過半數(shù)的預(yù)選舉選票，才會將自己變成candidate，發(fā)起選舉。這樣，如果是這個單個節(jié)點的網(wǎng)絡(luò)有問題，它不會貿(mào)然自增Term，因此當(dāng)它重新加入集群時。也不會對現(xiàn)任leader地位有任何沖擊。保證了系統(tǒng)更穩(wěn)定的方式運行。

?

5、如何保證已經(jīng)commit的數(shù)據(jù)不會被改寫？

etcd集群的leader會一直向follower同步自己的日志，如果follower發(fā)現(xiàn)自己的日志和leader不一致，會刪除它本地的不一致的日志，保證和leader同步。

leader在運行過程中，會檢查同步日志的回復(fù)消息，如果發(fā)現(xiàn)一條日志已經(jīng)被超過半數(shù)的節(jié)點同步，則把這條日志記為committed。隨后會進(jìn)行apply動作，持久化日志，改變kv存儲。

我們現(xiàn)在設(shè)想這么一個場景：一個集群運行過程中，leader突然掛了，這時候就有新的follower競選leader。如果新上來的leader日志是比較老的，那么在同步日志的時候，其他節(jié)點就會刪除比這個節(jié)點新的日志。要命的是，如果這些新的日志有的是已經(jīng)提交了的。那么就違反了已經(jīng)提交的日志不能被修改的原則了。

怎么避免這種事情發(fā)生呢？這就涉及到剛才選舉流程中一個動作，candidate在發(fā)起選舉的時候會加上當(dāng)前自己的最新的日志index和term。follower收到選舉消息時，會根據(jù)這兩個字段的信息，判斷這個競選者的日志是不是比自己新，如果是，則贊成選舉，否則投反對票。

為什么這樣可以保證已經(jīng)commit的日志不會被改寫呢？因為這個機制可以保證選舉出來的leader本地已經(jīng)有已經(jīng)commit的日志了。

為什么這樣就能保證新leader本地有已經(jīng)commit的日志呢？

因為我們剛才說到，只有超過半數(shù)節(jié)點同步的日志，才會被leader commit，而candidate要想獲得半數(shù)以上的選票，日志就一定要比半數(shù)以上的節(jié)點新。這樣兩個半數(shù)以上的群體里交集中，一定至少存在一個節(jié)點。這個節(jié)點的日志肯定被commit了。因此我們只要保證競選者的日志被大多數(shù)節(jié)點新，就能保證新的leader不會改寫已經(jīng)commit的日志。

簡單來說，這種機制可以保證下圖的b和e肯定選不leader。

?

?

6、頻繁重選舉的問題

如果etcd頻繁出現(xiàn)重新選舉，會導(dǎo)致系統(tǒng)長時間處于不可用狀態(tài)，大大降低了系統(tǒng)的可用性。

什么原因會導(dǎo)致系統(tǒng)重新選舉呢？

1. 網(wǎng)絡(luò)時延和網(wǎng)絡(luò)擁塞：從心跳發(fā)送的流程可以看到，心跳消息和其他消息一樣都是先放到Ready結(jié)構(gòu)的msgs數(shù)組中。然后逐條發(fā)送出去，對不同的節(jié)點，消息發(fā)送不會阻塞。但是對相同的節(jié)點，是一個協(xié)程來處理它的msgc通道的。也就是說如果有網(wǎng)絡(luò)擁塞，是有可能出現(xiàn)其他的消息擁塞通道，導(dǎo)致心跳消息不能及時發(fā)送的。即使只有心跳消息，擁塞引起信道帶寬過小，也會導(dǎo)致這條心跳消息長時間不能到達(dá)對端。也會導(dǎo)致心跳超時。另外網(wǎng)絡(luò)延時會導(dǎo)致消息發(fā)送時間過程，也會引起心跳超時。另外，peer之間通信建鏈的超時時間設(shè)置為1s+(選舉超時時間)*1/5 。也就是說如果選舉超時設(shè)置為5s，那么建鏈時間必須小于2s。在網(wǎng)絡(luò)擁塞的環(huán)境下，這也會影響消息的正常發(fā)送。

2. IO延時：從apply的流程可以看到，發(fā)送msg以后，leader會開始持久化已經(jīng)commit的日志或者snapshot。這個過程會阻塞這個協(xié)程的調(diào)用。如果這個過程阻塞時間過長，就會導(dǎo)致后面的msgs堵在那里不能及時發(fā)送。根據(jù)官網(wǎng)的解釋，etcd是故意這么做的，這樣可以讓那些io有問題的leader自動失去leader地位。讓io正常的節(jié)點選上leader。但是如果整個集群的節(jié)點io都有問題，就會導(dǎo)致整個集群不穩(wěn)定。

?

轉(zhuǎn)載于:https://www.cnblogs.com/huaweiyuncce/p/10130522.html

總結(jié)

以上是生活随笔為你收集整理的深入浅出etcd系列 – 心跳和选举的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。