冷热数据混存导致redis oom的根本解法是物理隔离：热数据走纯内存redis实例，冷数据下沉至pika/ssdb/对象存储，redis仅存轻量元信息；禁用allkeys-lru，改用volatile-lru并只对热key设ttl，冷数据写入必须绕过redis主实例。
冷热数据混存导致 Redis OOM 怎么办
直接后果是 OOM command not allowed when used memory > 'maxmemory'，尤其在促销、活动期间高频写入冷数据时极易触发。这不是配置调大就能解决的问题——冷数据挤占内存，热 Key 反而被 LRU 淘汰，造成缓存击穿和数据库雪崩。
根本解法是物理隔离：热数据走纯内存 Redis 实例，冷数据不进 Redis 主实例，而是下沉到磁盘型 NoSQL（如 Pika、SSDB、RocksDB 封装服务）或对象存储 + 元信息缓存。Redis 只保留热数据的“引用”或“摘要”，比如 hot:order:1001 存完整结构，cold:order:999999 在 Redis 中只存 {"storage":"oss","key":"ord_999999"}。
- 不要用
EXPIRE给冷数据“假装热”，过期时间设长反而延长内存驻留周期 - 禁用
maxmemory-policy allkeys-lru，改用volatile-lru并只对热 Key 设置 TTL - 冷数据写入路径必须绕过 Redis 主实例，走独立代理或应用层路由逻辑
为什么 Pika 比原生 Redis 更适合冷热分级
Pika 是兼容 Redis 协议的磁盘型 KV 存储，3.0+ 版本内置缓存层（Cache Layer），可配置 cache-size 和 cache-threshold，自动将高频访问 key 提升至内存，低频 key 沉降至 RocksDB。它不是“Redis + 磁盘持久化”，而是“Redis 协议 + 分级存储引擎”的融合体。
对比原生 Redis：RDB/AOF 是灾难恢复手段，不是分级策略；VM 早在 2.4 被废弃；而 Pika 的 cache-status 字段（如 PIKA_CACHE_STATUS_OK）是运行时真实状态标记，可被监控系统采集用于动态扩缩容。
- 冷热切换无须应用改代码，只需把客户端连接地址从
redis://...换成pika://... -
cache-threshold默认是 100 次访问，可按业务调整，避免“一次访问就上缓存”的误提 - 注意 Pika 不支持
SCAN全量遍历磁盘数据，冷数据批量查询需走专用导出接口或外部索引
冷数据元信息该存在 Redis 还是本地缓存
存在 Redis 是错的——这会让冷数据的“指针”继续占用热集群内存，且引入额外序列化/网络开销。正确做法是：冷数据元信息（如存储位置、版本号、过期时间）走 Caffeine 或 Guava Cache 本地缓存，TTL 设为比实际冷数据生命周期短 10%～20%，靠主动刷新 + 异步加载兜底。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
典型场景：用户查历史订单，ID ord_2025110001 属于冷数据，应用先查本地缓存，命中则直连 OSS 或 Pika 获取；未命中则触发异步加载，并返回 202 Accepted + 查询 ID，前端轮询结果。
- 本地缓存大小建议设为
10MB～50MB，用maximumSize+expireAfterWrite控制 - 禁止在本地缓存里存完整冷数据体，只存
storage_type、bucket、object_key等轻量字段 - 若多实例部署，需用分布式锁（如 Redis
SETNX）防重复加载，但锁粒度应为冷数据 ID，而非全局限流
如何验证冷热分离是否生效
不能只看内存使用率下降，要盯三个关键指标：热集群 evicted_keys 是否趋近于 0、冷数据访问延迟是否稳定在 50ms 内（Pika/OSS）、以及数据库慢查询中“冷数据穿透”类 SQL 是否归零。
推荐组合命令快速诊断：
redis-cli -h hot-redis info memory | grep -E "(used_memory|maxmemory|evicted_keys)" redis-cli -h pika-node info cache | grep -E "(cache_size|cache_hit_rate|cache_miss_rate)"
如果 cache_hit_rate 长期低于 60%，说明 cache-threshold 设得过高或冷热边界划分不准；如果热集群 evicted_keys 每小时增长 > 1000，说明仍有冷数据误入或热 Key 未加前缀隔离。
最易被忽略的一点：冷热分离后，应用日志里不再出现 Connection refused 或 timeout 并不等于架构健康——要确认这些错误是否只是被降级逻辑吞掉，而没真正消除根源。
