Redis满了重启这招真管用，解决问题没那么复杂也能稳住数据存储

（引用来源：某技术社区用户“老张运维笔记”的分享帖）

那天晚上，服务器报警短信嘀嘀嘀响个不停，一看是Redis内存使用率飙到98%，眼看就要撑爆了，当时我心里咯噔一下，第一反应就是“糟了，数据要丢！”，按照教科书上的做法，这时候应该紧急扩容、或者分析大Key、设置过期策略啥的，但那是远水救不了近火，情急之下，我想起之前听一个老同事说过一句：“关键时刻，重启大法好。”当时觉得这招太土了，但现在没别的办法,只能硬着头皮试试。

我的操作其实特别简单，没啥高深的，我肯定不能直接敲个redis-cli shutdown就完事儿了，那太莽撞了，我做的第一步，是用redis-cli连上去，执行了一个SAVE命令。（引用来源：Redis官方文档对SAVE命令的解释，该命令会创建一个当前数据集的快照，同步保存到磁盘上的RDB文件）我知道这个命令会阻塞所有客户端请求，直到保存完成为止，但当时业务已经是半瘫痪状态，保数据比保响应更重要，看着命令行界面卡住不动，我的心也跟着悬着，大概等了一分多钟，终于显示“OK”，这意味着当前内存里所有的数据都已经安全落地，写到磁盘的dump.rdb文件里了。

数据保存完毕，我心里就有底了，我果断地执行了重启命令，服务器重启Redis服务的过程很快，也就几秒钟，重启完成后，我立刻再次连接上去，检查内存使用情况，你猜怎么着？内存使用率直接从98%降到了45%左右！系统报警也随即解除,一切恢复了正常。

为什么重启一下就这么管用呢？后来我仔细琢磨了一下。（引用来源：根据我对Redis机制的理解）Redis作为一个内存数据库，它虽然有过期键的淘汰机制，但有些过期键并不会被立即回收，可能因为某些原因，比如这些键虽然逻辑上过期了，但还没有被后台的惰性删除或定期删除进程清理掉，它们依然会占据着内存空间，我们称之为“内存碎片”或者“已过期但未释放的内存”，重启这个过程，相当于进行了一次彻底的“大扫除”，当Redis重新启动时，它会从磁盘上之前用SAVE命令生成的RDB文件里把数据重新加载到内存中，而在加载的过程中，它只会加载那些有效的、没有过期的键值对，那些已经过期了的、或者因为各种原因残留在内存里的“垃圾数据”，在这次重启加载的过程中就被自然过滤掉、彻底丢弃了，重启后我们看到的内存占用，是一个“纯净”的、只包含有效数据的状态,使用率自然就大幅下降了。

我得强调，我这次能这么干，前提是我确认了我们项目的Redis配置是启用了RDB持久化的。（引用来源：Redis关于持久化的配置选项）也就是说，系统会定期或者在满足一定条件时自动将数据快照保存到磁盘，我在重启前又手动执行了SAVE，等于是上了双保险，确保了数据在重启前百分百是最新的完整状态，如果你的Redis根本没开任何持久化，那重启可就真成了“数据清零”的灾难了,这招绝对不能用。

这次经历让我有个挺深的感触，很多时候我们总把问题想得太复杂，觉得一定要用特别高端、特别技术化的方案才能解决，动不动就想着要优化代码、要分片集群、要上更贵的硬件，这些当然重要，是长远之计，但在某些突发的、紧急的场景下，一些看似“简单粗暴”的方法，如果能抓住要害（比如确保数据持久化安全），反而能最快、最直接地解决问题，先把眼前的火扑灭，重启这一下，不仅立刻缓解了内存危机，还为我们后续从容地分析内存占用过高原因（比如是不是有代码在不停地塞没有TTL的数据）、制定真正的优化方案赢得了宝贵的时间，所以我说，Redis满了别慌，重启这招，在确保数据安全的前提下，真挺管用的,解决问题不一定非要搞得那么复杂。