Redis 缓存常见问题与应对

Redis 在 Web 架构里几乎是缓存的标配，但在实际使用中，几个经典坑点反复出现。理解它们的成因与应对策略，能把缓存层从"性能加速器"变成"稳定加速器"。

一、缓存穿透
查询一个必定不存在的数据，缓存未命中且回源也未命中，请求会直接打到数据库。高频的穿透查询能把 DB 打垮。
应对：

• 布隆过滤器拦截不存在的 key，拦截后直接返回空。
• 对空值也写缓存，并设较短的 TTL（如 30-60 秒），避免恶意查询反复穿透。
• 参数合法性校验前置，非法 ID 直接在接口层拦截。

二、缓存击穿
某个热点 key 突然过期，短时间内大量请求涌向 DB。常见于秒杀、热点新闻。
应对：

• 热点 key 不设过期时间，或通过后台任务异步刷新。
• 互斥锁 / 分布式锁：只有请求拿到锁的线程去回源查库并回写，其余线程读旧值或等待。
• 逻辑过期：key 不真正删除，而是记录版本号；回源写新值后更新版本号，读端判断是否需要异步刷新。

三、缓存雪崩
大量 key 在同一时刻集中过期，导致回源流量瞬间暴增。
应对：

• 给 TTL 加上随机抖动（如基础 5 分钟 + 随机 0-3 分钟），使过期时间分散。
• 多级缓存（本地缓存 + Redis），本地层兜底一部分流量。
• 对 DB 做限流与降级，配合服务熔断避免拖垮整个链路。

四、数据一致性
写入 DB 后缓存如何更新？先删缓存再写库，或先写库再删缓存，都可能产生短暂不一致。
应对：

• 推荐 Cache-Aside 模式：先更新 DB，再删除（而非更新）缓存，下次读时回填。
• 对一致性要求高的场景，用 Binlog + Canal 等消息通道异步刷新 / 删除缓存。
• 在缓存中记录版本号或更新时间戳，读请求发现版本号落后时主动失效。

五、内存与驱逐策略
Redis 是内存数据库，内存不够时会触发淘汰，导致业务读不到缓存。
应对：

• 根据业务选择合适的 maxmemory-policy：allkeys-lru 淘汰最近最少使用的 key；volatile-ttl 淘汰即将过期的 key。
• 控制大对象（big key）和热 key，避免单个 value 占用过多内存或单节点 CPU 被打满。
• 对不重要的缓存开启持久化关闭，把内存全留给数据。

六、序列化与 Key 设计

• 序列化格式影响内存和解析性能。相比 Java 默认序列化，用 JSON、Protobuf 或 MessagePack 能明显缩小体积。
• Key 设计要短、有意义、带命名空间（如 user:1001:profile），避免用 hash 值当 key，方便排查。
• 批量操作（pipeline / mget/mset）减少网络往返，降低命令延迟。

七、超时与阻塞
Redis 是单线程处理命令的，慢命令会阻塞后续请求。
应对：

• 避免在 Redis 中执行 HGETALL、SMEMBERS 等 O(N) 命令扫大集合；用 HSCAN/SSCAN 增量扫描。
• 客户端设置合理的 connect/read 超时，结合连接池（如 Lettuce / JedisPool）的 maxWait 与空闲回收。
• 对关键写入使用 Redisson 的 WatchDog 机制看管锁，防止客户端挂掉导致锁无法释放。

八、高可用与故障

• 生产推荐 Redis Cluster 或 Sentinel。Cluster 支持水平扩展和故障转移；Sentinel 成本低，适合读写分离 + 主从架构。
• 主从切换期间会出现短暂只读或连接失败，客户端需支持重连与重试。
• 合理配置 RDB/AOF 持久化。要求不丢数据用 AOF + everysec；更看重性能则关闭 AOF，依靠上游补偿。

缓存不是银弹。用 Redis 时，先想清楚"能接受怎样的不一致"、“热点怎么分布”、“挂了怎么办”，再选 TTL、淘汰、持久化和部署形态，比堆参数更管用。