持久化方式选错，宕机就丢数据。Linux 上的问题大多有明确原因，难的不是解决，而是先定位到是哪一层出的问题。

下面按“先判断范围、再处理、最后防复发”的顺序展开，涉及 Redis、持久化 的关键动作都给了具体做法，可以照着走。

RDB

定时快照，恢复快但可能丢几分钟。

需要留痕的操作，把时间点和现象一起记下来，复盘时最有用。

AOF

everysec 兼顾性能与安全，文件更大。

容易踩的坑：常见的坑是只处理表象：症状消失就收工，根因还在，过几天又复发。

建议

缓存场景可只开 RDB，业务数据建议 AOF。

同一时间只改一项，改完立刻验证，出问题也好定位。

验证

重启后看 key 是否还在。

常见问题

Q：Redis这类问题，最快的判断办法是什么？
先确认现象的范围：只有单台还是全部、只在某个时段还是持续。范围一缩小，原因基本就浮出来了。

Q：按文中的步骤做完，还需要注意什么？
把处理过程和最终生效的参数记下来。同类问题再出现时直接对照记录，比重查一遍快得多。

小结

回到这篇的四个环节：RDB、AOF、建议、验证。生产环境优先考虑稳定性，新参数先在小流量机器上验证。

相关阅读：binlog 太大怎么清理、MySQL 主从复制怎么搭、MySQL 备份与恢复实践。