Redis内存配置那些事儿，怎么调才算靠谱又省心的运维经验分享

说到Redis的内存配置,这确实是让很多运维朋友头疼又不得不面对的事情，搞不好，要么是内存蹭蹭往涨导致服务宕机，要么就是过于保守让资源白白浪费，今天咱们就捞干的说点靠谱又省心的经验，主要参考了Redis官方文档和一些像“阿里云开发者社区”这类技术社区里大家的实战分享。

第一件事：别让内存“爆”掉，设置上限是头等大事

这听起来像是废话,但真有不少人一开始不设置最大内存，觉得服务器内存大，随便用，这是最危险的，Redis一旦把物理内存用光，操作系统就会开始用Swap（交换分区），这时候Redis的性能会急剧下降，慢得跟爬一样，如果Swap也用完了，操作系统的内存杀手（OOM Killer）就会跳出来，随机杀掉一个进程来释放内存，而Redis服务往往是首选目标，结果就是服务直接挂掉。

第一步,务必在配置文件redis.conf里找到maxmemory这个参数，给它设一个值，比如你服务器有8G内存，可以设个6G或7G，给系统和其他进程留点余地，这个值就是Redis能用内存的天花板。

第二件事：内存快满了怎么办？淘汰策略是关键

设了maxmemory之后，当内存用到这个上限时，新的数据怎么写进去？这就涉及到淘汰策略，由maxmemory-policy这个参数控制，选对策略，非常省心，官方文档里详细列举了所有策略，但咱们说最常用的几种：

1. volatile-lru：这是最常用、也比较省心的选择，它只针对那些设置了过期时间（TTL）的键进行淘汰，挑最近最少使用的键干掉，这适合你的业务里，大部分数据都设置了过期时间的场景，比如缓存，这样既能保证常用数据留在内存里，又能把不常用的过期键清理掉。
2. allkeys-lru：如果你的Redis是当缓存用，而且所有数据都可以被淘汰，不管设没设过期时间，那就用这个，它从所有键里挑最近最少使用的淘汰，这在“阿里云开发者社区”的一些文章里被广泛推荐为通用缓存场景的首选。
3. volatile-ttl：这个策略不看你用不用，而是看谁快过期了就先淘汰谁，适合那种过期时间有明确层次的数据，比如有些数据5分钟过期，有些10分钟，它优先淘汰剩余时间短的。
4. noeviction：这是默认策略，但也是最“坑”的策略之一，它表示当内存满了之后，所有会申请新内存的命令（比如写命令）直接报错，读命令正常，这适合你把Redis当数据库用，数据绝对不能丢的场景，但要求你的应用能妥善处理这种写错误，如果没做好准备，服务就可能出问题。

怎么选？简单说，纯缓存用allkeys-lru；缓存数据有冷热区分、且都设了过期时间用volatile-lru；核心存储、数据不能丢，并且应用有容错机制，才考虑noeviction。

第三件事：警惕“隐形”内存杀手

你以为设置了上限和淘汰策略就高枕无忧了？还不行，有些情况会悄悄吃掉你的内存。

• 客户端输出缓冲区：如果一个客户端（比如一个执行很慢的订阅者，或者一个卡住的MONITOR命令连接）读取数据非常慢，Redis服务器为它分配的输出缓冲区就会积压大量数据，占着内存不释放，这在Redis官方文档的“客户端”部分有警告，解决办法是监控客户端连接，及时发现和处理异常慢查询或僵尸连接。
• 内存碎片：Redis分配和释放内存会产生碎片，虽然Redis自己有整理机制，但如果你的数据经常频繁修改且大小变化很大，碎片率可能会很高，可以通过info memory命令查看mem_fragmentation_ratio（内存碎片率）指标，如果这个值持续很高（比如大于1.5），并且确实感觉内存浪费严重，可以考虑在业务低峰期执行memory purge（如果支持）或者重启节点来重整内存，一些技术博客会提到调整hash-max-ziplist-entries等参数来优化小数据结构的存储，从而减少碎片，但这个比较进阶，初期可以不用深究。

第四件事：监控和告警是省心的终极法宝

再好的配置也离不开眼睛盯着,你需要监控几个核心指标：

• 已用内存（used_memory）：看它是否平稳，有没有持续增长的趋势。
• 内存碎片率（mem_fragmentation_ratio）：看是否在正常范围。
• 是否触发了内存淘汰（evicted_keys）：如果这个值在持续增长，说明你的内存已经不够用了，淘汰策略在频繁工作，这时候就要考虑是不是该扩容了，或者检查是否有内存泄漏（比如没设过期时间的无用数据堆积）。

设置合理的告警阈值,比如内存使用率达到80%就发告警，这样你就有充足的时间去处理，而不是等半夜服务挂了才被叫醒。

靠谱省心的Redis内存配置就是：设好内存上限，选对淘汰策略，警惕隐藏的内存消耗，再加上完善的监控告警，这套组合拳打下来，虽然不能保证绝对不出问题，但能让你睡得踏实很多。