Redis淘汰策略不能实现预热，因其仅在内存满时被动驱逐数据，而预热需服务启动时主动加载热点数据；二者目标相反，且预热数据若未被访问，在LFU/LRU下易被优先淘汰。
Redis 本身不直接支持“用淘汰策略实现预热”——这是个常见误解。内存淘汰策略（如 allkeys-lru、volatile-lfu）只在内存满时被动驱逐数据，而缓存预热是主动加载行为。二者目标相反：一个是“腾地方”，一个是“占位置”。想靠配置 maxmemory-policy 自动完成预热，注定失败。
为什么不能靠淘汰策略做预热
淘汰策略触发前提是 used_memory 达到 maxmemory 上限，此时 Redis 才开始按规则删 key。但预热需要的是：服务刚启动时、流量进来前，就把热点数据塞进去。等内存满了再“淘汰冷数据”，说明预热已经晚了——用户请求早就打到数据库上了。
更麻烦的是，LFU/LRU 的统计依赖真实访问，没被访问过的 key 在 LFU 计数器里是 0，在 LRU 链表里排末尾，一上来就被优先淘汰。你辛辛苦苦 SET 进去的预热数据，可能刚写完就被 allkeys-lfu 当成“零访问”给踢了。
-
volatile-ttl只淘汰带过期时间的 key，预热数据若没设 TTL 就完全不受影响，但也没法“主动升温” -
allkeys-random完全无序，预热数据存活率纯看运气 - 哪怕用了
allkeys-lru，新写入的 key 时间戳最新，短期不会被淘汰，但这不是“智能预热”，只是侥幸存活
真正能联动淘汰与预热的实操点
预热和淘汰可以协同，但必须靠人工设计逻辑，不是靠 Redis 自动关联。关键在于让预热数据“值得留下”：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 预热时统一加
EX或PEX，确保所有预热 key 都走volatile-lfu或volatile-lru路径，避免被allkeys-*策略误伤 - 用
OBJECT FREQ手动检查预热 key 的 LFU 计数，确认是否被真实访问过；没访问过就手动INCRBY模拟热度（仅调试用，生产慎用） - 配合
redis-cli --scan+GET批量触发访问，把预热 key “刷热”，让 LFU 计数上升，降低后续被淘汰概率 - 对核心预热数据，用
MEMORY USAGE估算其内存占比，确保maxmemory留足余量，别让预热一完成就立刻触发淘汰
Spring Boot 中预热 + 淘汰策略的实际配合方式
在 Java 生态里，预热通常发生在 ApplicationRunner 或 @PostConstruct 阶段，这时要明确区分“预热数据”和“运行时缓存数据”：
- 预热数据建议用独立前缀，比如
hot:product:1001，方便后续监控或清理；不要和业务缓存混用同一命名空间 - 在
RedisCacheConfiguration里为预热 cache 单独配entryTtl，比如Duration.ofHours(24)，避免和短 TTL 的业务缓存冲突 - 如果用
allkeys-lfu，务必在预热后调用一次redisTemplate.opsForValue().get(...)触发访问，否则这些 key 的 LFU 计数仍是 0，下次内存压力一大就会最先被淘汰 - 不要依赖
@Cacheable注解自动完成预热——它只响应请求，属于被动加载，和预热定义相悖
容易被忽略的细节
多实例部署下，每个节点都执行相同预热逻辑，会导致重复写入甚至数据不一致；而用 Lua 脚本或分布式锁控制预热入口，又引入额外复杂度。更现实的做法是：只在主节点预热，从节点靠复制同步——但这要求 Redis 是主从模式且复制延迟可接受。如果用 Redis Cluster，预热必须按 slot 分片手动路由，redis-cli --cluster 工具不支持批量预热，得自己拆 key 做哈希分发。
