rdb快照在突发宕机时可能丢失自上次保存以来的所有写入数据，如配置为900秒触发而第4分50秒崩溃，则丢失4分50秒数据；其适合非关键缓存场景，但不可单独用于订单等不可丢数据。
RDB快照在突发宕机时能保住多少数据
RDB是定时生成的二进制快照，它不记录中间状态。如果配置为每5分钟 save 900 1（即900秒内至少1个key变更就触发），而实例在第4分50秒崩溃，这4分50秒的所有写入都会丢失。
常见错误现象：redis-cli INFO persistence 显示 rdb_last_bgsave_status:ok，但 rdb_last_bgsave_time_sec 是320——说明上次快照已是5分20秒前，不是“刚保存完”。
- 业务写入频繁且不可丢（如订单状态更新），RDB单独用风险极高
- 若仅缓存非关键数据（如热搜榜、用户在线状态），RDB足够，还能避免AOF重写开销
- RDB文件体积小、恢复快，适合做冷备或灾备同步，但不能替代实时持久化
AOF重写期间Redis变慢甚至阻塞的真正原因
AOF重写（bgrewriteaof）本身是子进程操作，但重写完成时需原子替换旧AOF文件，此时主线程会短暂阻塞——尤其当AOF文件超1GB、磁盘I/O慢或使用ext4默认挂载参数时，阻塞可达数百毫秒。
更隐蔽的问题：AOF缓冲区（aof_buf）在重写期间持续累积，若此时发生写入洪峰，缓冲区溢出会导致Redis直接断连（日志出现 ERROR write error writing to the AOF file: No space left on device 或 write(2) returned -1）。
- 必须设置
auto-aof-rewrite-min-size和auto-aof-rewrite-percentage避免高频重写 -
appendfsync everysec是平衡点：兼顾性能与最多1秒丢失；always基本不用，吞吐掉30%以上，且ECS云盘/普通SSD无法稳定支撑 - 开启
aof-rewrite-incremental-fsync yes，让重写子进程分批fsync，降低单次I/O压力
混合持久化（RDB+AOF）不是简单叠加，而是有加载顺序依赖
Redis 4.0+ 支持 aof-use-rdb-preamble yes，启动时先加载RDB部分（快），再回放AOF尾部命令（准）。但这个机制只在AOF文件完整且末尾无截断时生效。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
常见错误现象：服务器异常断电后，AOF文件末尾损坏，Redis启动报错 Bad file format reading the append only file，即使RDB preamble完好也无法跳过错误继续加载。
- 必须配合
redis-check-aof --fix工具修复，但修复后可能丢失最后几条命令——不是“自动兜底” - 混合模式下，
CONFIG SET appendonly yes动态开启AOF，不会自动补全RDB preamble，首次AOF重写前仍是纯AOF格式 - 备份策略要同时保留最新RDB + 对应AOF（通过
redis-cli BGREWRITEAOF后立刻cp），否则恢复时无法对齐
从生产事故反推：哪些业务场景绝对不能关AOF
曾有支付系统将Redis用作“交易流水暂存”，配置了RDB但关闭AOF，认为“反正下游有MySQL”。结果某次内核OOM kill掉Redis进程，未刷盘的最后23笔支付请求全部丢失，导致账务不平。
这类场景共性是：Redis承担了“中间状态暂存”而非纯缓存，且上游无重试/幂等保障。
- 消息队列型用途（如延迟队列用ZSET实现）：必须开AOF，且
appendfsync everysec+no-appendfsync-on-rewrite yes - 分布式锁续期（如Redlock中临时key）：RDB够用，但锁服务本身不应依赖单Redis节点，持久化只是辅助
- Session存储：若Session过期时间远长于RDB间隔（如2小时），且应用无failover逻辑，则AOF是底线
真正难的是权衡——比如一个实时推荐服务，特征向量存在Redis里，每秒更新千次。这时RDB 60秒一次比AOF everysec 更稳：因为AOF重写+fsync抖动反而更容易引发超时。该选哪个，得看你的监控里哪类延迟毛刺更伤业务。
