Redis 里那些超时和持久化的事儿，怎么处理才靠谱又不慌乱

主要参考自Redis官方文档、经典技术书籍《Redis设计与实现》以及多位资深运维工程师的实践经验分享）

Redis这个内存数据库，速度是快，但用起来最让人提心吊胆的就两件事：一是数据会不会突然没了，二是服务会不会突然变慢甚至卡死，这两件事儿，说白了，核心就是怎么处理好它的“超时”和“持久化”，下面就直接聊聊怎么弄才算靠谱,真出了事儿也不至于手忙脚乱。

第一部分：关于超时这事儿，别乱设，得有策略

超时设置，就是给Redis里的数据定个“保质期”，设置对了，内存能自动回收，避免撑爆；设置不对，要么是内存浪费，要么是热点数据被误删,引发线上问题。

别用一个超时时间走天下，这是最常见的错误，你图省事，在配置文件里设个全局的3600秒（一小时），结果呢？有些需要长期存放的验证码数据一小时后没了，用户没法登录；而一些本该很快过期的临时缓存数据，却占着内存一小时，造成浪费，靠谱的做法是，在代码里根据不同的业务数据，精确地设置超时时间，短信验证码设300秒（5分钟），用户会话Token设7天,热点新闻数据设30分钟。

理解Redis淘汰数据的策略，当内存快满的时候，Redis就要开始“扔东西”了，扔哪些？这就是淘汰策略（maxmemory-policy），默认的策略经常是noeviction（不淘汰，直接报错），这在生产环境非常危险，会导致所有写请求失败，服务基本不可用，你必须根据业务特点选一个，如果是缓存系统，用allkeys-lru（淘汰最近最少使用的键）就很合适，它能尽量保住热点数据，如果是既有缓存又有重要数据的混合场景，可以用volatile-lru，只淘汰那些设置了超时时间的键里的“最近最少使用”的，这个策略一定要在配置文件里主动设好,不能指望默认值。

还有个小技巧，对于没有自然过期时间但又不能无限增长的数据，可以用“延迟双删”之类的思路，先更新数据库，再删Redis缓存，然后设个几秒后再次删除的异步任务，防止极端情况下缓存脏数据存在时间过长，这虽然不是Redis本身的超时机制,但是一种控制数据有效性的补充手段。

第二部分：持久化这事儿，不是开了就高枕无忧，得懂它怎么干活

持久化是把内存中的数据存到硬盘上，防止服务器断电或宕机后数据全丢，Redis主要有两种方式：RDB和AOF，很多人以为在配置文件里把这两个都打开就万事大吉,其实远不止如此。

RDB（快照），就像是给数据拍一张完整的照片，它的优点是文件紧凑，恢复大数据集时速度非常快，但缺点是可能会丢数据，因为它通常是隔一段时间（比如5分钟）才拍一次照，如果在这期间宕机，最后一次快照之后的数据就全没了。配置RDB的关键在于权衡数据安全性和性能开销。save 900 1表示900秒内至少1个键被改动就触发快照，这个频率太低了，可能丢15分钟的数据，对于数据比较重要的场景，可以设置得更密集些，比如save 60 10000（60秒内1万次改动），但要注意，频繁生成RDB快照会消耗CPU和磁盘I/O，可能影响主线程响应，最好在从库上做持久化,减轻主库压力。

AOF（追加日志），更像是记流水账，把每一个写命令都记录下来，这样数据安全性高很多，最多丢一秒的数据（如果配置为appendfsync everysec），但缺点是文件会越来越大，而且恢复速度比RDB慢。处理AOF，核心是做好“日志重写”，Redis会自动在后台把陈旧的、可以合并的命令压缩掉，最终生成一个更小的AOF文件，你要关注重写的触发条件（auto-aof-rewrite-percentage和auto-aof-rewrite-min-size），避免它在业务高峰时突然启动，占用大量资源导致服务卡顿，可以监控AOF文件大小，在业务低峰期手动触发BGREWRITEAOF命令。

最靠谱的组合拳是：RDB和AOF同时开启，用RDB做定期的完整备份，便于灾难恢复和从库同步；用AOF来保证尽可能少的数据丢失，这样即使AOF文件出问题了,你至少还有一个比较新的RDB快照可以兜底。

第三部分：真出了问题时，怎么才能不慌乱？

平时功夫下足了,真遇到问题才不会慌。

• 内存满了怎么办？ 首先看监控，是哪个Key或者哪种数据类型突然暴涨，可以用redis-cli --bigkeys命令快速找出大Key，如果是预期内的增长，调整淘汰策略为更积极的（如allkeys-lru）并考虑扩容，如果是异常增长（比如代码bug导致无限循环写入），先紧急清理掉问题Key,再排查代码。
• 持久化文件损坏了怎么办？ Redis自带了一个redis-check-aof和redis-check-rdb工具，可以用来修复损坏的AOF文件和检查RDB文件，对于AOF，它通常会截断到最后一个完整的命令处，这可能会丢一点数据，但能保证服务尽快恢复。定期检查备份文件的有效性非常重要,别等到要用的时候才发现备份是坏的。
• 服务超时变慢怎么办？ 别急着重启，先看慢查询日志（slowlog），是不是有复杂的命令（比如keys *）或者大Key操作阻塞了服务，再看持久化是不是正在做fork（RDB和AOF重写都会fork子进程），如果内存太大，fork操作本身就可能耗时很长，导致服务暂停，针对性地优化慢查询，避免使用阻塞命令,并确保机器有足够的内存。

处理Redis的超时和持久化，没有一劳永逸的银弹，核心在于理解你的业务对数据和性能的要求，然后做出合适的配置选择，并辅以监控、报警和定期的演练，把这些事儿都做到位了，心里自然就有底,不会慌乱了。