Redis内存满了怎么办？
Redis内存满了怎么办？从过期策略到淘汰机制，一篇讲透
摘要：Redis作为高性能内存数据库，内存资源是有限的。当Redis内存使用达到上限（maxmemory）时，会发生什么？如何避免OOM？本文将深入剖析Redis的过期键删除策略、内存淘汰机制，并给出生产环境的最佳实践配置。
1. 前言：为什么Redis需要管理内存？
Redis将所有数据存储在内存中，以换取极高的读写速度。但内存成本高、容量有限，如果不加控制，恶意写入或业务增长都可能导致内存耗尽，进而引发服务崩溃或被操作系统OOM Killer杀掉。
因此，合理设置内存上限并配置淘汰策略，是Redis生产环境必备的稳定性手段。
2. 设置内存上限：maxmemory
在redis.conf或通过CONFIG SET动态配置：
# 设置最大内存为4GB（单位可以是bytes, kb, mb, gb）maxmemory 4gb- 64位系统默认
maxmemory=0，表示无内存限制（可能导致内存无限增长，最终被系统kill）。 - 建议值：物理内存的3/4，剩余留给操作系统和子进程（如RDB/AOF重写）。
- 32位系统最大支持3GB，默认
maxmemory=3GB。
3. Redis的过期键删除策略
当键设置了过期时间（TTL），Redis如何删除它？实际采用的组合是：定期删除 + 惰性删除。（注意：并没有使用“定时删除”，因为创建大量定时器会严重影响性能。）
下面分别说明三种理论策略，并指出Redis的实现选择。
3.1 三种删除策略对比
| 策略 | 原理 | 优点 | 缺点 | Redis采用？ |
|---|---|---|---|---|
| 定时删除 | 设置键过期时创建一个定时器，到期立即删除 | 内存友好，及时释放 | CPU开销大，大量定时器影响性能 | ❌ 不采用 |
| 惰性删除 | 访问键时检查是否过期，过期则删除 | CPU友好，只在实际访问时检查 | 可能长期占用内存（过期但一直未访问的key） | ✅ 采用 |
| 定期删除 | 每隔一段时间（默认100ms）随机抽样过期key并删除 | 平衡CPU与内存 | 仍有部分过期key残留 | ✅ 采用 |
3.2 Redis实际工作流程
关键点：
- 定期删除：默认每秒执行10次（可通过
hz参数调整），每次随机抽取一批设置了过期时间的key，删除其中过期的。不会全量扫描，避免阻塞主线程。 - 惰性删除：当客户端读取key时，先检查是否过期，过期则删除并返回空。
- 两者配合：定期删除清理大部分过期key，惰性删除兜底。但仍有极端情况：一些过期key从未被访问且定期删除未抽中，会长期占用内存 → 此时需要内存淘汰机制兜底。
4. 内存淘汰机制：最后的防火墙
当maxmemory达到上限后，Redis会根据配置的淘汰策略来腾出空间给新写入。这是内存快满时的“紧急通道”。
4.1 触发时机
每次执行命令（如set、lpush等）导致内存增加时，检查是否超过maxmemory。若超过，则按照所选策略逐出一些key，直到内存低于上限。
4.2 八种淘汰策略（Redis 4.0+）
| 策略 | 作用范围 | 行为描述 |
|---|---|---|
noeviction | 所有key | 内存满时写入操作返回错误（默认策略） |
allkeys-lru | 所有key | 使用LRU算法淘汰最近最少使用的key |
volatile-lru | 设置了过期时间的key | 在有过期时间的key中淘汰LRU的key |
allkeys-lfu | 所有key | 使用LFU算法淘汰最不经常使用的key（Redis 4.0新增） |
volatile-lfu | 设置了过期时间的key | 在有过期时间的key中淘汰LFU的key |
allkeys-random | 所有key | 随机淘汰 |
volatile-random | 设置了过期时间的key | 在有过期时间的key中随机淘汰 |
volatile-ttl | 设置了过期时间的key | 淘汰剩余TTL最短的key |
LRU：Least Recently Used，最近最少使用
LFU：Least Frequently Used，最不经常使用（访问频率）
4.3 LRU/LFU近似算法
Redis并没有采用精确的全局LRU（太耗内存），而是近似LRU：
- 随机采样N个key（默认
maxmemory-samples 5），淘汰其中空闲时间最长的。 - 采样数越大，淘汰越精确，但CPU开销越大。
4.4 如何选择淘汰策略？
| 场景 | 推荐策略 |
|---|---|
| 缓存场景（数据可从DB重建） | allkeys-lru或allkeys-lfu |
| 部分数据不能淘汰（如用户会话） | volatile-lru，并只给可淘汰的key设置过期时间 |
| 有冷热数据明显区分 | allkeys-lfu |
| 无任何数据可淘汰，宁可写失败 | noeviction（金融/强一致性场景慎用） |
5. 配置与监控
5.1 动态配置淘汰策略
# 设置淘汰策略redis-cli configsetmaxmemory-policy allkeys-lru# 设置内存上限redis-cli configsetmaxmemory 8gb# 设置LRU采样数量（可选）redis-cli configsetmaxmemory-samples105.2 监控内存状态
redis-cli info memory重点关注：
used_memory_human：实际使用内存maxmemory_human：配置上限mem_fragmentation_ratio：碎片率（>1.5需关注）evicted_keys：因内存淘汰被删除的key总数
5.3 最佳实践建议
- 生产环境务必设置
maxmemory，建议为物理内存的70%~80%（留出内存给系统及fork子进程）。 - 默认策略是
noeviction，不做配置会导致内存满后写失败，业务异常。应根据场景显式配置。 - 给key合理设置过期时间，配合
volatile-*策略更灵活。 - 调高采样数（如10）提升LRU/LFU精度，但增加CPU消耗。
- 监控
evicted_keys，如果淘汰频繁，说明内存不足或过期时间设置不合理，需扩容或优化数据。
6. 完整流程图：从写入到淘汰
7. 总结
| 机制 | 作用 | 触发时机 |
|---|---|---|
| 定期删除 | 主动清理过期key | 每100ms一次 |
| 惰性删除 | 访问时删除过期key | 每次读/写该key |
| 内存淘汰 | 内存达到maxmemory后强制逐出 | 每次写操作前 |
Redis通过定期+惰性组合高效清理过期数据，再通过内存淘汰机制作为最后防线，确保内存不会越界。合理配置maxmemory和maxmemory-policy，配合监控告警，才能让Redis稳定运行在高压力之下。
一句话记忆：定期清、惰性删、满则逐（LRU/LFU），三管齐下保平安。