我会先确认影响范围，同时控制故障继续放大。掌握 RDB、AOF、主从复制、哨兵和 Cluster 的可靠性与故障切换。Redis 通过 RDB 快照和 AOF 日志实现数据持久化，通过异步主从复制保存副本，使用 Sentinel 完成主从架构的监控与自动切换，或使用 Redis Cluster 同时实现分片和故障转移。它们通常只能降低数据丢失风险，不能自动提供跨节点强一致。

止损之后，我会按请求链路建立证据，而不是凭经验猜。 src/rdb.c/aof.c：快照、AOF 与重写。 INFO persistence/replication：fork、fsync、复制偏移。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

定位时我最关注这些参数、指标和容量关系。分别 kill -9 主库、断开副本超出 backlog、在高写入时 BGSAVE，测 RPO、RTO 与 COW 内存。

找到根因后先做最小修复，再用同样的流量验证。主库返回成功后尚未把写传播到副本就宕机，新主缺少该 Key。异步复制不能承诺零丢失；资格状态若不可丢，应落可靠数据库/日志或在写入时等待足够副本并接受延迟。 fork 时写时复制导致内存翻倍：aofdelayedfsync：为 fork 预留内存。 复制积压不足频繁全量同步：fork 耗时与 COW：backlog 覆盖最长断线窗口。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「fork COW」为主基线，记录值应满足「<容器余量」；同时保存 aofdelayedfsync、fork 耗时与 COW，使后续变化能够回到同一时间轴比较。

恢复阶段要逐步放量，最后把监控和边界补齐。高可用保证服务尽快恢复，不自动保证所有已确认写都存在；必须按数据价值选择 Redis 是事实源还是可重建派生数据。