Redis内存与性能调优实战：从内存账本到线上故障排查

Redis的Day 6来了。前五天我们把数据类型、持久化、主从复制、哨兵和高可用都过了一遍，今天聊一个平时最容易出问题、也最能体现运维功力的环节：内存和性能调优。很多朋友Redis用着用着就卡了、内存报警了、或者明明数据不多却占了好几个G，一查发现压根不知道问题出在哪。这篇文章我会从内存账本讲起，先搞清楚内存到底花在哪，再讲淘汰策略、过期机制、数据结构怎么省内存，然后是性能排查的思路和实操命令，最后分享一个我自己线上踩过的内存告警案例。内容会比较干，建议对照着你们的Redis实例边看边试。

1. 内存问题的根源：先搞懂Redis的内存账本

很多人以为Redis的内存占用就等于数据量大小，这是最大的误解。Redis的内存开销远不止key-value本身，它包括了数据的内存、Redis自身的运行时开销、以及操作过程中产生的临时内存。如果不把账算清楚，后面所有调优都是瞎猜。

1.1 数据本身只占一部分：内存开销从哪来

我经常跟团队里的小朋友打比方：Redis存一条数据，不只是把“钥匙”和“锁”放进柜子里，柜子本身的隔板、标签、登记本都是要占地方的。具体来看主要有这么几块。

第一块是key和value本身的开销。每个key都有一个字典条目（dictEntry），这个条目在64位系统下大约要占64字节左右，包含了key的指针、value的指针、next指针、以及过期时间等元信息。如果你存的key很短，比如只有几个字符，那这个dictEntry的开销甚至比key本身还大。

第二块是Redis对象头的开销。每个value都是一个redisObject，包含type、encoding、ptr等信息，在64位系统上大约占16字节。也就是说，哪怕你存一个整数1，除了int本身8字节，还有16字节的redisObject包装。

第三块是内存碎片的损耗。Redis默认使用jemalloc分配器，它的特点是快、多线程安全、碎片少，但并不是没有碎片。频繁的申请和释放会造成内存碎片，导致used_memory_rss（进程实际占用的物理内存）明显大于used_memory（实际使用的内存）。注意这里，我在下面会专门展开讲。

还有一块容易被忽略的是客户端输出缓冲区。每个连接到Redis的客户端都有一个query buffer和output buffer，如果某个客户端执行了类似于keys *或者一次性读取大集合的操作，输出缓冲区瞬间膨胀，会直接把内存顶到警戒线。

1.2 三个关键指标：used_memory、used_memory_rss、mem_fragmentation_ratio

排查内存问题，第一步永远是用redis-cli info memory看内存的台账。很多人上来就盯着used_memory看，其实不够。我建议重点看这三个值。

used_memory是Redis分配器分配出去的内存总量，包含数据和所有的运行时开销，相当于“账面内存”。used_memory_rss是操作系统视角下Redis进程实际占用的物理内存，相当于“实际占内存”。第三个是mem_fragmentation_ratio，也就是used_memory_rss除以used_memory的比值，用来衡量内存碎片情况。

这个比值怎么解读？我总结了一个经验区间：

• 比值小于1：说明发生了swap，也就是物理内存不够，Redis的一部分内存被交换到了磁盘上，性能会急剧下降，这是最危险的信号。
• 比值在1到1.5之间：正常区间。Redis刚启动、数据量小、或者jemalloc分配比较整齐的时候，比值接近1。
• 比值大于1.5：碎片率偏高。内存碎片意味着分配器向操作系统申请了很多内存，但实际分配给数据的只有一部分，剩余的空间暂时无法利用。这时候要考虑重启实例（主从切换后用slave先数据同步再提升）、或者用memory purge（只对jemalloc有效）来缓解。

注意：memory purge这个命令不是所有版本都有，而且它只能清理一部分碎片，不是万能药。真正严重的碎片问题，通常需要从数据模型设计上解决，比如避免频繁修改大对象、避免大量相同前缀的key反复创建删除。

2. 内存优化三板斧：淘汰、过期与数据结构改造

账算清楚了，接下来才是动手优化。内存优化没有银弹，但有三板斧在绝大多数场景下都能见效：设定上限和淘汰策略、处理过期key、改造数据结构。

2.1 maxmemory与淘汰策略的选择逻辑

不管你的机器内存有多大，我都建议给Redis设置maxmemory。不设置上限，Redis就会像一个没有节制的消费狂，直到把系统内存吃光，然后触发OOM killer把Redis进程杀掉，或者疯狂swap导致性能雪崩。

设置maxmemory的时候要留出给操作系统和持久化的余量。比如机器是8G内存，建议Redis最多用5-6G，剩下的给OS的page cache、给fork子进程做COW（Copy On Write）留出空间。特别要注意的是，开启RDB持久化时bgsave会fork出一个子进程，虽然子进程共享内存页，但如果后续有写操作触发COW，内存会短暂上涨，如果maxmemory设得太满，很容易踩到fork失败或者内存不足。

设置完了还要选对淘汰策略，这个很多人随便选，其实里面门道不少。Redis 4.0以后有8种策略，日常主要用这三种：

• allkeys-lru：全体key按LRU（最近最少使用）淘汰。适合缓存场景，不区分key是否设置过期时间，谁最近没被用就淘汰谁。
• volatile-lru：只在设置了过期时间的key里按LRU淘汰。适合某些key需要永久保留、某些key可以丢的场景。
• allkeys-lfu：按LFU（最不经常使用）淘汰。适合访问频率极度不均衡的场景，比如热点数据特别集中，用LFU比LRU更精准。

我在线上遇到最多的问题是：有人把maxmemory-policy设成noeviction（默认值），然后开启持久化、数据量超过内存，写入直接报OOM command not allowed when used memory > 'maxmemory'。这不是bug，而是策略使然。如果用Redis做缓存且允许丢数据，老老实实改成allkeys-lru；如果做存储且不能丢，那就得扩容或者优化数据模型了，别指望Redis帮你兜底。

2.2 过期key的"延迟释放"陷阱

这是内存优化里最隐蔽的问题之一。你给key设置了过期时间，以为到了时间内存就自动释放了，但Redis的过期删除其实是被动的。

具体来说，Redis的过期key删除靠两种机制：惰性删除和定期删除。惰性删除是当你访问一个key时才发现它过期了，顺手删除；定期删除是Redis每隔一段时间（默认每秒10次）随机抽一批设置了过期时间的key，删除其中过期的部分。这两种机制配合，既保证了效率，又避免了集中删除造成阻塞。

但问题来了：如果一个key过期之后一直没人访问，而且定期删除的抽样池子里又没抽到它，那这个key就会一直占着内存。这种情况在key量大、过期时间分散的场景下特别明显。我见过最夸张的案例是，一台机器上亿个key里有过期时间的占了40%，但实际上被删除的只有一少部分，内存占用一直下不来。

排查方法很简单：用redis-cli --scan --pattern '*'看一下已过期但未删除的key数量，或者用redis-cli --stat观察keyspace_hits和keyspace_misses的比值。如果确认大量过期key没有及时清理，有两个方向可以处理。临时方案是用redis-cli --scan --pattern '要清理的前缀*' | xargs -L 1 redis-cli del批量删除（注意这个命令在大库上会阻塞，建议在从库上干或者低峰期干，或者用unlink替代del来异步释放内存）。长期方案是检查业务上是不是有过期时间设置不合理的场景，或者主动把过期key的TTL集中在偏短的时间窗口，减少分散。

2.3 用更省内存的数据结构：hash、intset、ziplist的实战取舍

有经验的Redis开发者都知道，Redis内存优化最大的空间不在Redis本身，而在你选择的数据结构编码方式上。Redis对同一个数据类型有不止一种底层编码，小数据量时用紧凑编码，大数据量时切换为常规编码。

以hash为例：当hash里的字段数小于512（默认hash-max-ziplist-entries），并且每个字段名和值的长度都小于64字节（默认hash-max-ziplist-value）时，Redis用ziplist这种紧凑的连续内存结构存储，开销量非常小。一旦超过阈值就切换成hashtable，每个字段的独立性增强，但内存开销变大。

同理，list在元素较少且都是整数时用intset编码，小list用quicklist内部也采用了ziplist节点；set在元素少且为整数时用intset。这就是为什么我经常建议：把多个小key合并成一个hash，能极大降低内存占用。

举个例子，如果业务里有100万个用户状态，每个用户有十几个字段。你如果按user:10001:name、user:10001:age这样的方式拆成多个字符串key，每个key都要算一遍dictEntry和redisObject的固定开销，100万用户的十几个字段就是几千万个key，内存瞬间爆炸。但如果用hash，每个用户一个key，内部字段打包在ziplist里，固定开销被摊薄了。实测下来，同样的数据量，用hash组织比拆散成string可以省一半以上内存，尤其是字段短、key多的时候效果更明显。

不过要注意，ziplist省内存的代价是读写时定位元素需要遍历，如果单个hash里的字段太多，反而会导致性能下降。所以设计规则是：hash里的字段控制在1000以内，字段名和值保持短小，不要为了省内存把一个hash塞成超级大对象。修改hash-max-ziplist-entries可以调大阈值，但我不建议设得太大，否则长字段的遍历会成为性能陷阱。

3. 性能调优：从头到尾的链路排查

说完了内存，再讲性能。性能问题从来不是单点的，它可能出在连接层、命令执行层、持久化层、甚至网络层。以下是我在实际排查中总结的比较完整的优化链路。

3.1 配置参数里的"隐形杀手"：timeout、tcp-keepalive、tcp-backlog

很多人的Redis配置文件是默认的，改都没改过，这里面就有不少隐藏问题。

第一个是timeout。默认值是0，表示客户端连接空闲多久之后Redis主动断开——0表示永不断开。如果你的客户端没有做连接池复用，每次用完就丢，这会造成大量空闲连接一直挂着，每个连接都要占内存作为输出缓冲区。建议设置timeout 300，让空闲超过5分钟的连接自动断开。

第二个是tcp-keepalive。默认是300，表示Redis每隔300秒向客户端发送一个keepalive探测包，确认连接是否还活着。在客户端异常断电、网络断开的情况下，这个值决定了Redis多久能发现连接失效并清理。如果你的应用有大量短连接，可以把这个值调小到60-120，加速失效连接的回收。

第三个是tcp-backlog。它决定了Redis的TCP accept队列长度。默认值511，如果并发连接数很高，而应用层来不及accept，内核的accept队列会溢出，导致部分客户端连接被拒或者握手超时。在高并发场景下建议调整系统参数net.core.somaxconn和net.ipv4.tcp_max_syn_backlog，并把tcp-backlog设置成和它们匹配的值，比如1024或更高。

还有maxclients，默认10000，一般够用，但如果你用的是低配机器，连接数上来后fd不够用，Redis会报max number of clients reached。这个需要结合系统的ulimit -n来调，先把文件描述符限制放宽，再调大maxclients。

3.2 持久化对性能的影响：RDB快照与AOF重写的取舍

持久化是Redis性能的一大干扰源。RDB做bgsave时会fork子进程，fork本身是很快的（现代Linux用的是写时复制），但在大内存实例上，fork瞬间会因为要复制页表而短暂卡顿。我见过一个12G内存的实例，fork一次导致主线程卡了将近1秒，线上直接报警。经验值是：单个Redis实例的数据量不要超过物理内存的一半，能有效降低fork的代价。

AOF的影响则体现在append和rewrite上。AOF每次写操作都要追加到文件，如果appendfsync设置成always，每次写都要刷盘，性能会降到惨不忍睹，只能用在数据安全性极高的场景；everysec是推荐的折中方案，每秒刷一次盘；no交给操作系统决定刷盘时机，性能最好但丢失数据的窗口最大。

AOF重写（rewrite）虽然是在子进程里做的，但重写期间主进程如果有大量写操作，会积压AOF缓冲和重写缓冲，导致内存上涨和IO压力。我的建议是：如果业务对数据丢失容忍度足够高，纯缓存场景直接关掉持久化，能省掉一大部分性能开销；如果必须持久化，优先RDB，恢复快、影响小；AOF只在数据变更比较重要且机器IO有余力的时候开。

3.3 慢查询日志：定位"拖后腿"的元凶

性能问题排查，我建议先看慢查询日志，再看monitor，最后才是抓栈。Redis的slowlog机制很简单：超过阈值的命令会被记录下来，用slowlog get可以查看。

配置有两个关键参数：slowlog-log-slower-than（微秒）和slowlog-max-len（条数）。注意，10000微秒等于10毫秒，我一般把这个阈值设成5000（5毫秒），也就是超过5毫秒的命令都记录下来，因为Redis单线程模型下，一个命令超过5毫秒就会让整个实例的吞吐量有明显波动。

slowlog get的输出里有几个关键信息：命令名、执行参数、执行耗时、时间戳。排查慢查询时，逐条分析是不是有keys *、hgetall大hash、smembers大set、zrange大zset这些危险命令。如果是，就要从业务层改成分批读取，或者用scan系列替代keys *。

需要特别提一句的是KEYS命令。很多人为了调试方便，直接在线上执行keys *，这个命令会遍历全库的所有key，数据量大了以后阻塞时间是以秒计的。线上排查key请用scan，它每次只返回一小部分，配合游标可以无阻塞地遍历。

3.4 大key与小key：不要小看网络耗时

另一个常见的性能杀手是大key。Redis是单线程的，一个命令执行期间其它命令都排队等待，如果你有个value是几MB的字符串，或者一个hash里有几万字段，那么读取它的命令会在主线程里跑很久，直接拖垮整个实例的响应能力。

排查大key可以用redis-cli --bigkeys，它会扫描实例并输出最大的若干key。不过要注意，--bigkeys这个命令本身在线上扫全库也是有一定开销的，建议低峰期跑。扫出来之后，策略就是拆分：大hash可以拆成多个小hash，大list可以拆成多个list，大string可以通过压缩或者分片存储。

另外很多人忽略的一点是网络耗时。Redis的一次操作，数据在客户端和服务器之间传输的时间往往比Redis执行命令本身还要长。如果客户端和服务器之间网络延迟是5ms，那一秒最多也就200次请求，再多也是排队。所以Redis的调用方要尽量和Redis同机房部署，用内网而不是公网连接，这比任何SQL优化都有用。

4. 线上实战：一次内存告警的排查实录

理论讲了这么多，来一个真实案例。这个案例是我之前带的一个项目的经历，排查过程挺典型的。

4.1 现象：used_memory不高，但物理内存告警

有一个Redis实例，8G的机器，maxmemory设了5G，数据量大概在2G左右。某天运维报警说物理内存使用率超过90%，进程有被OOM kill的风险。我上去一看info memory，发现used_memory才2.1G，但used_memory_rss已经5.8G了，mem_fragmentation_ratio高达2.7。账面上只用了2G，实际却占了5.8G，中间差了3.7G，这就是典型的严重碎片化问题。

4.2 排查：从INFO到--bigkeys

第一步，我先确认了时间线：这台机器是三个月前从2G数据升级上来的，中间经历过一次全量数据迁移，之后每天都有大量短生命周期key的频繁写入删除。结合mem_fragmentation_ratio持续高于2，基本可以锁定内存碎片积累。

第二步，我用redis-cli --bigkeys扫描了一遍，确认没有单个大key导致数据分布不均的问题，各个类型里最大的key也就几百KB，不足以解释3.7G的差距。

第三步，我看了info stats里的keyspace_hits和expired_keys，发现过期key数量不少，但expired_keys增量并不大，说明大量设置了过期时间的key并没有被主动访问触发删除，而是在定期删除的随机抽样中漏掉了，一直在占内存。过期key加碎片效应叠加，才让内存账本彻底失控。

4.3 结论：碎片与过期key的叠加效应

解决方案分两步走。第一步处理过期key，我在低峰期用scan配合unlink批量清掉了那些已过期但未删除的key，这一步释放了大概800M内存。第二步处理碎片，最彻底的办法是重启实例让内存重新整块分配，但生产环境不能直接重启丢数据。我采用的做法是：在主从复制环境下，先用从库顶上来，把主库重启清掉碎片，再切回来，全程零停机。

重启后mem_fragmentation_ratio降到了1.1左右，内存告警消失了。但这还没有完，我在代码层面还做了一件事：把原来大量拆散的短生命周期字符串key合并成了若干个hash，用ziplist编码存储，从根本上降低了dictEntry的固定开销和碎片的产生源。三个月后回头看，同样的数据规模，used_memory_rss只有之前的40%。

4.4 常见问题速查表：一条命令看清内存状态

内存排查我整理了一个速查表，直接收藏就好：

memory doctor这个命令是Redis 4.0引入的，它会自动检查常见的内存问题并给出报告，排查时可以先跑一下当个参考。

5. 调优避坑指南：别把调优做成负优化

调优这件事，很多时候不是不会调，而是调过头了。下面这几条都是我用真金白银换来的教训。

5.1 配置改动的"负优化"清单

很多人一拿到调优文章就照着抄，结果越调越差。比如：

• 过度调大ziplist阈值。把hash-max-ziplist-entries从512调到10240，确实内存降了，但hash内字段一多，哈希查找退化成了遍历，CPU飙升。ziplist越小越省内存是有限度的，需要在内存和CPU之间求平衡。
• 盲目关闭AOF。有的场景数据其实不能丢，为了性能关了AOF，结果机器一重启丢了几分钟数据，业务事故。关持久化之前，先确认你的业务真的能接受数据丢失。
• maxmemory设得太满。总觉得既然机器有8G就把maxmemory设成7G，结果RDB fork的时候COW需要额外内存，触发OOM。我建议maxmemory最多占物理内存的70%-75%，给操作系统和fork留足空间。
• 连接池配得太大。客户端连接池大小不是越大越好，连接数太多会让Redis的CPU花在处理连接请求上，而不是处理命令。单个实例的客户端连接数在几百到一两千就很充裕了，没必要配上万。

5.2 调优后的监控与自检

调优不是一次性动作，后续的监控更重要。我建议至少盯这几个指标，做成图表每天看一眼：

• used_memory和used_memory_rss的走势，以及mem_fragmentation_ratio。
• keyspace_hits和keyspace_misses，命中率掉到90%以下说明缓存设计有问题，大量请求穿透到数据库了。
• slowlog的条数和耗时分布，持续出现慢查询就要追根因。
• connected_clients的变化曲线，异常突增多半是客户端没做好连接复用。
• rejected_connections，被拒绝的连接数大于0时，要么maxclients太低，要么TCP backlog满了。

还有一个容易被忽略的自检项：版本升级。Redis 5和Redis 6在内存管理、过期机制、阻塞命令处理上都有很大改进。如果还在用老版本，很多调优手段压根用不上。比如Redis 4.0才有的memory命令和LFU淘汰，Redis 5.0引入的client pause和动态调整hash-max-ziplist-entries参数，Redis 6.0引入的多线程IO处理（注意只是网络IO多线程，命令执行还是单线程）。版本太老，调优天花板就低。

我个人在实际排查中还有个习惯：每次调优都记录before和after的指标快照，哪怕只是改了maxmemory-policy，也要把info memory的几个关键值记下来。不然时间一长，你就会忘记当初为什么改这个参数、改完是变好了还是变差了。很多坑，恰恰是“不知道改了什么参数”造成的。

最后分享一个小技巧：如果决定要动生产Redis的配置，先把config get的结果备份下来，用config set在线修改后观察一段时间，确认没问题再写入redis.conf。万一调坏了，config set改回来也就是一条命令的事，没必要直接改配置文件然后重启，那是自己给自己找麻烦。