想象一下，你的Redis服务器是一个合租宿舍，内存就是床位。当新数据（新室友）要住进来，但床位已满时，你作为宿管（淘汰策略）必须决定：让谁卷铺盖走人？

Redis提供了8种"劝退"方案，堪称内存管理界的《甄嬛传》：

1. noeviction（佛系躺平）："床位满了？新来的在门口等着吧！"（直接报错，适合宁可系统崩溃也不妥协的硬核玩家）
2. allkeys-lru（时间管理大师）：淘汰最近最少使用的键（LRU算法），像极了微信里只删三个月不联系的好友
3. volatile-lru（精准打击）：只淘汰设置了过期时间的键中的LRU，相当于只赶走租期快到的人
4. allkeys-random（俄罗斯轮盘赌）：随机淘汰，建议改名叫"老板键"，随时可能丢失重要数据
5. volatile-random（薛定谔的驱逐）：随机淘汰带过期时间的键，连Redis自己都不知道下一秒谁会消失
6. volatile-ttl（死神来了）：优先淘汰剩余寿命最短的键，专治那些设了过期时间却赖着不走的钉子户
7. volatile-lfu（势利眼模式）：淘汰使用频率最低的过期键，像极了只捧当红流量的娱乐圈
8. allkeys-lfu（社达主义）：无差别淘汰最不常用的键，哪怕它是永久居民

灵魂拷问：你的缓存数据是"临时工"（带TTL）还是"正式员工"（永久键）？这直接决定了该用volatile还是allkeys系列策略！

二、触发淘汰时，Redis的"内心戏"有多复杂？

当used_memory > maxmemory时，Redis会开启它的"生存游戏"。但你以为选个策略就完事了？Too young！

那些年我们踩过的坑：

1. 缓存击穿+雪崩豪华套餐：
2. 如果大量永久键（allkeys-xx）突然被集中淘汰，相当于把宿舍老住户全赶走，新请求直接穿透到数据库
3. 随机策略（*-random）可能在流量高峰时误杀热门数据，引发连锁雪崩
4. LRU的"代沟"问题：
   Redis的LRU是近似算法（采样5个键选最久未使用的），就像让近视眼找钥匙——可能误判。极端情况下，真正的热点数据可能被误删！
5. LFU的内存刺客：
   LFU（最不常用）需要维护使用频率计数器（8位记录，最大值255）。如果某个键突然被疯狂访问（比如爆款商品），之后长期不用，它就会像过气网红一样霸占着位置不离开。

三、底层数据结构：Redis的"省内存七十二变"

你以为Redis只会无脑淘汰数据？它还是个内存压缩大师！同样的数据，在不同编码下内存占用可能相差10倍！

数据结构与编码的"变形记"：

冷知识：用OBJECT ENCODING key可以查看某个键的底层编码，像X光一样看透Redis的小心思！

四、优化宝典：让Redis告别"996"

1. 策略选择心法：

• 宁可错杀一千（allkeys-lru）：适合缓存系统，反正数据都能从DB回源
• 精准外科手术（volatile-ttl）：适合混合使用持久化+缓存数据的场景

2. 内存优化骚操作：

• 给ziplist"开小灶"：调整hash-max-ziplist-entries 512（默认值），让更多Hash类型使用压缩列表
• intset的数学之美：确保Set中的元素都是整数，轻松省下50%内存
• 序列化黑科技：用MessagePack代替JSON，String类型立马瘦身

3. 防雪崩三件套：

• 过期时间加随机抖动：EXPIRE key 3600 + rand(0,300) 避免集体过期
• 永不过期的保底数据：对核心数据设置allkeys-lfu而不是noeviction
• 双层缓存战术：本地缓存（Caffeine）+ Redis，双重保险防穿透

五、经典误区：查询不触发淘汰？错！但有个前提...

官方教科书答案：
Redis淘汰策略仅在写入操作时触发（如SET/HSET/LPUSH等），查询本身不会触发淘汰。
但现实打脸现场：

“我明明只是疯狂查数据，Redis内存却狂飙，淘汰数暴涨！”

真相只有一个：
查询只是背锅侠，幕后黑手另有其人！

六、幕后黑手TOP5：谁在偷偷搞事情？

1. 伪装成“纯查询”的写操作（经典老六行为）

某些看似无害的查询命令，实则是披着羊皮的狼：

案例重现：

# 你以为的“查询”：  
127.0.0.1:6379> SORT hot_list STORE sorted_list  # 悄咪咪创建新键，触发淘汰！  

诊断方案：

• 用SLOWLOG GET检查慢查询日志
• 使用MONITOR命令实时监控所有操作

2. 内存碎片暴击（Redis的“隐形内存刺客”）

内存碎片率（mem_fragmentation_ratio）>1.5时：

• 物理内存被割裂成碎片 → 实际可用内存减少
• 写入时发现“看似够用，实则不足” → 被迫淘汰数据

可视化比喻：

内存就像停车场，明明总车位足够，但都被摩托车占成了碎片，新来的汽车死活停不进！

急救方案：

# 查看内存碎片率  
127.0.0.1:6379> INFO MEMORY  
# 开启自动碎片整理（Redis 4.0+）  
CONFIG SET activedefrag yes  

3. 过期键的“回光返照”（查询引发的连环血案）

Redis的惰性删除机制：

• 查询某个键时，若发现已过期 → 立即删除
• 大量查询过期键 → 频繁删除释放内存 → 后续写入可能重新占满内存 → 触发淘汰

经典场景：

• 缓存雪崩后，大量请求查询已过期的热点数据
• 每次查询导致删除旧键 → 新写入立刻补位 → 内存过山车式波动

避坑指南：

• 对过期时间添加随机抖动：EXPIRE key 3600 + $(shuf -i 0-600 -n 1)
• 使用volatile-ttl策略优先淘汰即将过期的键

4. 后台进程的“暗度陈仓”（持久化挖的坑）

RDB/AOF持久化时：

• BGSAVE或BGREWRITEAOF创建子进程 → 写时复制（Copy-On-Write）占用额外内存
• 内存临时暴涨 → 触发淘汰策略

血泪教训：

某电商大促期间，查询量激增触发AOF重写，导致内存翻倍，淘汰数飙升！

应急预案：

• 关闭持久化：CONFIG SET save ""（仅限纯缓存场景）
• 使用内存监控工具设置报警阈值

5. 配置的“神补刀”（自己挖坑自己跳）

作死操作三件套：

1. 动态调低maxmemory：CONFIG SET maxmemory 2GB（原内存已3GB → 立即触发淘汰）
2. 误用allkeys-*策略：永久键被误杀 → 缓存穿透 → 数据库压力激增
3. 禁用交换分区（swap）：物理内存硬耗尽 → Redis进程被OOM Killer杀死

保命配置：

bash

# 预留20%内存缓冲  
CONFIG SET maxmemory 16GB  # 当物理内存为20GB时  
# 优先使用volatile-*策略  
CONFIG SET maxmemory-policy volatile-lru  

七、终极思考：你的Redis是"打工人"还是"过劳死"？

下次当你看到Redis内存使用量上下波动时，不妨想象这样的场景：

• 一个ziplist编码的Hash键正在努力蜷缩身体，试图留在压缩列表的舒适区
• 某个长期未被访问的Key，在LRU算法的注视下瑟瑟发抖
• LFU计数器在每次访问时默默+1，仿佛在说："看到没？我还有人用！"