Redis 缓存设计与实践：策略、穿透、雪崩、击穿

Redis（Remote Dictionary Server）是开源内存数据库，支持多种数据结构（String、Hash、List、Set、Sorted Set 等），常用于缓存、会话、限流、消息队列等场景。缓存可显著降低数据库压力、提升响应速度；但设计不当会带来穿透、雪崩、击穿等问题。本文介绍 Redis 缓存策略、三大问题的成因与解决方案，以及常用数据结构与命令。

一、Redis 缓存为何重要：数据与场景

根据 Redis 官方与各云厂商 benchmark，内存读写延迟在亚毫秒级，相比数据库可提升一个数量级以上的响应速度。缓存命中率每提升 10%，数据库负载可显著下降。

场景	典型用途	数据结构
页面/接口缓存	热点数据、列表	String、Hash
会话	用户登录态	String（带 TTL）
限流	QPS、IP 限流	String 计数、滑动窗口
排行榜	分数排序	Sorted Set
消息队列	简单队列、发布订阅	List、Pub/Sub

数据来源：Redis 官方文档、各云厂商性能报告（综合整理）。

二、Redis 缓存策略

缓存策略决定「何时写缓存、何时失效、谁负责更新」。常见四种：Cache-Aside、Read-Through、Write-Through、Write-Behind。

2.1 Cache-Aside（旁路缓存）

应用直接管理缓存与数据库。读：先查缓存，未命中则查库并回填缓存。写：先更新数据库，再删除（或更新）缓存，避免长期脏读。这是最常用、最易实现的策略。

2.2 Read-Through / Write-Through

Read-Through：缓存层代理读请求，未命中时由缓存层从数据库加载并写入缓存。Write-Through：写请求同时写数据库与缓存，保证强一致但写延迟较高。

2.3 Write-Behind

写请求先写缓存，异步批量写回数据库。适合高写、可接受最终一致的场景；需处理宕机丢数据与顺序问题。

策略	读流程	写流程	适用
Cache-Aside	先缓存后库，miss 则查库并回填	更新库后删/更新缓存	通用、推荐
Read-Through	缓存代理读，自动加载	同 Cache-Aside	有统一缓存层
Write-Through	同上	同时写库和缓存	强一致
Write-Behind	同上	先写缓存，异步写库	高写、最终一致

三、缓存穿透、雪崩、击穿

三者是缓存设计中的典型问题，需在架构与代码层面针对性解决。

3.1 缓存穿透

缓存穿透指查询「不存在的数据」，请求每次都绕过缓存直接打到数据库，易被恶意利用。解决方案：① 布隆过滤器（Bloom Filter）在缓存前过滤不存在的 key；② 对「查无结果」也做短时缓存（空值缓存），避免重复查库。

3.2 缓存雪崩

缓存雪崩指大量 key 在同一时段过期，导致请求瞬间压到数据库。解决方案：① 过期时间加随机值（如 1 小时 ± 10 分钟），打散过期时间；② 多级缓存（本地缓存 + Redis）；③ 热点数据永不过期或逻辑过期 + 异步更新。

3.3 缓存击穿

缓存击穿指某个热点 key 过期瞬间，大量请求同时查库。解决方案：① 互斥锁：只有一个请求查库并回填，其余等待或重试；② 逻辑过期：key 永不过期，value 内带过期时间，异步更新。

问题	成因	方案
穿透	不存在的数据频繁查询	布隆过滤器、空值缓存
雪崩	大批 key 同时过期	过期时间随机、多级缓存
击穿	热点 key 过期瞬间	互斥锁、逻辑过期

四、常用数据结构与命令

String：KV，可存 JSON、计数；GET/SET/INCR/DECR。Hash：对象、字段；HGETALL/HSET/HMGET。List：队列、栈；LPUSH/RPOP/LRANGE。Set：去重、交并差；SADD/SMEMBERS/SINTER。Sorted Set：有序集合、排行榜；ZADD/ZRANGE/ZRANGEBYSCORE。设置过期：EXPIRE key seconds。

五、缓存设计要素权重

基于实际项目经验，缓存设计时以下要素的影响程度（相对权重，满分 100）：

说明：权重基于 Redis 缓存项目实践归纳，仅供参考。

六、小结

Redis 缓存需结合业务选策略（推荐 Cache-Aside），并防范穿透、雪崩、击穿。数据结构与命令按场景选择；过期与更新策略直接影响命中率与一致性。若数据库使用 VPC 内网，可配合 Redis 做多级缓存，参考《MySQL VPC 内网架构》；API 层可结合限流与安全设计，见《API 安全设计最佳实践》。