編輯導讀：本文轉(zhuǎn)載自淘寶核心系統(tǒng)運維團隊博客，文中描述的宕機檢測方式適用于大規(guī)模集群環(huán)境，但原理仍是基于雙節(jié)點，有需求的朋友們可以借鑒。

檢測一臺機器是否宕機的應用場景如下：

1, 工作機器宕機，總控節(jié)點需要能夠檢測到并且將原有服務遷移到集群中的其它節(jié)點。

2, 總控節(jié)點宕機，總控節(jié)點的備份節(jié)點（一般稱為Slave）需要能夠檢測到并替換成主節(jié)點繼續(xù)對外服務。

檢測一臺機器是否宕機必須是可靠的。在大規(guī)模集群中，機器可能出現(xiàn)各種異常，比如停電，磁盤故障，過于繁忙導致假死等。對于機器假死，如果總控節(jié)點認為機器宕機并將服務遷移到其它節(jié)點，假死的機器又認為自己還可以提供服務，則會出現(xiàn)多個節(jié)點服務同一份數(shù)據(jù)而導致數(shù)據(jù)不一致的情況。
 

首先必須明確，理論上檢測另外一臺機器是否宕機是無法做到的，有興趣的同學可以參考Fischer的論文?？梢院唵卫斫馊缦拢篈機器往B機器發(fā)送心跳包，如果B機器不發(fā)送響應，A無法確定B機器是宕機了還是過于繁忙，由于A和B兩臺機器的時鐘可能不同步，B機器也無法確定多久沒有收到A機器的心跳包可以認為必須停止服務。因此，A機器沒有辦法確定B機器已經(jīng)宕機或者采取措施強制B機器停止服務。

當然，工程實踐中，由于機器之間會進行時鐘同步，我們總是假設A和B兩臺機器的本地時鐘相差不大，比如相差不超過0.5秒。這樣，我們可以通過Lease機制進行宕機檢測。Lease機制就是帶有超時時間的一種授權(quán)。假設總控節(jié)點需要檢測工作節(jié)點是否宕機，總控節(jié)點可以給工作節(jié)點發(fā)放Lease授權(quán)，工作節(jié)點持有有效期內(nèi)的Lease才允許提供服務，否則主動下線停止服務。工作節(jié)點的Lease快要到期的時候向總控節(jié)點重新申請Lease（一般稱為renewLease），總控節(jié)點定時檢測所有工作機的Lease授權(quán)是否合法，如果發(fā)現(xiàn)某臺工作機Lease失效，可以將工作機上的服務遷移到集群中的其它機器，這時因為工作機發(fā)現(xiàn)自己Lease失效會主動停止服務。當然，這里需要注意，由于總控節(jié)點和工作機的時鐘可能不一致且有網(wǎng)絡延遲，總控節(jié)點上的Lease超時時間要長，也就是說，如果工作節(jié)點的Lease超時時間是12秒，總控節(jié)點可能需要13秒后才能確認工作節(jié)點已經(jīng)停止了服務，從而避免數(shù)據(jù)不一致問題。

同構(gòu)節(jié)點之間的選主也有一個宕機檢測問題。比如總控節(jié)點宕機，備份節(jié)點需要能夠檢測并升級為主節(jié)點繼續(xù)對外服務。Mysql數(shù)據(jù)庫經(jīng)常采用Heartbeat + DRBD (Distributed Replicated Block Device) + Mysql的高可用性方案，據(jù)說能夠達到3個9的高可用性，主節(jié)點和備節(jié)點維持Heartbeat心跳，當提供服務的主節(jié)點出現(xiàn)故障時，備節(jié)點的Heartbeat檢測到主節(jié)點沒有心跳（例如，Ping不通主節(jié)點），備節(jié)點自動接管虛擬IP，升級為主節(jié)點提供Mysql讀寫服務。由于Heartbeat檢測機器主節(jié)點宕機不可靠，這個方案存在眾所周知的腦裂問題，即集群中可能同時存在多個主節(jié)點同時提供服務。解決這個問題本質(zhì)上還是需要引入仲裁節(jié)點，比如Heartbeat + DRBD方案中引入Fence節(jié)點使出現(xiàn)問題的節(jié)點從集群中脫離，或者引入分布式鎖服務，比如Chubby的開源實現(xiàn)Zookeeper服務。分布式鎖服務實現(xiàn)主節(jié)點選舉大致如下：主節(jié)點和備節(jié)點到Chubby中搶鎖，搶到鎖的節(jié)點在鎖的有效期(Lease期)內(nèi)提供服務，當主節(jié)點鎖的Lease快要到期時，主節(jié)點申請延長鎖的超時時間，正常情況下分布式鎖服務總是優(yōu)先滿足主節(jié)點的請求，當主節(jié)點出現(xiàn)故障時，備節(jié)點能夠搶到鎖切換為主節(jié)點提供服務。

***還有一個問題，假設總控節(jié)點通過Lease機制檢測工作節(jié)點是否宕機，這種方案是可靠的，不過當總控節(jié)點宕機時，如果不采取任何措施，集群中的所有工作節(jié)點都將因為無法重新申請Lease而停止服務，這就是帶有總控節(jié)點的設計固有的脆弱性，某個設計或者編碼的錯誤都有可能造成嚴重的影響。解決這個問題一般會有一個叫做Grace Period的機制，工作節(jié)點Lease超時時將停止服務，但是工作節(jié)點并不一開始就重啟或者下線，而是處于一種危險狀態(tài)(稱為Jeopardy)，這種狀態(tài)持續(xù)一個Grace Period，比如45秒。如果在Grace Period 內(nèi)總控節(jié)點重啟，工作節(jié)點和總控節(jié)點重新聯(lián)系上從而可以切換為正常狀態(tài)繼續(xù)提供服務。

如果需要較好地理解宕機及選舉相關的問題，可以閱讀并思考Paxos相關的論文，比如Paxos made simple, The Part-time Parliament, Paxos made live, Paxos made practical, Chubby等。有任何問題，歡迎討論。