Raft 日志复制延迟：多数派确认不等于所有副本都健康

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 慢，而是慢副本长期被多数派成功掩盖。等到故障切换发生，它会一次性把债暴露出来。