云数据库 Redis 避坑实战：过期键、内存淘汰与大 Key 治理

用云数据库 Redis 做缓存时，大部分故障不是「Redis 挂了」，而是用法踩坑。把三个最高频的坑和对应解法整理如下，供接手缓存维护的同学参考。

一、过期键：惰性删除加定期删除，不等于准时删除。Redis 对带 TTL 的键采用惰性删除（访问时才真正删）加定期抽样删除（每 100ms 随机查一批到期键）。这意味着键到期后可能仍占着内存，DBSIZE 统计也会偏大。常见误区是把「TTL 到了」当成「立刻释放内存」。正确做法：对过期时间加随机抖动，避免海量键同一秒到期引发删除惊群；容量判断看内存水位监控，而不是 TTL 语义。

二、内存淘汰策略：maxmemory 打满后怎么腾位置，取决于 maxmemory-policy。常用的三档：volatile-lru 只在带 TTL 的键里淘汰最久未用的，混合场景默认合理；allkeys-lru 所有键参与淘汰，纯缓存场景首选；noeviction 不淘汰直接拒绝写入，适合一条都不能丢的配置类数据。选型先问一句：这份数据丢了要不要紧？可丢就 allkeys-lru，不可丢就 noeviction 配合持久化与磁盘兜底。

三、大 Key 治理：单个 String 超过 10KB、集合类键元素超过 5000 就该警惕。大 Key 的危害集中在三处：DEL 或过期时阻塞主线程造成延迟毛刺、序列化传输开销大、集群分片倾斜。发现手段是监控带宽与慢查询毛刺，配合 SCAN 抽样和 redis-cli --bigkeys 巡检。治理分三步：拆，把大 Hash 按业务维度分桶成多个小键；缩，压缩 value 或换更紧凑的编码；异步删，用 UNLINK 替代 DEL，把释放工作交给后台线程。

总结：过期不等于即时释放，淘汰策略按缓存还是存储来选，大 Key 要早发现早拆分。这三点做扎实，Redis 稳定性问题会少一大半。