心跳与判死
分布式存储靠心跳判断伙伴是否还活着：节点周期性地互发消息，对端在约定时间内没回应就被标记为可疑，再持续超时则判定离线并触发副本重建。难点在于「多久算死」：阈值太短会把正在做垃圾回收或遇到网络抖动的健康节点踢出去，引发无谓的数据迁移；阈值太长则故障发现慢，降级窗口被拉长。
基本信息
| 适用类型 | Ceph、HDFS、Kafka、Elasticsearch 等集群组件 |
|---|---|
| 判定依据 | 周期心跳 + 超时阈值，部分系统叠加延迟概率模型 |
| 常见参数 | 心跳间隔、超时倍数、可疑阈值 |
| 风险方向 | 误判引发迁移风暴，漏判拉长降级时间 |
典型使用场景
- 集群频繁出现节点上下线抖动：需要区分是真实故障还是阈值过紧
- 扩容后心跳流量上升：评估心跳平面是否需与数据平面分离
- 长尾延迟业务：评估超时阈值与业务可接受的降级窗口如何取舍
- 虚拟机与容器环境：宿主争抢导致瞬时停顿，需要放宽判定
- 跨机房部署：往返时延天然较高，阈值必须按链路实测设定
观察与调整思路
观察与调整思路
# 先看抖动频率与持续时间，而不是先改参数
ceph -s # 关注 up/down 抖动与降级规模
ceph osd tree # 确认是哪几个节点在反复上下线
ceph daemon osd.3 config show | grep -E 'heartbeat|tick' # 查看实际生效参数
# 参数调整前先排除网络丢包、时钟漂移与磁盘长时间阻塞阈值取舍对照
| 阈值设定 | 表现 | 代价 |
|---|---|---|
| 偏紧 | 故障发现快 | 瞬时停顿被误判，触发不必要的副本迁移 |
| 偏松 | 误判减少 | 真实故障发现变慢，降级窗口延长 |
| 分层检测 | 结合网络与磁盘状态综合判断 | 实现复杂，需要按环境实测调参 |
常见的自适应机制
- 采用基于延迟分布的怀疑度模型，用统计概率代替固定超时
- 多路径心跳：管理网与数据网各发一路，减少单链路误判
- 结合后端磁盘状态，识别「进程活着但 IO 卡死」的假存活
- 引入旁路探测，由第三个节点代问，避免双方链路问题被误判为节点故障
- 把可疑与死亡分成两级，可疑阶段先只告警不迁移
心跳流量很小但要求稳定：心跳平面与数据平面分开、走低时延链路，比单纯放大超时阈值更能减少误判。
在虚拟机里跑存储节点时，宿主机的 CPU 争抢会造成秒级停顿；这类环境务必按实测延迟放大判定阈值，否则迁移风暴会反复出现。