redis集群不支持冷热数据自动分离，需业务层通过key前缀、独立连接池或自定义槽映射实现路由控制，并差异化配置过期策略与持久化参数。
Redis 集群本身不支持按冷热数据自动分离——它只做哈希槽分片，所有 key 无论访问频率或 TTL，都按 CLUSTER KEYSLOT 均匀散列到不同节点；所谓“冷热分离”，必须由业务层显式控制数据落点，再配合过期策略与持久化配置差异化管理。
怎么让热数据进 A 组节点、冷数据进 B 组节点
集群没有内置标签或权重机制，只能靠客户端路由干预：
- 在写入前，用业务规则决定 key 前缀（如
hot:order:1001/cold:user:profile:2002），再为不同前缀配置独立的 Redis 连接池，指向不同集群（或同一集群内不同 master 节点组） - 若共用一个集群，可改写客户端的
getSlot逻辑：对hot:开头的 key 强制映射到槽 0–5460，cold:开头的强制映射到 5461–10922（需确保目标节点实际负责这些槽，且不与其他 key 冲突） - 不推荐用
KEYS或SCAN扫描后迁移——集群下跨槽操作会触发CROSSSLOT Keys in request don't hash to the same slot错误
过期策略对冷热数据的实际影响差异
Redis 的过期删除是惰性+定期混合策略，但冷数据更易被“漏删”：
- 热数据高频访问，每次
GET都触发惰性删除，TTL 到期后几乎立刻释放内存 - 冷数据长期无访问，仅依赖定期抽样（默认每秒 10 次，每次随机检查 20 个带过期的 key），若冷 key 数量大、分布散，可能数小时不被清理，持续占内存
- 集群中每个节点独立执行定期删除，无法协调——不能指望“主节点删完，从节点同步释放”，从节点过期判断完全被动（只响应主节点发来的
DEL命令）
持久化配置如何配合冷热区分
RDB/AOF 不区分冷热，但配置粒度可按节点切分：
- 热数据节点建议关闭
save（禁用 RDB），开启appendonly yes+appendfsync everysec，牺牲毫秒级一致性换取高吞吐 - 冷数据节点可启用 RDB（如
save 900 1），并关闭 AOF（appendonly no），减少写放大和 fork 开销；注意：RDB 生成时仍会阻塞主线程，冷节点因负载低，影响较小 - 所有节点必须保持
cluster-enabled yes，否则无法加入集群；但save和appendonly可以逐节点配置不同
真正难的是冷数据“识别时机”——业务往往在数据写入时就知道它是冷是热，但一旦放错节点，集群不提供重分片能力（redis-cli --cluster reshard 只能搬槽，不能按 key 特征过滤）；所以路由决策必须前置，且 key 命名规范要刚性约束。
