检测一台机器是否宕机的应用场景如下：

1, 工作机器宕机，总控节点需要能够检测到并且将原有服务迁移到集群中的其它节点。

2, 总控节点宕机，总控节点的备份节点（一般称为Slave）需要能够检测到并替换成主节点继续对外服务。

检测一台机器是否宕机必须是可靠的。在大规模集群中，机器可能出现各种异常，比如停电，磁盘故障，过于繁忙导致假死等。对于机器假死，如果总控节点认为机器宕机并将服务迁移到其它节点，假死的机器又认为自己还可以提供服务，则会出现多个节点服务同一份数据而导致数据不一致的情况。

首先必须明确，理论上检测另外一台机器是否宕机是无法做到的，有兴趣的同学可以参考。可以简单理解如下：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机制检测工作节点是否宕机，这种方案是可靠的，不过当总控节点宕机时，如果不采取任何措施，集群中的所有工作节点都将因为无法重新申请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等。有任何问题，欢迎讨论。