冷热数据混存是redis雪崩的直接推手，因冷数据假性存活、lru误杀热key、批量写入触发oom等导致缓存命中率断崖下跌；必须物理隔离至实例层，热集群用volatile-lru+抖动ttl，冷集群用pika存储，辅以caffeine本地缓存+主动刷新。
大促期间 Redis 冷热数据不分离，是雪崩的加速器，不是诱因之一，而是直接推手。 热 Key 集中过期、冷数据挤占内存、淘汰策略误杀高频 Key——三者叠加，数据库 QPS 在 5 分钟内冲到日常 8 倍以上，基本就是这个架构在报警。
为什么冷热混存会让雪崩概率翻倍
冷数据写入 Redis 后，哪怕设了 EXPIRE，只要没被访问，它就只是“假性存活”：既不热、又不自动释放，还长期占用内存。一旦触发 maxmemory-policy allkeys-lru（默认或误配），Redis 会无差别淘汰，热 Key 反而比冷数据更易被踢出——因为冷数据写入早、访问少、LRU 时间戳老。结果就是：缓存命中率断崖下跌，大量请求穿透到 DB，而此时大促流量正 peak，DB 连接池瞬间打满。
- 冷数据批量写入（如历史订单导出）会触发 Redis 内存快速上涨，触发
OOM command not allowed when used memory > 'maxmemory' - 冷数据 key 命名若带业务前缀（如
order:2025110001），和热 Key（order:hot:1001）混在同一个实例，SCAN 或 KEYS 操作极易阻塞主线程 - 冷数据 TTL 设为统一长值（如 24h），会导致整点过期密度突增，和热 Key 的抖动 TTL 形成共振，放大雪崩风险
冷热物理隔离必须落地到实例层
只靠应用层判断“这是冷数据”再跳过 Redis，不可靠；只靠命名规范或 TTL 区分，挡不住误写。真正有效的隔离，是让冷数据根本进不了热 Redis 实例。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 热集群：纯内存 Redis 实例，
maxmemory-policy volatile-lru，只对明确标记为热的 key（如hot:product:1001）设 TTL，且基础 TTL +random.nextInt(120, 600)抖动 - 冷集群：用
Pika替代 Redis，连接地址从redis://改为pika://，冷数据（如cold:order:999999）直写 Pika，Redis 中仅存元信息指针（如{"storage":"pika","key":"cold:order:999999"}） - 禁止任何冷数据写入热 Redis 的路径：在客户端 SDK 层加白名单校验，对匹配
cold:、archived:、history:前缀的 key 直接抛异常或路由到代理层
本地缓存 + 主动刷新是热数据防击穿底牌
光靠 Pika 和 Redis 分离还不够。大促时热 Key 查询 QPS 可能上万，单靠 Redis 二级缓存仍有网络延迟和连接争抢。Caffeine 本地缓存必须启用，且要配合主动刷新，否则抖动 TTL 仍可能造成小范围击穿。
- Caffeine 配置
expireAfterWrite(10, TimeUnit.SECONDS)，不依赖 Redis TTL，避免跨节点时间差导致不一致 - 在 Caffeine
removalListener中触发异步预加载：当 key 即将过期（比如剩余 30% TTL 时），调用Redisson.getDelayedQueue().add()推送刷新任务，由后台线程提前回源并写回 Redis 和本地缓存 - 所有热数据读路径必须先查 Caffeine，未命中才查 Redis；写路径必须同步更新 Caffeine（
cache.put(key, value)）和 Redis（setex），禁用“先删缓存再更新 DB”的弱一致性模式
冷热分离不是加个配置就能跑通的事。Pika 的 cache-threshold 要调到 50～200 次访问才提热，避免冷数据一次查询就上内存；Caffeine 的 maximumSize 必须按单机 QPS × 平均响应时间 × 热 Key 数量反推，不能拍脑袋设 10000；最易被忽略的是：冷数据元信息绝不能存在 Redis 里——它看似轻量，但千万级用户下，每个 200 字节的 JSON 就是 200MB 内存开销，而且全是无效压力。
