做后端和运维这些年Redis内存设置是我被问得最多的问题之一也是最容易出事故的配置项。很多人一开始只会在配置文件里写一句maxmemory 512mb结果线上跑着跑着就开始报OOM或者Redis进程直接被系统杀掉。更常见的情况是明明数据就几百万个小key内存却涨到几个G怎么减都减不下来。这篇文章不是来讲官方文档的而是把我踩过的坑、用过的排查方法、以及最终稳定落地的配置方案完整梳理一遍希望能帮你把Redis内存这一块彻底搞明白。不管你是刚接手线上服务的新手还是已经写过很多年分布式缓存的老手里面涉及的淘汰策略选型、碎片整理参数、内存监控排查手段都对你有实际参考价值。这篇文章虽然叫Redis内存设置但真正要解决的是三个核心问题内存被谁吃了、满了之后会发生什么、以及内存不够用的时候该如何排查和止损。1. 先搞清楚Redis的内存到底被谁占了1.1 数据本身只占内存的一部分如果你的Redis里存了一亿个key每个value只有几个字节你可能会觉得内存应该很小。但真实情况是一亿个key的纯元数据开销就足以让你怀疑人生。Redis是内存数据库每个键值对除了存储数据本身还有额外的结构开销包括dictEntry、redisObject、SDS头部等等。简单算一笔账每个key对应的哈希表条目、对象头、实际字符串对象加在一起至少要占用50到100字节。也就是说一亿个key即使每个value只有一个字节光结构开销就是5到10个G级别的内存。很多人线上内存一直降不下来查了半天发现是key数量太多而不是value太大这个方向一开始就错了。除了键值对本身还有几块隐形内存开销经常被人忽略。第一块是复制积压缓冲区repl-backlog用于主从同步期间补发增量数据默认配置下可能占用几十MB到几百MB不等。第二块是客户端缓冲区包括输入缓冲区和输出缓冲区如果某个客户端执行了大量批量读取输出缓冲区会临时膨胀得很厉害。第三块是持久化相关的开销比如RDB持久化和AOF重写时Redis会fork出子进程虽然用的是写时复制但主进程在fork期间的写操作会导致内存页被复制这时候RSS会明显翻倍。这些开销有一个共同特点它们都不在used_memory的直接数据统计里那么直观需要结合used_memory_rss和mem_fragmentation_ratio一起看。否则你只会觉得奇怪为什么我明明没存多少数据内存却已经爆了。1.2 maxmemory到底该怎么设maxmemory的作用是给Redis一个硬性内存上限一旦超出限制Redis就会根据淘汰策略开始清理或直接拒绝写入。设置方式有两种一种是直接在redis.conf里写入maxmemory 512mb另一种是运行时执行CONFIG SET maxmemory 512mb后者会立即生效不用重启。注意单位支持b、kb、mb、gb配置时建议统一使用mb或gb避免单位换算错误。有一个很关键的坑64位系统下maxmemory默认值是00在Redis里的意思是不限制而不是不分配内存。所以很多人默认情况下其实完全没设置内存上限Redis会一直把系统内存吃到机器扛不住为止。而32位系统的默认上限是3GB因为32位进程最多只能寻址那么多这个差异也经常被交叉部署的人忽略。我个人在实际配置时不会把maxmemory设成完全等于业务缓存预期值而是会额外预留25%到50%的内存冗余用来应对上面提到的结构开销、复制缓冲区、fork期间的内存翻倍。更稳妥的做法是先观察正常运行时的used_memory_peak取峰值乘上1.3到1.5再结合机器物理内存大小反推一个安全值。比如一个8G内存的机器给Redis分配4G剩下4G留给操作系统、持久化进程和突发流量这样即使触发fork也不会立刻OOM。2. 内存满了之后会发生什么淘汰策略解析2.1 八种淘汰策略逐个拆解当实际内存超过maxmemory时Redis不会立刻报错而是会根据maxmemory-policy决定下一步行为。很多人知道有八种策略但根本说不清区别这里我直接按行为分类来讲。第一类是直接从数据字典里筛选淘汰对象包括allkeys-lru、allkeys-lfu、allkeys-random。这类策略对所有key一视同仁不管有没有设置过期时间满了就按规则淘汰。第二类是只针对设置了过期时间的key进行淘汰包括volatile-lru、volatile-lfu、volatile-random、volatile-ttl。如果没有任何一个key设置过期时间那这类策略就相当于失效了。第三类是noeviction这也是默认策略意思是内存满了之后不淘汰任何已有数据而是直接拒绝所有写命令读命令还能正常执行。这里有一个很多人会踩的坑也是面试经常问的点volatile-lru和allkeys-lru在内存满了但没有任何过期key的时候表现完全不同。volatile-lru会觉得无key可淘汰然后所有写入直接报错allkeys-lru则会正常淘汰普通key。如果你的业务场景是纯缓存所有key都没有设置过期时间但淘汰策略选了volatile开头那等于哪天数据量上来就会立刻触发写失败。选策略之前一定要想清楚你的Redis里面到底有没有过期key以及能不能接受任意key被淘汰。2.2 LRU、LFU与TTL的真实机制LRU是Least Recently Used的缩写从原理上讲应该是淘汰最长时间未被访问的key。但Redis并没有实现严格意义上的全量LRU而是采用近似LRU这一点很关键。真正的LRU需要维护双向链表每次访问都要维护顺序在Redis这种高并发场景下代价太高。Redis的做法是采样每次从字典里随机抽取maxmemory-samples个key默认5个从中选出最久未被访问的key进行淘汰。所以淘汰结果不是绝对的全局最优而是近似最优。LFU则是根据访问频率来淘汰key适合那种访问热度差异非常明显的场景比如热点新闻的缓存、热门商品的库存信息。Redis里的LFU是用redisObject的24位lru字段改造实现的高16位存储访问频率的计数器低8位存储时间戳通过lfu-log-factor和lfu-decay-time两个参数控制衰减速度。简单理解就是如果一个key之前被频繁访问后来频率降下来了它的计数器会随着时间慢慢衰减如果一段时间内完全没有访问计数器会降到很低最终被淘汰。对于写多读少的场景LFU的命中率通常比LRU更好。3. 内存碎片占了内存却没干活的隐形杀手3.1 碎片是怎么产生的Redis内存碎片的产生机制比较容易理解但很多人没有给它足够的重视。当你频繁执行更新、删除操作时旧的内存会被释放新的内存会被分配但分配器找到的可用空间不一定是连续的。Redis默认使用jemalloc作为内存分配器它会根据请求大小选择不同大小的内存块比如8字节、16字节、32字节、64字节这种级别。如果你存了很多大小不一的value就会导致大量大小不匹配的分配问题形成碎片。判断碎片程度的核心指标是mem_fragmentation_ratio计算公式是used_memory_rss / used_memory。这个比值越接近1说明内存利用率越高如果大于1.5说明碎片已经很严重了实际占用的物理内存是逻辑数据的1.5倍以上相当于白白浪费了三分之一的机器内存。但如果这个比值小于1也不要高兴得太早那通常意味着有一部分数据被换到了磁盘swap里这种情况比碎片问题更危险因为Redis访问磁盘会导致严重的性能抖动。3.2 碎片整理的标准操作流程Redis从4.0版本开始支持自动碎片整理机制通过activedefrag yes开启。开启之后Redis会在后台通过增量方式移动内存数据尽量把分散的小内存块合并成可用的大块。配置项里有几个参数需要关注active-defrag-ignore-bytes 100mb表示如果碎片大小小于100MB就不主动整理active-defrag-threshold-lower 10和active-defrag-threshold-upper 1000表示当碎片率达到10%到1000%区间内才进行整理默认是100到1000可以理解为碎片率低于100%不处理。实际操作里建议先把阈值调低一些通过CONFIG SET动态调整并观察碎片率变化如果长时间没有改善再考虑其他手段。如果是5.0以上版本还可以尝试memory purge命令手动整理内存。但这里要特别提醒memory purge在部分版本上并不是无代价操作它会强制分配器释放空闲内存页需要主进程停止写入一小段时间来完成。生产环境如果没有任何维护窗口不建议手动执行优先开启activedefrag或者干脆计划一次低成本重启让内存重新分配。3.3 操作系统层面的辅助手段碎片问题在很多情况下不只是Redis的锅操作系统内存管理策略影响也很大。最典型的是透明大页THP内核默认开启后可能会出现一个2MB的大页被部分占用但无法缩回的问题导致内存碎片率居高不下。很多生产环境会在启动Redis前关闭THP命令是echo never /sys/kernel/mm/transparent_hugepage/enabled但要注意这需要root权限而且重启机器后会失效需要写进开机启动脚本。另外还有一个容易被忽视的参数是vm.overcommit_memory。Redis官方文档建议将vm.overcommit_memory设置为1这样可以避免fork子进程时因为内存不足而失败。但在内存不是很充裕的机器上这样配置反而可能让Redis吃掉过多内存导致OOM。所以这个参数一定要结合机器物理内存和maxmemory综合评估不要无脑照搬官方建议。4. 线上排查实战内存到底花在哪了4.1 INFO memory命令逐字拆解排查Redis内存问题的第一步永远是看INFO memory输出。第一次看到这段输出的人很容易被一长串字段吓到但其实关键字段就那么几个。used_memory是Redis逻辑上使用的内存总量由数据结构和各缓冲区构成used_memory_human是它的可读版本单位是MB或GBused_memory_rss是Redis实际占用的物理内存和内核报告给进程的RSS一致used_memory_peak是历史峰值如果当前值远低于峰值说明之前曾经出现过高速增长之后才回落。maxmemory和maxmemory_policy是当前配置和淘汰策略。mem_fragmentation_ratio我之前说过了。还有一个mem_allocator字段它标明当前使用的分配器现在主流的Redis版本都内置并默认使用jemalloc通常不需要特别处理。举个例子你执行INFO memory后看到used_memory: 2147483648、used_memory_rss: 3221225472那说明逻辑内存是2G实际占用了3G碎片率约1.5已经处于偏高状态。如果此时total_system_memory只有4G还跑着其他服务就很危险了。正确的排查思路是先看used_memory_rss是否接近系统可用内存如果是立刻检查maxmemory是否设置、淘汰策略是什么、是否有大key。4.2 MEMORY子命令的三个实用操作在INFO memory基础上还有一个更精细的排查方向就是MEMORY子命令。MEMORY USAGE key可以查看某个key的实际内存占用返回结果包含key本身和value的所有结构开销。比如MEMORY USAGE user:1024返回2000说明这个key占了2KB左右。如果怀疑线上有超大value可以先列出你认为可疑的大key再逐个确认不必全量扫描。MEMORY STATS会返回从启动到现在的内存统计快照里面包含data、residue、fragmentation等多项指标适合写脚本做持续采集。还有一个MEMORY DOCTOR命令特别有意思它会输出当前内存状态是否健康以及建议采取的优化措施比如内存碎片率过高建议开启activedefrag或检测到大key建议拆分。虽然它的建议不一定完全准确但作为排查起点非常方便。4.3 大key定位的两种操作路线如果内存问题是由大key引起的INFO memory根本看不出具体对象这时候就要用redis-cli --bigkeys了。这个命令会遍历整个实例统计最大的key、最大的hash、最大的list等输出每个数据类型中占用空间最大的几个key。它本质上是执行SCAN和DEBUG OBJECT来估算内存会对线上产生一定压力所以建议在业务低峰期执行或者直接在从节点上执行。另一种更精准的方式是自定义脚本用SCAN游标遍历key对每个key执行MEMORY USAGE获取真实占用超过预设阈值的记录下来然后再针对这些大key做拆分或者删除。这样做比--bigkeys慢一些但结果非常精确。我习惯在生产环境把阈值设成10MB扫描完生成一份报告再根据报告决定是拆分、压缩还是淘汰。这里有一个经验很多大key其实不是业务直接产生的而是某个聚合计算把结果一次性缓存在了Redis里遇到这种情况最好从写入源头限制单个value大小而不是每次爆了再去清理。4.4 操作系统的配合排查排查到Redis自身没问题之后还要看一眼操作系统层面的三个指标可用内存、swap使用量和RSS。free -h可以看整体内存水位cat /proc/[pid]/status里的VmRSS和VmSwap能看到Redis进程实际占用的物理内存和swap。一旦发现有swap占用基本可以判定内存设置不合理因为Redis在swap上的性能损耗接近死机级别。另外看一下进程数量确认是否存在多个Redis实例共用一台机器。很多时候你给实例A设置了4G内存上限但实例B没设置结果A配置好好的也照样出事因为B把物理内存抢光了。如果一台机器上部署多个Redis实例建议在配置文件里用不同的maxmemory隔离同时用cgroup等方式约束进程资源避免某个实例因为峰值内存拖垮整个物理机。5. 常见问题与避坑速查5.1 线上问题速查表我把这几年遇到的高频问题汇总成一个表格方便你对照排查现象常见原因处理建议Redis内存一直涨maxmemory设了也没用maxmemory-policy配置成了noeviction或volatile开头策略切换为allkeys-lru或allkeys-lfu并确认策略与过期key情况匹配写命令突然报OOM错误内存达到maxmemory淘汰策略无法淘汰任何key检查淘汰策略和过期key数量紧急时临时调大maxmemory内存碎片率超过1.5频繁更新删除、THP未关闭、分配器碎片开启activedefrag关闭THP必要时重启实例used_memory很小但used_memory_rss非常大碎片率高或子进程写时复制检查mem_fragmentation_ratio和fork时间考虑持久化方案调整重启后内存没下降RDB/AOF加载、持久化数据量过大检查启动日志确认加载过程优化持久化策略淘汰发生后命中率明显下降淘汰策略选型不合理或maxmemory设置过小分析访问模型LFU/LRU按场景选择调大maxmemory5.2 三条最重要的工作经验把这几条放在最后是我最想让你记住的实战心得。第一maxmemory不是越高越好。它的意义在于给Redis一个明确边界同时也是给操作系统一个保护。如果你把maxmemory设成接近物理内存的数值反而容易让Redis在fork持久化或者全量重写时瞬间翻倍内存直接把机器搞挂。宁愿设小一点触发淘汰策略也比整个服务宕机强。第二不要用noeviction去做缓存。如果你把Redis当成缓存服务选noeviction就等于埋了一颗地雷。平时一切正常流量一来数据量一增长直接所有写命令报错业务的缓存穿透变成数据库打挂这就是最典型的Redis内存事故。缓存场景无脑选allkeys-lru或者allkeys-lfu再通过监控观察命中率通常就不会出大问题。第三开启activedefrag之前要先评估CPU。碎片整理不是免费的它是通过后台任务搬移数据来实现的开启之后对CPU会有额外消耗。如果机器本身负载已经很高建议先调整整理阈值、或者选择业务低峰期临时开启。我踩过的坑是在某次高负载期间为了降碎片开启了activedefrag结果CPU额外上涨了十多个百分点得不偿失。最后再分享一个我自己的习惯每次上线新的Redis实例我都会把INFO memory的关键字段采集到监控系统里设置used_memory_peak、mem_fragmentation_ratio、maxmemory三条基础告警线。这样即使内存配置出问题也能在真正触发事故之前提前一步介入调整。内存这块没有一劳永逸的方案但只要配置合理、监控到位绝大多数问题都能在可控范围内解决。