如何保证Redis中存储的是热点数据（100万数据选20万）

如何保证Redis中存储的是热点数据（100万数据选20万）

核心思路

在数据库有100万数据但Redis只能存20万的情况下，我们需要确保Redis缓存的是最常被访问的数据（热点数据）。

️ 解决方案

1. LRU缓存淘汰策略（最常用）

# Redis配置
maxmemory 2GB          # 设置最大内存
maxmemory-policy allkeys-lru  # 使用LRU淘汰策略

工作原理：

• Redis会自动淘汰最近最少使用的键
• 热点数据会被保留，冷数据被淘汰

2. LFU策略（Redis 4.0+）

maxmemory-policy allkeys-lfu  # 使用LFU（最不经常使用）策略

优势：

• 不仅考虑最近使用时间，还统计访问频率
• 更适合长期热点数据识别

3. 多级缓存方案

用户请求 → 布隆过滤器 → Redis热点缓存 → 数据库

4. 主动预热+监控

// 示例：监控并预热热点数据
public void preheatHotData() {
    // 1. 从数据库统计最近24小时访问量TOP 20万
    List<HotItem> hotItems = database.queryTopItems(200000);
    
    // 2. 批量加载到Redis
    hotItems.forEach(item -> 
        redisTemplate.opsForValue().set(item.key, item.value));
}

5. 时间窗口计数法

// 使用Redis的INCR记录访问次数
public void recordAccess(String key) {
    // 记录键的访问次数
    redisTemplate.opsForValue().increment("access:" + key);
    
    // 定期（如每小时）整理热点数据
    if(System.currentTimeMillis() % 3600000 == 0) {
        // 获取访问量TOP 20万的键
        Set<String> hotKeys = getTopKeys(200000);
        // 更新热点缓存...
    }
}

数据筛选策略对比

策略	优点	缺点	适用场景
LRU	实现简单，内存友好	可能误判突发流量	通用场景
LFU	识别长期热点更准	内存消耗稍大	热点稳定场景
主动预热	精确控制缓存内容	需要额外开发	已知热点分布
时间窗口	实时性高	实现复杂	访问模式变化快

最佳实践建议

1. 组合使用策略：LRU/LFU + 定时任务预热

2. 监控缓存命中率：

   redis-cli info stats | grep keyspace_misses
   redis-cli info stats | grep keyspace_hits
   

3. 设置合理的TTL：即使热点数据也设置过期时间，避免脏数据

4. 考虑分片：如果单Redis实例不够，可以按业务分片存储

⚠️ 常见误区

• ❌ 把所有数据都设置相同的TTL（会导致缓存雪崩）
• ❌ 完全依赖自动淘汰策略（某些场景需要主动干预）
• ❌ 忽略缓存穿透问题（对不存在的key也要做短时间缓存）

小技巧：可以使用redis-cli --hotkeys命令（Redis 4.0+）快速找出当前热点键