Raft 日志复制延迟多数派确认不等于所有副本都健康Raft 的日志复制经常被简化成“多数派确认就提交”。这句话没错但容易让人忽略副本健康。多数派确认能保证提交安全不代表所有 follower 都跟得上。如果某些副本长期落后故障切换、读请求、快照传输都会受影响。分布式存储排障时不能只看 leader 是否能提交还要看 follower lag 和复制延迟。一、复制链路拆开看sequenceDiagram participant L as Leader participant F1 as Follower A participant F2 as Follower B L-F1: AppendEntries L-F2: AppendEntries F1--L: Ack F2--L: Delayed Ack L-L: Commit after majority多数派提交后请求可以返回。但落后的 follower 仍然需要追日志否则未来切主会很难看。二、监控不能只看 commit 成功率需要看每个 follower 的 match index、next index、append latency、snapshot count。raft_metrics: leader_commit_index follower_match_index append_entries_latency_p95 replication_lag_entries snapshot_install_count如果某个 follower lag 持续增长说明复制链路、磁盘 IO 或网络有问题。三、慢副本会拖累未来慢副本短期不影响多数派提交但会带来三个风险切主候选不足、快照传输变重、读扩展能力下降。lag_policy: warn_entries: 10000 isolate_entries: 100000 trigger_snapshot: true check_disk_io: true不要等到 leader 故障才发现 follower 都落后很多。那时恢复窗口会变得很长。四、排查从网络和磁盘开始复制慢通常来自网络抖动、磁盘 fsync 慢、压缩或序列化开销、批量大小不合理。iostat -x 1 sar -n DEV 1同时看日志复制批大小和失败重试。小批量会增加 RPC 开销大批量会增加尾延迟参数需要结合负载调。还要观察 snapshot 安装频率。如果 follower 经常追不上日志只能通过 snapshot 补齐说明复制链路长期不健康。snapshot 能恢复状态但它占用网络和磁盘也会扩大恢复窗口。raft_alerts: follower_lag_entries threshold append_latency_p99 rising snapshot_install_count increasing leader_changes unexpected这些指标最好按 group 或 shard 维度拆开。全集群平均值会掩盖某个热点 group 的复制问题。五、总结Raft 多数派确认保证提交安全但不代表所有副本健康。生产监控要看 follower lag、append 延迟、snapshot 安装和慢副本趋势。分布式存储系统的稳定性不只在“能提交”还在“副本能持续跟上”。多数派不是忽略少数派的借口。真正危险的不是某一次 follower 慢而是慢副本长期被多数派成功掩盖。等到故障切换发生它会一次性把债暴露出来。