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

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

2, 總控節點宕機，總控節點的備份節點（一般稱為Slave）需要能夠檢測到並替換成主節點繼續對外服務。 　　檢測一臺機器是否宕機必須是可靠的。在大規模叢集中，機器可能出現各種異常，比如停電，磁碟故障，過於繁忙導致假死等。對於機器假死，如果總控節點認為機器宕機並將服務遷移到其它節點，假死的機器又認為自己還可以提供服務，則會出現多個節點服務同一份資料而導致資料不一致的情況。 　　 　　首先必須明確，理論上檢測另外一臺機器是否宕機是無法做到的，有興趣的同學可以參考Fischer的論文。可以簡單理解如下：A機器往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機制檢測工作節點是否宕機，這種方案是可靠的，不過當總控節點宕機時，如果不採取任何措施，叢集中的所有工作節點都將因為

我用的喵提醒，他的vip會員有個keepalive提醒服務，你給他定時發心跳就可以了，不需要自己又準備一臺監控機。