丢失窗口怎么算
任何持久化方案都有丢失窗口，区别只在窗口有多长。使用 AOF 且刷盘策略为每秒一次时，窗口约等于 1 秒；只靠 RDB 快照时，窗口等于规则设定的最大间隔内的全部写入；用不保存的方式强制停机，本次停机前的增量就全部放弃。把窗口长度明确写进业务承诺，并准备好对账与补数手段，比反复争论「到底会不会丢」更有实际价值。
基本信息
| 计算方式 | 丢失窗口等于刷盘周期或快照间隔 |
|---|---|
| 常见取值 | appendfsync everysec 约 1 秒 |
| 兜底手段 | 消息队列补数、数据库对账、全量校准 |
| 核对命令 | CONFIG GET save 与 appendfsync |
| 风险信号 | rdb_changes_since_last_save 长期偏高 |
典型使用场景
- 上线前与业务方确认可接受的数据丢失窗口
- 设计对账任务：按业务主键定期比对缓存与数据库
- 事故复盘时估算实际丢失量级，决定是否需要补数
- 选择持久化组合时，把窗口长度作为决策依据
- 演练突然宕机场景，验证恢复流程与业务影响
现状核对
现状核对
redis-cli CONFIG GET save
redis-cli CONFIG GET appendfsync
redis-cli INFO persistence | grep -E 'rdb_last_save_time|rdb_changes_since_last_save'
redis-cli INFO persistence | grep -E 'aof_enabled|aof_last_write_status|aof_last_bgrewrite_status'
redis-cli INFO persistence | grep -E 'aof_last_write_status' # 刷盘是否正常方案与窗口对照
| 方案 | 丢失窗口 | 特点 |
|---|---|---|
| AOF everysec | 约 1 秒 | 性能与安全的常用折中 |
| AOF always | 接近为零（单机故障下） | 每条命令刷盘，性能代价最高 |
| 仅 RDB 快照 | 最长等于规则间隔 | 配置简单，对写入量敏感 |
| 不保存强制停机 | 本次停机前全部增量 | 仅用于抢险场景 |
很多业务真正依赖的不是「一条都不丢」，而是「能重建」：先明确每类键的上游来源与重建路径，往往比一味加码持久化配置更有效，也更容易在成本上向业务交代清楚。
丢失窗口只是单机维度。发生主从切换时还会额外丢掉尚未同步到新主库的那部分写入，因此对业务的承诺应当把持久化窗口与切换窗口分开写清楚，分别给出量级与对应的补偿措施，而不是笼统写一个数字。
评估方式可以很朴素：找出写入量最大的那类业务，算出它在这个窗口内会产生多少条记录，再问业务方能不能接受重放或补录这么多数据。这个数字通常比任何参数推导都更有说服力。