ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花

Redis内存不足（OOM）是生产环境高频故障，轻则导致写入失败、缓存击穿，重则引发服务雪崩、数据丢失。处理核心原则：先紧急止损稳住业务，再定位根源，最后通过配置、数据、架构三层优化根治，搭配监控预防复发，避免盲目扩容治标不治本。

一、紧急止损：3步快速缓解OOM，避免业务雪崩

此阶段核心是快速释放内存、恢复服务可用性，适用于线上突发OOM场景，操作无侵入且可快速回滚。

1. 临时调整内存淘汰策略（兜底首选）

Redis默认不开启主动淘汰（noeviction），内存占满后直接拒绝写入，需快速切换适配业务的淘汰策略，通过命令临时生效（重启后失效，后续需固化到配置文件）。

• 缓存业务（允许数据丢失）：优先用 allkeys-lru（删除全量键中最近最少使用的数据），适配绝大多数缓存场景
• 带过期时间的缓存：用 volatile-lru（仅删除带TTL的最近最少使用键，保留永久键）
• 高频访问业务：用 allkeys-lfu（删除最少使用频率键，命中率更高）
• 临时执行命令：redis-cli config set maxmemory-policy allkeys-lru

2. 临时扩容内存上限

若服务器物理内存充足，直接调高Redis最大内存限制，缓解瞬时压力，命令：redis-cli config set maxmemory 16G（根据服务器剩余内存合理设置，预留20%系统内存）。

3. 暂停高危操作+清理无效数据

• 暂停批量导入、大Key写入、全量缓存刷新等操作，减少内存瞬时暴涨
• 快速清理确认无用的测试数据、过期日志键、历史缓存，命令：redis-cli KEYS "prefix:*" | xargs redis-cli DEL（慎用KEYS，生产建议用SCAN）

紧急操作仅为临时兜底，不可长期依赖，必须尽快排查内存暴涨根源，否则OOM会反复出现。

二、根源排查：定位内存占用元凶

通过Redis内置命令和工具，精准定位内存占用高的核心原因，避免盲目优化。

1. 查看内存核心指标（基础排查）

执行 redis-cli info memory，重点关注以下字段：

• used_memory：Redis实际使用内存
• used_memory_peak：内存峰值（判断是否瞬时暴涨）
• maxmemory：配置的最大内存上限
• mem_fragmentation_ratio：内存碎片率（大于1.5说明碎片严重，占用额外内存）
• expired_keys：过期键数量（过期键未回收会堆积内存）

2. 排查大Key（内存占用重灾区）

大Key（单个键占用内存超100MB）是内存暴涨的核心原因，Redis自带工具快速定位：

• 一键扫描大Key：redis-cli --bigkeys（输出各类数据类型的最大键，含占用内存）
• 精准查询单键内存：redis-cli memory usage key名

3. 排查其他内存占用根源

• 过期键未回收：Redis惰性删除+定期删除机制，若过期键堆积，执行 redis-cli memory purge 强制清理
• 内存碎片过高：Redis 4.0+支持主动碎片整理，碎片率超1.5需开启优化
• 持久化开销：RDB/AOF重写、子进程会占用额外内存，导致内存瞬时超标
• 客户端缓冲区溢出：大量慢连接、批量查询占用输出缓冲区内存

三、深度优化：根治内存占用问题

从配置、数据、持久化三层入手，降低内存消耗，从根源解决OOM。

1. 配置层优化（永久生效，修改redis.conf）

• 固化内存淘汰策略：设置 maxmemory-policy allkeys-lru，根据业务选择适配策略
• 合理设置maxmemory：单机Redis预留20%系统内存，比如32G服务器设为25G，避免抢占系统内存
• 开启内存碎片整理：新增配置 active-defrag yes、active-defrag-threshold-lower 10、active-defrag-threshold-upper 100，自动清理碎片
• 优化客户端缓冲区：限制客户端连接数和缓冲区大小，避免恶意连接占用内存

2. 数据层瘦身（核心优化，降内存效果最明显）

• 拆分大Key：把超大Hash/List/Set拆分为多个小键，比如按用户ID、时间分片存储
• 精简键值结构：缩短键名、压缩值内容；用Hash、ZSet替代纯字符串存储批量数据，开启ziplist压缩编码（配置 hash-max-ziplist-entries 512、hash-max-ziplist-value 64）
• 规范过期时间：所有缓存键必须设置TTL，避免永久键堆积；缩短冷数据过期时长，定期清理无效数据
• 冷热数据分离：热数据留在Redis，冷数据迁移到MySQL、MongoDB等磁盘存储，按需加载

3. 持久化优化（减少内存额外开销）

• 开启 no-appendfsync-on-rewrite yes，AOF重写期间暂停fsync，降低内存和IO压力
• 调整RDB持久化时机，避开业务高峰期，避免子进程重写占用大量内存

四、架构扩容：突破单机内存极限

若单机优化后仍无法满足内存需求，通过架构扩容水平扩展，彻底解决内存瓶颈。

• Redis Cluster集群：官方集群方案，数据分片存储到多个节点，突破单机内存限制，支持动态扩容节点
• 主从+哨兵架构：读写分离，主节点负责写入，从节点分担读取压力，搭配集群分片提升总内存容量
• 多实例部署：单服务器部署多个Redis实例，拆分不同业务缓存，避免单实例内存过载

五、长效监控与预防：杜绝OOM复发

• 搭建监控告警：监控used_memory、mem_fragmentation_ratio、大Key数量、过期键堆积量，内存占用达80%提前告警
• 定期巡检：每周扫描大Key、清理无效数据、评估内存碎片，提前优化
• 规范开发规范：禁止无TTL键、禁止超大Key写入、禁止批量全量刷新缓存

总结：Redis OOM处理闭环=紧急止损（救业务）→根源排查（找问题）→三层优化（治根本）→架构扩容（破极限）→监控预防（防复发），兼顾短期应急和长期稳定。

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花