首页>内容详情

Redis 内存溢出问题实战指南：排查思路与优化策略

大熊•2025-04-21 20:56:26•文章关键词：Redis,架构,OOM,架构

什么是 Redis 内存溢出

Redis 内存溢出(Out Of Memory，简称 OOM)是指 Redis 使用的内存超过了系统分配给它的最大内存限制。这时 Redis 可能会变得异常缓慢、无法写入新数据，甚至崩溃。

Redis 内存溢出的常见表现

Redis 服务突然宕机
写入操作报错：OOM command not allowed when used memory > 'maxmemory'
Redis 性能急剧下降
客户端连接超时增多

内存溢出的常见原因

maxmemory 配置不合理：没有为 Redis 设置合理的内存上限
内存淘汰策略不当：选择了不适合业务场景的淘汰策略
大 key 问题：存在占用大量内存的 key
内存碎片率高：频繁的写入删除操作导致内存碎片
数据结构使用不当：错误地使用了不适合的数据结构
请求量突增：短时间内大量数据写入
内存泄漏：业务逻辑未正确管理 key 生命周期
持久化配置不当：RDB 或 AOF 配置导致内存使用峰值过高

Redis 内存溢出排查思路

当发现 Redis 可能出现内存溢出问题时，我们可以按照以下步骤进行排查：

redis内存溢出排查思路

1. 检查内存使用情况

首先，我们需要了解 Redis 当前的内存使用状况

# 通过redis-cli连接到Redis服务器
redis-cli

# 执行INFO命令查看内存信息
127.0.0.1:6379> INFO memory

在返回的信息中，我们需要重点关注以下几个指标：

used_memory：Redis 分配器分配的内存总量，以字节（byte）为单位
used_memory_human：以人类可读的格式返回的 Redis 分配的内存总量
used_memory_rss：从操作系统的角度，Redis 进程占用的物理内存总量
used_memory_peak：Redis 的内存消耗峰值，反映历史最高用量
used_memory_lua：Lua 脚本引擎占用的内存
mem_fragmentation_ratio：内存碎片比率，计算方式为 used_memory_rss/used_memory
maxmemory：Redis 实例的最大内存配置
maxmemory_policy：内存淘汰策略
mem_allocator：当前使用的内存分配器（jemalloc/tcmalloc/libc）

内存碎片率(mem_fragmentation_ratio)的标准：

小于 1：Redis 使用的内存超过分配的物理内存，部分数据可能已经被操作系统放入 swap，此时 Redis 性能会严重下降，需要立即处理
1.0-1.5：正常范围，这是内存分配器的合理开销
大于 1.5：内存碎片率偏高，可能需要进行内存碎片整理

内存分配器差异：

jemalloc（Redis 默认）：在小对象分配上更高效，碎片率通常较低，适合大多数 Redis 工作负载
tcmalloc（Redis 6.0+可选）：在多线程环境下性能更好，但对某些数据模式可能碎片率略高
libc：在低内存系统上更轻量，但碎片率通常高于专业分配器

举个例子，某 Redis 实例的内存信息可能如下：

# Memory
used_memory:2147483648
used_memory_human:2.00G
used_memory_rss:2576980992
used_memory_rss_human:2.40G
used_memory_peak:2200000000
used_memory_peak_human:2.05G
used_memory_lua:31744
mem_fragmentation_ratio:1.20
maxmemory:2147483648
maxmemory_human:2.00G
maxmemory_policy:allkeys-lru
mem_allocator:jemalloc-5.1.0

从上面的信息我们可以看出：

该 Redis 实例已经使用了 2GB 内存（used_memory_human:2.00G）
历史峰值为 2.05GB（used_memory_peak_human:2.05G）
实际占用的物理内存为 2.40GB（used_memory_rss_human:2.40G）
Lua 脚本引擎占用 31KB 内存，不是问题源头
内存碎片率为 1.20，处于正常范围
最大可用内存也是 2GB（maxmemory_human:2.00G）
当前的内存淘汰策略是 allkeys-lru
使用 jemalloc-5.1.0 作为内存分配器，适合小对象高效分配

这个实例显然已经达到了最大内存限制，正面临内存溢出的风险。

还可以通过以下命令查看关键监控指标：

# 查看因内存不足被淘汰的key数量
redis-cli INFO stats | grep evicted_keys

# 查看阻塞的客户端数量
redis-cli INFO clients | grep blocked

# 在集群环境中，检查节点状态
redis-cli cluster nodes

若 evicted_keys 持续增长，说明当前内存淘汰策略已在工作，但仍无法满足内存需求。阻塞客户端数量高可能表明有长时间运行的命令，间接影响内存使用。

2. 分析内存占用

2.1 寻找大 key

Redis 中的大 key 往往是内存溢出的主要原因之一。"大 key"的量化标准通常是：

String 类型：值大小超过 10KB
Hash/Set/ZSet/List 类型：元素数量超过 5000
单个 key 占用内存超过 1MB

我们可以使用以下命令找出占用内存较大的 key：

# 使用redis-cli的--bigkeys选项
redis-cli --bigkeys

# 或者使用SCAN命令配合MEMORY USAGE
redis-cli --scan --pattern '*' | head -n 100 | xargs -I {} redis-cli memory usage {}

还可以使用 Redis 内存分析工具：

# 使用redis-memory-analyzer工具（需要单独安装）
rma -h 127.0.0.1 -p 6379 -a yourpassword --limit 100

2.2 检查内存碎片

如果 mem_fragmentation_ratio 值大于 1.5，说明内存碎片率偏高：

# 查看内存碎片率
redis-cli INFO memory | grep mem_fragmentation_ratio

高内存碎片率的情况下，可以考虑执行内存碎片整理：

# Redis 4.0以上版本支持内存碎片整理
redis-cli
127.0.0.1:6379> CONFIG SET activedefrag yes

注意：开启内存碎片整理会增加 CPU 负载，建议在业务低峰期执行，并可以配合以下参数调整碎片整理的激进程度：

# 设置碎片整理的触发阈值和CPU使用率上限
redis-cli CONFIG SET active-defrag-ignore-bytes 100mb  # 当碎片超过100MB时开始整理
redis-cli CONFIG SET active-defrag-cycle-min 25        # 最小CPU使用率25%
redis-cli CONFIG SET active-defrag-cycle-max 50        # 最大CPU使用率50%

2.3 分析数据分布

了解 Redis 中不同类型的数据占比，有助于优化数据结构：

# 统计不同类型的key数量
redis-cli
127.0.0.1:6379> INFO keyspace

例如，返回结果可能如下：

# Keyspace
db0:keys=1000,expires=500,avg_ttl=3600000
db1:keys=2000,expires=1500,avg_ttl=7200000

从上述结果可以看出：

db0 中有 1000 个 key，其中 500 个设置了过期时间，平均过期时间为 1 小时
db1 中有 2000 个 key，其中 1500 个设置了过期时间，平均过期时间为 2 小时
db0 中有 50%的 key 没有设置过期时间，如果使用 volatile-xxx 类的淘汰策略，这些 key 永远不会被淘汰

2.4 检测潜在内存泄漏

某些情况下，业务逻辑可能未正确管理 key 的生命周期，导致内存泄漏

# 扫描没有设置过期时间的key
redis-cli --scan --pattern '*' | xargs -I {} redis-cli TTL {} | grep -c -E '^-1$'

如果发现大量未设置过期时间的 key 且持续增长，可能存在内存泄漏风险。

3. 检查 Redis 配置

3.1 检查 maxmemory 配置

redis-cli CONFIG GET maxmemory

如果返回的值为 0，说明没有设置内存上限，Redis 会一直使用内存直到系统内存耗尽。

3.2 检查内存淘汰策略

redis-cli CONFIG GET maxmemory-policy

Redis 提供了多种内存淘汰策略：

noeviction：不淘汰任何数据，当内存不足时拒绝写入操作
allkeys-lru：从所有 key 中使用 LRU 算法淘汰最久未使用的 key
volatile-lru：从设置了过期时间的 key 中使用 LRU 算法淘汰（注意：如果没有设置过期时间的 key，则不会淘汰任何数据）
allkeys-random：从所有 key 中随机淘汰
volatile-random：从设置了过期时间的 key 中随机淘汰
volatile-ttl：淘汰即将过期的 key
volatile-lfu：从设置了过期时间的 key 中使用 LFU 算法淘汰（Redis 4.0 新增）
allkeys-lfu：从所有 key 中使用 LFU 算法淘汰（Redis 4.0 新增）

淘汰策略性能差异：

在 100 万 key 规模下，淘汰延迟对比：
- allkeys-random: ~0.1-0.2ms（最快，但命中率低）
- allkeys-lru: ~0.5-1ms（平衡方案，适合大多数场景）
- volatile-lru: ~0.3-0.8ms（当所有 key 都有过期时间时高效）
- allkeys-lfu: ~0.8-1.5ms（较慢，但命中率最高）

对于volatile-xxx类策略，需特别注意：若大量 key 未设置过期时间，这些策略可能完全失效，无法缓解内存压力。

对于高并发场景下的 LRU/LFU 算法，可以调整采样精度：

# 增加LRU采样精度，默认为5
redis-cli CONFIG SET maxmemory-samples 10

Redis 6.0+还提供了 LRU 采样优化参数：

Redis 6.0+还提供了 LRU 采样优化参数：

4. 检查持久化配置

持久化配置不当也会引起内存问题，特别是在执行 RDB 快照或 AOF 重写时：

4.1 检查 RDB 配置

# 查看RDB相关配置
redis-cli CONFIG GET save
redis-cli CONFIG GET stop-writes-on-bgsave-error

RDB 优化建议：

在内存紧张环境中，避免频繁触发 RDB 快照：

# 减少自动保存频率，例如只在1小时内有10000次写入时才保存
redis-cli CONFIG SET save "3600 10000"

# 禁止在后台保存出错时停止写入，防止数据丢失
redis-cli CONFIG SET stop-writes-on-bgsave-error no

4.2 检查 AOF 配置

# 查看AOF相关配置
redis-cli CONFIG GET appendonly
redis-cli CONFIG GET auto-aof-rewrite-percentage
redis-cli CONFIG GET auto-aof-rewrite-min-size

AOF 优化建议：

合理配置 AOF 重写参数，减少内存峰值：

# 当AOF文件大小增长100%且至少达到64MB时触发重写
redis-cli CONFIG SET auto-aof-rewrite-percentage 100
redis-cli CONFIG SET auto-aof-rewrite-min-size 64mb

# 使用everysec策略平衡性能和安全性
redis-cli CONFIG SET appendfsync everysec

5. 检查客户端连接情况

客户端连接过多也可能导致内存压力增大：

# 查看客户端连接情况
redis-cli INFO clients

实际案例分析

案例一：电商系统订单缓存导致的内存溢出

问题描述 :某电商平台在大促活动期间，Redis 突然出现 OOM 警告，系统响应变慢，部分订单处理失败。

排查过程

首先检查 Redis 内存使用情况：

redis-cli INFO memory

发现 Redis 已经使用了接近配置的最大内存（8GB），内存碎片率为 1.05（正常范围）。

使用 bigkeys 命令查找大 key：

redis-cli --bigkeys

结果显示存在一个特别大的 hash 结构，key 为"order_detail_cache"，占用内存接近 2GB。

进一步分析这个大 key：

redis-cli
127.0.0.1:6379> HLEN order_detail_cache
(integer) 1568342

发现该 hash 包含了近 160 万个 field，每个 field 存储了一个订单的详情信息，且大多数没有设置过期时间。

检查应用程序代码，发现在订单处理逻辑中，开发人员为了提高性能，将订单详情缓存到 Redis 中，但是只设置了写入逻辑，没有设置过期时间和清理逻辑。

解决方案

拆分大 key：将单个大 hash 拆分为多个小 hash

原先的固定分片策略可能导致分片不均，改进为直接数字取模分片：

// 修改前 - 可能导致分片不均匀
String shardKey = "order_detail_cache:" + orderId.substring(0, 2);

// 修改后 - 直接对订单ID数字取模，避免字符串哈希开销
long orderIdNum = Long.parseLong(orderId);
int shardId = (int)(orderIdNum % 64); // 分成64个分片
String shardKey = "order_detail_cache:" + shardId;
redisTemplate.opsForHash().put(shardKey, orderId, orderDetail);

设置合理的过期时间：根据业务需求，为订单缓存设置合理的过期时间：

// 设置24小时过期
redisTemplate.expire(shardKey, 24, TimeUnit.HOURS);

实现定期清理机制：对于已完成的订单，主动从缓存中删除：

// 订单完成后，主动删除缓存
redisTemplate.opsForHash().delete(shardKey, orderId);

调整内存淘汰策略：将 Redis 的内存淘汰策略从 noeviction 改为 volatile-lru，并确保所有 key 都设置了过期时间：

redis-cli CONFIG SET maxmemory-policy volatile-lru

处理突发流量：引入队列机制缓冲大促期间的突发订单写入：

// 使用消息队列缓冲订单写入操作
@Async
public void cacheOrderDetail(String orderId, OrderDetail orderDetail) {
    // 发送到消息队列，避免Redis瞬间内存暴涨
    orderCacheProducer.send(new OrderCacheMessage(orderId, orderDetail));
}

增加监控：实现对 Redis 内存使用的实时监控，当内存使用率超过 80%时触发告警，同时监控 evicted_keys 指标判断淘汰策略是否生效。

效果
实施以上措施后，Redis 内存使用量从接近 8GB 下降到稳定在 3GB 左右，系统响应速度恢复正常，大促期间再也没有出现 OOM 问题。

案例二：用户会话信息导致的内存溢出

问题描述
某 Web 应用使用 Redis 存储用户会话信息，随着用户量增长，Redis 内存使用不断增加，最终导致内存溢出。

排查过程

检查 Redis 内存使用情况：

redis-cli INFO memory

发现 used_memory 为 6GB，接近 maxmemory 配置的 7GB。

分析 key 分布情况：

redis-cli
127.0.0.1:6379> INFO keyspace

结果显示 db0 中有超过 100 万个 key，且大部分都设置了过期时间。

抽样检查几个 key 的内容：

redis-cli --scan --pattern 'session:*' | head -n 5 | xargs -I {} redis-cli MEMORY USAGE {}

发现每个会话 key 占用内存约为 5KB-10KB 不等。

检查应用代码，发现系统将完整的用户信息（包括权限列表、操作历史等）都存储在 Redis 会话中，且会话过期时间设置为 30 天。

解决方案

精简会话内容：只在 Redis 中存储必要的会话信息，其他信息按需从数据库加载：

// 修改前
SessionInfo sessionInfo = new SessionInfo();
sessionInfo.setUserInfo(userInfo);
sessionInfo.setPermissions(permissionList);
sessionInfo.setOperationHistory(historyList);
redisTemplate.opsForValue().set("session:" + sessionId, sessionInfo);

// 修改后
SessionInfo sessionInfo = new SessionInfo();
sessionInfo.setUserId(userId);
sessionInfo.setLoginTime(loginTime);
// 只保存核心会话数据
redisTemplate.opsForValue().set("session:" + sessionId, sessionInfo);

调整过期时间：根据实际业务需求，将会话过期时间从 30 天调整为 2 小时，非活跃用户需要重新登录：

// 设置2小时过期
redisTemplate.expire("session:" + sessionId, 2, TimeUnit.HOURS);

优化会话续期机制：避免频繁调用 expire 续期导致 Redis 压力过大，改为延迟续期：

// 优化后的会话续期机制
public void extendSession(String sessionId) {
    String key = "session:" + sessionId;
    // 获取当前key的剩余过期时间
    Long ttl = redisTemplate.getExpire(key, TimeUnit.MINUTES);

    // 只有当剩余时间小于30分钟时才进行续期，减少不必要的expire操作
    if (ttl != null && ttl > 0 && ttl < 30) {
        redisTemplate.expire(key, 2, TimeUnit.HOURS);
    }
}

使用 Redis 数据压缩：对会话数据进行压缩后再存储：

// 使用应用层压缩
public void saveCompressedSession(String sessionId, SessionInfo sessionInfo) {
    try (ByteArrayOutputStream baos = new ByteArrayOutputStream();
         GZIPOutputStream gzipOut = new GZIPOutputStream(baos);
         ObjectOutputStream objectOut = new ObjectOutputStream(gzipOut)) {

        objectOut.writeObject(sessionInfo);
        objectOut.flush();
        gzipOut.finish();

        // 存储压缩后的二进制数据
        redisTemplate.opsForValue().set("session:" + sessionId, baos.toByteArray());
        redisTemplate.expire("session:" + sessionId, 2, TimeUnit.HOURS);
    } catch (IOException e) {
        log.error("会话压缩失败", e);
        // 降级处理 - 存储未压缩数据
        redisTemplate.opsForValue().set("session:" + sessionId, sessionInfo);
        redisTemplate.expire("session:" + sessionId, 2, TimeUnit.HOURS);
    }
}

同时，配置 Redis 的数据结构压缩选项：

redis-cli CONFIG SET list-compress-depth 1
redis-cli CONFIG SET hash-max-ziplist-entries 512
redis-cli CONFIG SET hash-max-ziplist-value 64

效果
实施上述措施后，Redis 内存使用从 6GB 下降到 2GB 左右，系统稳定性大幅提升，用户体验基本不受影响。

Redis 内存溢出解决方案

针对 Redis 内存溢出问题，我总结了以下几类解决方案：

1. 增加内存资源

graph LR
    A[增加内存资源] --> B[增加单机Redis内存]
    A --> C[实施Redis集群]
    A --> D[使用Redis Cluster]
    A --> E[引入Redis Sentinel]

扩容 Redis 服务器：如果条件允许，可以增加 Redis 服务器的物理内存
部署 Redis 集群：将数据分散到多个 Redis 实例，降低单个实例的内存压力
使用 Redis Cluster：利用 Redis 官方的集群方案，实现数据自动分片
- 适用于：需要自动分片、高可用性、可扩展性的大规模数据场景
- 特点：去中心化架构，支持自动故障转移，数据自动分片
引入 Redis Sentinel：提高 Redis 的可用性，确保服务稳定性
- 适用于：对高可用性要求高，但不需要分片的中小规模数据场景
- 特点：主从架构，提供监控、通知、自动故障转移功能，但不提供数据分片

云环境下的优化：

AWS ElastiCache：
- 配置 VPC 流量控制，防止突发流量
- 开启集群模式自动分片
- 设置内存使用率警报阈值（通常 75%）
- 启用读取副本进行读写分离

阿里云 Redis：
- 启用弹性模式支持自动扩缩容
- 配置数据生命周期管理功能
- 利用代理集群架构降低连接压力
- 启用 DTS 实现区域级备份

2. 优化数据结构和使用方式

graph LR
    A[优化数据结构] --> B[拆分大key]
    A --> C[合理设置过期时间]
    A --> D[精简数据内容]
    A --> E[使用合适的数据类型]
    A --> F[启用数据压缩]

拆分大 key：将大的 hash、list、set 等拆分为多个小的数据结构
设置合理的过期时间：根据业务需求，为 key 设置合适的过期时间
精简数据内容：只存储必要的数据，减少冗余字段
使用合适的数据类型：根据业务场景选择最合适的 Redis 数据类型，例如：
- 统计在线用户：SET占用约 25MB/10 万用户，而BITMAP仅需约 0.6MB/10 万用户（节省 96%内存）
- 少量字段存储：对于仅 2-3 个字段的数据，直接用 STRING 存 JSON 比 HASH 更节省内存（减少哈希表元数据开销）
- 排行榜：大数据量时 ZSET 比 LIST 更节省内存且查询效率更高

启用数据压缩：针对数据压缩的两种方式：
- 应用层压缩：适用于大文本、JSON 对象、序列化对象等大值场景，使用 Gzip、Snappy 等算法
- Redis 内部压缩：针对特定数据结构的紧凑表示，如 ziplist/intset 等

拆分大 key 示例：

假设有一个存储用户点赞记录的大 hash：

HSET user:likes userId1 postId1 userId2 postId2 ... （数百万条记录）

可以拆分为多个小 hash：

HSET user:likes:0 userId1 postId1 userId2 postId2 ...（前10万条）
HSET user:likes:1 userId10001 postId1 userId10002 postId2 ...（10-20万条）
...

3. 调整 Redis 配置

设置合理的 maxmemory：根据服务器内存和业务需求，为 Redis 设置合理的内存上限
选择适当的内存淘汰策略：根据业务特点选择合适的淘汰策略
开启内存碎片整理：对于内存碎片率高的情况，开启自动碎片整理
优化持久化配置：调整 RDB 和 AOF 的配置，减少持久化对内存的影响
- RDB 优化：调整save配置减少生成快照频率，降低 fork 子进程占用内存的峰值
- AOF 优化：设置合理的auto-aof-rewrite-percentage和auto-aof-rewrite-min-size，控制重写时机

内存淘汰策略选择建议：

缓存场景：推荐使用 allkeys-lru 或 allkeys-lfu 策略
- 当 key 数量极大时(>100 万)，增加maxmemory-samples参数值提高 LRU 算法精度
会话存储：推荐使用 volatile-lru 策略（务必确保所有会话 key 都设置了过期时间）
计数器应用：推荐使用 allkeys-random 策略（随机淘汰在此场景性能最佳）
排行榜应用：推荐使用 volatile-ttl 策略（优先淘汰即将过期的数据）

4. 实现监控和预警机制

内存使用监控：实时监控 Redis 内存使用情况，设置阈值告警（建议设置在 80%左右）
大 key 监控：定期检测并告警系统中的大 key
慢查询监控：监控并优化慢查询
自动扩容策略：当内存使用率达到阈值时，自动触发扩容
淘汰监控：监控 evicted_keys 指标，判断淘汰策略是否生效
内存峰值监控：监控 used_memory_peak，防止突发流量导致内存溢出
集群状态监控：监控 cluster_nodes 和 master_link_status，避免集群问题导致单节点过载

5. 处理突发流量

对于电商促销、高峰活动等可能导致突发流量的场景：

使用消息队列：引入 Kafka 等队列系统缓冲写入操作，避免 Redis 瞬间内存暴涨
提前扩容：活动前增加 Redis 实例或调整内存配置
提高淘汰精度：临时增大 maxmemory-samples 值，提高内存淘汰精度
实施限流：对非核心业务实施写入限流，保护 Redis 服务

Redis 内存优化实用工具

redis-cli --bigkeys：查找 Redis 中的大 key
redis-memory-analyzer：分析 Redis 内存使用情况的专业工具
redis-rdb-tools：分析 RDB 文件内容，找出内存占用大的数据
RedisInsight：官方提供的 Redis 图形化管理工具，包含内存分析功能
Prometheus + Grafana：搭建 Redis 监控系统，实时监控内存使用情况

预防 Redis 内存溢出的建议

制定严格的缓存策略：

明确规定哪些数据可以缓存，哪些不可以
禁止无过期时间的 key（除非特殊审批）
建立大 key 审批机制，超过 500KB 的 key 需经过审核

设置分级过期时间：

核心业务数据：1-2 小时
非核心业务数据：5-30 分钟
统计类数据：1 天
会话数据：根据业务安全需求，通常 1-2 小时

避免存储大对象：大对象应当拆分或者压缩存储，单个 key 建议不超过 1MB
定期清理无用数据：实现定期清理机制，主动删除无用数据
做好容量规划：
- 计算公式：预计数据量 × 单个 key 平均大小 × (1 + 内存碎片率) × 冗余系数(1.3-1.5)
- 例如：100 万用户，每用户 2KB 数据，碎片率 0.2，冗余系数 1.3 = 2.6GB
规范化开发：制定 Redis 使用规范，规定 key 命名规则、数据结构选择标准等

总结

类别	方法	适用场景	实施难度	效果
资源扩展	增加单机内存	数据量适中，不适合分布式	低	短期有效
资源扩展	实施 Redis 集群	大规模数据，高可用需求	高	长期有效
数据优化	拆分大 key	存在大 key 问题	中	显著
数据优化	设置过期时间	临时数据	低	显著
数据优化	精简数据内容	数据冗余严重	中	显著
数据优化	选择合适数据类型	所有场景	低	显著
配置调整	内存淘汰策略	缓存场景	低	有效
配置调整	内存碎片整理	碎片率高	低	有效
配置调整	持久化配置优化	RDB/AOF 内存峰值高	低	有效
监控预警	内存监控告警	所有场景	中	预防性
监控预警	大 key 监控	大 key 风险高	中	预防性
突发应对	消息队列缓冲	突发流量场景	中	有效
云服务优化	自动扩缩容	云环境部署	中	高效
开发规范	缓存设计规范	开发阶段	低	长期有效

上一篇：架构师必备：高性能分布式 ID 发号器设计与实现详解

下一篇：无