Redis内存淘汰策略：从OOM崩溃到丝滑运行的终极指南

Redis内存淘汰策略：从OOM崩溃到丝滑运行的终极指南

凌晨三点，报警短信炸裂："Redis OOM！"你颤抖着手点开监控------那条该死的缓存曲线像吃了伟哥一样直冲云霄... 别慌！今天我们就给Redis的内存管理来场"外科手术"

一、引言：当Redis内存开始"吃紧"

想象Redis是个超级仓库管理员（内存），你的数据是货物（键值对）。当仓库堆满时，管理员该怎么办？

1. 佛系管理员 ：直接摆烂"仓库满了，新货别来了！"（noeviction）
2. 时间管理大师 ：优先扔掉快过期的货物（volatile-ttl）
3. 精准打击专家 ：按"最近使用频率"精准淘汰（LFU）
4. 怀旧派选手 ：扔掉最久没碰的货物（LRU）

Redis内存淘汰的本质是：在内存不足时，按特定策略删除键以释放空间

二、8大内存淘汰策略详解

策略	特点	适用场景
noeviction	新写入报错，读正常	关键数据不允许丢失
allkeys-lru	全体键中淘汰最近最少使用的键	通用场景，热点数据明显
volatile-lru	仅淘汰带过期时间的LRU键	混合数据集（永久+临时）
allkeys-lfu	全体键中淘汰最不经常使用的键	访问频率差异大的场景
volatile-lfu	仅淘汰带过期时间的LFU键	临时数据且访问频率差异大
volatile-ttl	淘汰即将过期的键（剩余TTL最小）	时效性敏感数据（如验证码）
volatile-random	随机淘汰带过期时间的键	临时数据无明确规律
allkeys-random	全体键中随机淘汰	极端情况（慎用）

三、配置实战：给Redis穿上"救生衣"

# redis.conf 关键配置
maxmemory 2gb  # 最大内存限制
maxmemory-policy allkeys-lru  # 使用allkeys-lru策略
maxmemory-samples 10  # LRU/LFU算法采样精度

Java代码实战：Spring Boot中模拟淘汰过程

@SpringBootTest
public class RedisEvictionTest {

    @Autowired
    private RedisTemplate<String, String> redisTemplate;

    /**
     * 模拟内存淘汰场景
     * 步骤：1. 疯狂插入数据直到OOM 2. 观察淘汰行为
     */
    @Test
    public void testAllkeysLruEviction() throws Exception {
        final String KEY_PREFIX = "product:";
        int i = 0;
        
        try {
            // 持续插入数据直到触发淘汰
            while (true) {
                String key = KEY_PREFIX + (++i);
                redisTemplate.opsForValue().set(key, "Data-".concat(UUID.randomUUID().toString()));
                // 每100条读取一次旧数据，模拟热点访问
                if (i % 100 == 0) {
                    redisTemplate.opsForValue().get(KEY_PREFIX + ThreadLocalRandom.current().nextInt(1, i/2));
                }
                if (i % 1000 == 0) {
                    System.out.println("已插入: " + i + "条记录");
                }
            }
        } catch (RedisSystemException e) {
            System.err.println("触发内存限制: " + e.getMessage());
        }

        // 验证淘汰效果
        Long surviveCount = redisTemplate.execute((RedisCallback<Long>) conn -> conn.dbSize());
        System.out.println("淘汰后剩余键数量: " + surviveCount);
        
        // 检查早期键是否被淘汰
        boolean earlyKeyExists = redisTemplate.hasKey(KEY_PREFIX + 1);
        System.out.println("最早插入的键是否存在: " + (earlyKeyExists ? "存在" : "被淘汰"));
    }
}

四、原理深潜：LRU/LFU的魔法是如何炼成的？

1. Redis的LRU：精妙的时间采样

// Redis对象头存储LRU时钟 (redisObject.h)
typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    unsigned lru:LRU_BITS;  // 24位LRU时间戳
    int refcount;
    void *ptr;
} robj;

Redis的LRU不是传统双向链表，而是基于采样的近似LRU：

1. 每次访问键时更新lru字段为当前全局LRU时钟
2. 淘汰时随机选maxmemory-samples个键
3. 淘汰这组样本中lru最小的键（最久未使用）

📌 为什么不用真LRU？

真LRU需要维护链表，每个访问都要调整指针------内存和CPU双重暴击！

采样LRU用少量精度损失换巨大性能提升（配置maxmemory-samples 10时效果接近真实LRU）

2. LFU：频率统计的智慧

// LFU实现复用lru字段
//         16 bits      8 bits
//     +----------------+--------+
//     + Last decr time | LOG_C  |
//     +----------------+--------+

LFU计数器组成：

• 高16位：最后递减时间戳（分钟级精度）
• 低8位 ：对数计数器（LOG_C）

核心机制：

1. 计数器增长 ：p = 1.0/(counter*server.lfu_log_factor + 1) 概率增加
2. 定期衰减 ：若键N分钟未访问，counter -= (counter*lfu_decay_time)

🔥 冷知识：LFU计数器最大255（8位上限），通过概率增加避免快速饱和

五、避坑指南：血泪换来的经验

1. 巨坑1：未设置过期时间导致永久堆积

   // 错误示范：未设置过期时间
   redisTemplate.opsForValue().set("user:1000", userInfo);
   
   // 正确姿势：必须设置过期时间！
   redisTemplate.opsForValue().set("user:1000", userInfo, 30, TimeUnit.MINUTES);

2. 巨坑2：volatile策略遇到无过期时间的键

   • 当使用volatile-*策略时，无过期时间的键永远不会被淘汰！
   • 解决方案：要么用allkeys-*，要么给所有键加过期时间

3. 巨坑3：LFU计数器初始化问题

   • 新键初始计数=5（默认），可能被高频旧键秒杀
   • 调优：lfu-log-factor降低增长难度，lfu-decay-time控制衰减速度

六、最佳实践：让Redis内存稳如泰山

1. 监控指标三剑客：

   > redis-cli info memory
   used_memory_human：当前内存用量
   mem_fragmentation_ratio：碎片率（>1.5需警惕）
   evicted_keys：累计淘汰键数（突然增长是报警信号！）

2. 动态调整策略：

   // 运行时动态修改策略（Jedis示例）
   Jedis jedis = pool.getResource();
   jedis.configSet("maxmemory-policy", "allkeys-lfu");
   jedis.configRewrite(); // 持久化到配置文件

3. 内存优化组合拳：

   # 配置示例：综合优化
   maxmemory 4gb
   maxmemory-policy allkeys-lfu
   maxmemory-samples 10
   lfu-log-factor 10   # 控制计数器增长速度
   lfu-decay-time 1    # 每分钟未访问则计数器衰减

七、面试核武器：高频考点解析

Q1：Redis的LRU和传统LRU有什么区别？

答：Redis使用近似LRU算法，通过随机采样（默认5键）淘汰最久未使用的键。相比双向链表实现的真LRU，节约内存且避免写操作时链表的全局锁竞争。

Q2：LFU的计数器为什么设计成对数增长？

答：防止高频访问使计数器快速饱和（上限255）。对数增长保证：访问1万次的键不会比访问100次的键高出100倍计数，避免"历史热键"长期霸占内存。

Q3：线上Redis突然开始大量淘汰键，如何定位？

诊断路线：

1. info stats查看evicted_keys变化速率
2. monitor命令抓取大key（注意性能影响）
3. 检查是否接近maxmemory阈值
4. 确认是否切换淘汰策略或流量突增

八、总结：内存管理的艺术

• 策略选择黄金法则：

  • 优先 allkeys-lru（通用场景）
  • 强时效数据用 volatile-ttl
  • 热点分化明显用 allkeys-lfu

• 永远记住：

  ❗ 不给键设过期时间 → volatile策略失效 → 内存泄漏！

  ❗ 不设置maxmemory → 内存撑爆 → 进程被OOM Killer干掉！

  ❗ 不监控evicted_keys → 业务雪崩 → 年终奖泡汤！

最后送大家一道护身符：

# 生产环境必备配置
maxmemory 16gb  # 必须设置为物理内存的3/4！
maxmemory-policy allkeys-lfu
maxmemory-samples 10
save ""  # 关闭RDB节省内存（根据业务权衡）

通过这篇指南，你已获得Redis内存管理的"屠龙宝刀"。下次再遇OOM报警，微微一笑：不过是淘汰策略调参的小游戏罢了！