前言

在现代分布式系统中，故障检测 是系统高可用的基础能力。系统需要实时感知某个节点是否还“存活”，以便及时做出容错或主备切换。这一机制中，Heartbeat（心跳） 是最核心的技术手段。

无论是集群成员管理、主从选举、服务注册发现，还是负载均衡，heartbeat 都是系统健康监控的“生命信号”。

定义

Wiki 对 Heartbeat 的定义如下：

A heartbeat is a periodic signal generated by hardware or software to indicate normal operation or to synchronize other parts of a system.

一句话：Heartbeat 就是系统之间周期性发送的“我还活着”的信号。

工作原理

一句话：各个节点定期发送 heartbeat（心跳包），接收方通过超时时间判断该节点是否存活。

一个典型的 Heartbeat 流程：

  1. 每个节点周期性（如每 1~5 秒）发送 heartbeat；
  2. 接收方记录上次收到 heartbeat 的时间；
  3. 如果超过超时时间（如 10 秒）仍未收到新的 heartbeat，即认为该节点“已失联”；
  4. 上报给集群管理模块，触发 failover 或重试机制。

Heartbeat 的核心目标：检测节点的生死状态。

属性与指标

Heartbeat 系统的关键属性包括：

  1. 发送周期（interval） 心跳发送的时间间隔，太频繁会加重网络负担，太慢会降低检测精度。

  2. 超时时间（timeout） 接收方等待多长时间未收到心跳才判断对方故障。

  3. 抖动（jitter）机制 防止大量节点在同一时间发送心跳造成瞬时冲击。

  4. 失效策略 超时后是立即摘除节点、降级服务，还是等待人工干预。

  5. false positive rate 心跳丢包不一定等于节点故障，需避免误判。

  6. 可扩展性 大规模系统中是否支持万级节点心跳采集。

类型

按方向分

  1. 主动上报型（Push） 每个节点主动向中心发出 heartbeat，如 etcd、Zookeeper。

  2. 轮询检测型（Pull） 管理节点周期性 ping 所有节点，如 Consul、Nagios。

按角色分

  1. 客户端心跳（client-to-server） 客户端定期 ping 服务端，保证连接不中断。

  2. 服务端心跳（server-to-client） 服务端定期 ping 客户端，用于连接保活。

  3. 节点互相心跳（peer-to-peer） 节点间直接互相监测，如 gossip 协议。

Heartbeat 与程序关系

Heartbeat 机制常见于以下场景中：

  1. 主从节点监控 主节点失联后，触发主备切换，如 Redis Sentinel、MongoDB。

  2. 服务注册中心 节点失联后自动从服务发现中剔除，如 Eureka、Consul。

  3. 分布式协调系统 Raft、Zookeeper、Paxos 等协议均依赖心跳维持领导权。

  4. 容器编排调度系统 Kubernetes node 使用 kubelet 向 apiserver 上报状态。

  5. 连接保活 TCP 长连接中常用 heartbeat 探测断链，如 WebSocket ping/pong。

开发时需要注意：

  • 心跳发送需异步、低延迟、不可阻塞主逻辑；
  • 推荐加入 jitter 抖动；
  • 配合 retry 和 fencing 机制，避免误判引发 Split Brain；
  • 对频繁 false positive 的系统要适度容忍丢包。

常用 Heartbeat 框架或实现

系统/协议 Heartbeat 用途 检测方式
Zookeeper 节点存活、主选举 Server pull + ping
etcd 保持 session、选主 Client push
Redis Sentinel 主从切换 ping master/slave
Kubernetes 节点存活检测 kubelet → apiserver
Consul 服务健康检查 health check + TTL
WebSocket 保持长连接 ping/pong packet
MySQL Group Replication 节点连接状态 metadata heartbeat