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

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

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

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

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

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

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

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

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

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