心跳检测仅为仲裁提供在线状态输入，不直接仲裁；真正仲裁需多数派投票、共享存储锁或外部共识服务等机制实现。
心跳检测本身不直接实现仲裁，而是为仲裁提供基础状态输入；真正的仲裁机制需要额外设计，比如多数派投票、共享存储锁或外部共识服务。
心跳是状态感知，不是决策主体
心跳只回答“这个节点是否还在线”这一问题，但它无法判断“该节点是否可信”或“多个节点谁该继续提供服务”。例如：当主节点网络短暂中断但进程仍在运行时，心跳会超时，备节点可能误判并抢主——这就是脑裂。所以必须引入仲裁来打破平局。
常见心跳仲裁实现方式
以下三种方案在生产环境中被广泛采用，可根据集群规模和一致性要求选择：
- 多数节点投票（Quorum）：适用于3节点及以上集群。只有获得超过半数节点确认的提议才能生效。例如5节点集群中，至少3个节点同意切换，才允许备节点接管VIP和服务。
- 共享存储锁 + 心跳联合校验：主节点需持续持有共享磁盘上的独占锁（如fencing lock），同时维持心跳。一旦心跳失败且锁释放失败，备节点通过STONITH强制重启原主节点，再获取锁并启动服务。
- 外部仲裁服务（etcd / ZooKeeper / Consul）：所有节点向一个高可用的协调服务注册心跳并读取主节点租约。主节点需定期续租（类似心跳），租约过期后协调服务自动触发选举，其他节点监听变更事件执行接管。
关键配置与防错要点
无论采用哪种仲裁方式，都需配合以下实践避免误判和雪崩：
- 心跳间隔与超时时间要合理：建议心跳周期设为1秒，超时设为3～5秒，避免网络抖动引发频繁切换。
- 启用时钟同步（NTP）：所有节点时间偏差需控制在50ms内，否则租约和超时逻辑会失效。
- 区分网络层与应用层心跳：仅靠ICMP ping不够，应叠加端口连通性、进程存活、服务响应等多维度探测。
- 仲裁节点自身必须高可用：若用etcd做仲裁，它本身也应是3或5节点集群，不能单点部署。
实际组合示例：Heartbeat + VIP + etcd仲裁
以HAProxy负载均衡集群为例：
- 两台服务器运行Heartbeat，各自监控本地HAProxy进程和80端口响应；
- 两者均向etcd写入带TTL的key（如/ha/leader），值为主机名；
- Heartbeat主模块不直接决定主备，而是监听etcd中该key的变更；
- 当etcd中key消失，剩余节点竞争写入，成功者触发VIP绑定和HAProxy启动。
这种设计把“状态上报”交给心跳，“决策权”交给etcd，既解耦又可靠。
