在高可用分布式系统中，故障检测是确保系统可靠性和连续性的核心机制。其中，心跳（Heartbeat）机制作为一种经典的低延迟故障检测方法，被广泛应用于 leader 选举、租约续约和节点健康监控。本文聚焦于使用 TCP 和 UDP 协议实现低延迟心跳的工程实践，分析其优缺点，并提供可落地的参数配置和监控清单，帮助工程师在实际部署中优化系统性能。
心跳机制的核心在于节点间定期交换简短消息，以确认彼此的存活状态。在分布式系统中，如 Raft 或 ZooKeeper 等共识协议中，领导者（Leader）节点每隔固定间隔向跟随者（Follower）发送心跳包。如果跟随者未在超时时间内收到心跳，则触发故障检测流程，可能导致领导者选举或服务切换。这种机制的优势在于简单高效，能在毫秒级响应故障，但也面临网络延迟、丢包和带宽消耗等挑战。
选择 TCP 或 UDP 作为心跳传输协议是工程决策的关键。TCP 提供可靠传输，通过连接保持和重传机制确保心跳包不丢失，适合对准确性要求高的场景，如小规模集群的领导者选举。然而，TCP 的三次握手和拥塞控制引入额外延迟，在高并发环境下可能导致心跳间隔不稳定。根据 Raft 协议的实践 [1]，TCP 心跳的典型延迟为 10-50ms，但开销较高，尤其在频繁重连时。
相比之下，UDP 作为无连接协议，具有更低的延迟和开销，仅需发送数据报即可，适合低延迟需求高的场景，如大规模分布式系统的故障检测。在 UDP 心跳中，节点无需维护连接状态，发送间隔可控制在 50ms 以内，实现亚毫秒级响应。但 UDP 不保证交付，需通过冗余发送或序列号检测丢包。例如，在 Akka 框架中，UDP 心跳结合 Phi Accrual 失效检测器，能有效处理网络抖动，误报率控制在 1% 以下。
在实际工程中，低延迟心跳的实现需平衡检测速度与误报风险。观点一：心跳间隔应大于网络往返时间（RTT）的 5-10 倍，以容忍正常延迟；超时阈值则设置为心跳间隔的 3-5 倍，避免假阳性。证据显示，在数据中心环境中，RTT 通常为 0.2-1ms，因此心跳间隔可设为 100ms，超时为 500ms。这在 Cassandra 的 gossip 协议中得到验证，能在 1s 内检测 99% 的真实故障。
对于租约续约（Lease Renewal），心跳可扩展为携带租约信息。领导者发放短期租约（e.g., 10s），跟随者通过心跳响应续约。如果续约失败，跟随者停止服务，防止脑裂（Split-Brain）。使用 UDP 时，需添加时间戳和 HMAC 签名验证消息完整性，确保低延迟下安全。参数建议：租约有效期 = 心跳间隔 × 10，续约窗口 = 租约期 80%。这在 etcd 的 watch 机制中应用，实现了高效的资源锁定。
领导者选举（Leader Election）是心跳机制的典型应用。在 Raft 中，心跳超时触发选举超时（Election Timeout），随机化在 150-300ms 范围内，防止选举风暴。使用 TCP 时，选举过程可靠但启动慢；UDP 则更快，但需多轮投票确认。工程清单：1) 初始化所有节点为 Follower；2) 超时后转为 Candidate，自投一票并广播 RequestVote；3) 获多数票（N/2 +1）后成为 Leader，立即发送心跳维持权威；4) 集成世代时钟（Epoch）检测过时领导者。
可落地参数配置如下：
- 心跳间隔：TCP 100ms，UDP 50ms（基于 RTT 测量）。
- 超时阈值：心跳间隔 × 5，自适应调整（使用 EWMA 算法跟踪延迟）。
- 缓冲区大小：UDP 包 64 字节（仅含时间戳、节点 ID 和 CRC）。
- 重传策略：UDP 每间隔 2 次发送冗余包，TTL 3 次。
- 监控点：心跳延迟 P99 < 10ms，误报率 < 0.1%，带宽 < 1KB/s/ 节点。
- 回滚策略：检测误报后，延长超时 20%，日志记录异常事件。
风险与限制：一是网络分区导致的延迟放大，解决方案为多路径路由或 gossip 扩散心跳；二是 GC 暂停影响发送，建议异步线程池隔离心跳任务。大型集群中，纯心跳易耗带宽，推荐结合 SWIM 协议的间接 ping 优化。
总之，低延迟心跳机制通过 TCP/UDP 的权衡，能显著提升分布式系统的可用性。工程师在部署时，应通过压测验证参数，并在 Prometheus 等工具中监控指标，实现 proactive 故障管理。
资料来源： [1] Ongaro, D., & Ousterhout, J. (2014). In Search of an Understandable Consensus Algorithm. USENIX ATC. [2] 分布式系统模式：心跳，https://zhuanlan.zhihu.com/p/700202785