redis集群不支持冷热数据自动分离，需业务层或外部组件实现；lfu仅用于内存淘汰，不能识别冷数据并迁移；真正自动路径依赖访问行为分析与外部钩子联动。
Redis 集群本身不支持冷热数据自动分离——无论你用的是 Redis 6.2 还是 7.0，CLUSTER KEYSLOT 哈希路由逻辑对所有 key 一视同仁，不会因为访问频次、TTL 长短或 value 大小做任何区分。所谓“自动”，必须靠业务层显式介入，或引入外部组件兜底。
Redis 7.0 的 LFU 淘汰策略 ≠ 冷热分离能力
很多人看到 Redis 7.0 支持 maxmemory-policy allkeys-lfu 就以为能“自动识别冷数据并迁移”，这是误解。LFU 只控制内存满时删谁，不控制写入时存哪，也不触发跨节点/跨存储的移动动作：
-
LFU是被动淘汰机制，只在maxmemory触发后起作用；冷数据若长期没被访问，可能早被删了，但根本没机会“归档” - 集群中每个 master 节点独立执行 LFU，无法协同判断“这个 key 在整个集群里是不是真冷”
- LFU 计数器本身占内存（每个 key 多 1–2 字节），对亿级 key 量级的集群，反而增加内存开销
- 它不产生任何事件通知，无法联动外部存储做归档；你不能监听 “key 被 LFU 淘汰了” 然后去存到 S3
真正可行的“自动”路径：基于访问行为 + 外部钩子
所谓“自动”，本质是把冷热判定逻辑从人工配置转移到运行时行为分析，并通过可扩展机制触发后续动作。RQ、Celery 或自研中间件是更现实的载体：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在应用层埋点：对关键 key 的
GET/HGET加计数器（如用INCR hot:counter:{key}），每小时聚合一次，access_count 的 key 标记为潜在冷数据 - 用 Redis 的
KEYS或SCAN扫描带特定前缀（如cache:user:）的 key，再批量查PTTL和MEMORY USAGE，筛出低频+大体积+长 TTL 的组合 - 借助
redis-cli --hotkeys（仅限单节点）或redis-exporter + Prometheus抓取evicted_keys、expired_keys、keyspace_hits/misses指标，用 Grafana 做冷热分布看板 - 一旦识别出冷数据，调用脚本执行：
GET→SET到冷集群（或外部对象存储）→DEL（或EXPIRE 1强制过期）→ 记录归档日志
结合外部存储时，必须绕开集群的 CROSSSLOT 限制
如果你打算把冷数据导出到 S3、MySQL 或本地文件，最常踩的坑是：在集群模式下直接对多个 key 执行跨槽操作，报错 CROSSSLOT Keys in request don't hash to the same slot：
- 禁止在 Lua 脚本里用
redis.call("GET", k1, k2)同时读多个 key——哪怕它们是同一类冷数据，只要 hash 槽不同就失败 - 正确做法是：先用
CLUSTER KEYSLOT {key}算出每个 key 所属槽位，按槽分组，再对每组发起 pipeline 请求 - 归档脚本必须支持断点续传：记录已处理的 key 游标（
SCAN的 cursor）、成功上传的 ETag、失败重试次数，避免重复导出或漏导 - 冷数据元信息（如
archived_at、storage_uri）建议仍存在热集群中，用短 TTL（如 7 天），避免归档后完全丢失索引
真正的难点不在技术实现，而在于冷数据识别的“时机”和“粒度”：业务写入时就知道某条订单详情是冷的，那就该在 SET 前就路由到冷池；如果等它变成冷的再迁移，往往已经占了热集群几 GB 内存，且迁移过程本身就会打满带宽和 CPU。所以冷热分离不是后期运维手段，而是数据生命周期设计的第一环。
