心跳检测本质是维持租约存活的持续在线证明，通过周期性KeepAlive请求刷新TTL，确保分布式锁不被误释放或Raft Leader身份不被误撤销，同时需平衡间隔与容忍窗口以抗网络抖动。
心跳检测在分布式锁和选主过程中，本质是维持租约存活的“持续在线证明”。它不是简单地发个 ping，而是与租约（Lease）深度绑定，让服务端能可靠判断客户端是否真实可用。
租约是心跳的载体，不是替代品
etcd 中的租约（Lease）本身不主动探测客户端，而是依赖客户端定期发起 KeepAlive 请求来续期。这个请求就是心跳——每次成功响应，就等同于告诉 etcd：“我还活着，把我的租约 TTL 重置为原始值”。一旦心跳中断（比如客户端崩溃、网络断开、GC 停顿过长），租约会在 TTL 到期后自动失效，关联的锁 Key 被删除，或选主时的临时节点被清理。
- 租约创建时指定 TTL（如 10 秒），这是心跳失败后的最大容忍窗口
- 客户端必须启动一个后台 goroutine 或线程，持续调用
KeepAlive()并处理返回的KeepAliveResponse - 不能只靠单次心跳；必须形成稳定周期（例如每 3 秒发一次），且间隔远小于 TTL，留出容错余量
在分布式锁中，心跳防止业务未完成就丢锁
如果业务逻辑耗时较长（比如上传大文件、批量计算），而租约 TTL 又设得太短，容易出现“锁被提前释放→其他客户端抢入→数据冲突”的问题。心跳续约正是为解决这个矛盾：
- 加锁时申请租约，并立即启动 KeepAlive 流程
- 业务执行期间，心跳持续刷新租约，保证锁一直有效
- 业务结束前主动释放锁（
Delete+Revoke），或依靠 defer 确保异常退出时也能清理 - 注意：KeepAlive 响应可能延迟或丢失，客户端需监听 channel 关闭并做兜底（如主动 Revoke 后重试）
在 Raft 选主中，心跳是 Leader 自证身份的核心手段
Raft 的 Leader 不是靠“投票结果存档”长期有效的，而是靠持续向 Follower 发送心跳（AppendEntries RPC）来维持任期权威。这和 etcd 租约心跳逻辑一致，只是协议层不同：
- Leader 每隔固定时间（如 100ms）向所有 Follower 发送空日志条目的 AppendEntries 请求
- Follower 收到后重置自己的选举超时计时器，表示“我看到 Leader 还在”
- 若连续多个心跳周期没收到请求，Follower 认定 Leader 失联，转为 Candidate 发起新选举
- 这种心跳机制天然防脑裂：只要网络分区存在，多数派一侧能持续收心跳维持 Leader，少数派因无法获得多数票而无法选出新 Leader
实际部署要注意心跳与网络抖动的平衡
心跳太频繁会增加 etcd 或 Raft 集群压力；太稀疏又容易误判故障。关键不是追求“绝对实时”，而是设定合理的探测窗口：
- 建议心跳间隔 ≤ TTL / 3（如 TTL=15s，心跳设为 4~5s 一次）
- 租约 TTL 需覆盖最长业务耗时 + 网络毛刺容忍时间（例如业务最长 8s，加 5s 缓冲，TTL 设为 15s）
- 监控 KeepAlive channel 是否长时间无响应，可作为客户端本地健康信号
- 避免将心跳与业务线程强耦合——应独立 goroutine 运行，防止 GC 或阻塞导致心跳停滞
