在高并发系统中，Redis 往往并不是“锦上添花”的组件，而是直接决定系统能否扛住流量的核心基础设施。缓存设计做得好，数据库压力可以下降一个数量级；反过来，缓存设计一旦失误，在流量高峰时甚至会成为“放大器”，把问题从 Redis 直接传导到数据库，引发连锁反应。因此，讨论 Redis 缓存时，不能只停留在“用没用缓存”，而是要深入到缓存的使用方式、失效策略以及异常场景下的表现。
缓存的核心目标：削峰与隔离
从设计层面看，引入缓存的本质目标只有两个：削峰和隔离。削峰是指通过 Redis 承接绝大多数读请求，避免所有流量直接打到数据库；隔离则是让数据库只承担“必要且可控”的访问，而不是成为外部流量波动的直接受害者。理想状态下，数据库的 QPS 应该相对平稳，而 Redis 承受的是不稳定、高并发的请求。
在实际工程中，常见的模式是“Cache Aside（旁路缓存）”：读请求先查 Redis，命中则直接返回；未命中则查询数据库，并将结果写入缓存。写请求先更新数据库，再删除或更新缓存。这个模式简单直观，也是大多数业务的默认选择，但问题恰恰也出在这里——当缓存失效或异常时，风险会被瞬间放大。
1. 缓存穿透：请求绕过缓存直击数据库
缓存穿透指的是：请求的 key 在缓存中不存在，在数据库中也不存在。由于缓存无法命中，每一次请求都会直接访问数据库，如果这种请求被恶意构造或在高并发下反复出现，就会对数据库造成持续压力。
在工程实践中，缓存穿透往往来自两个来源：一是业务上的“合法但不存在”的请求，比如查询一个已被删除或从未存在的用户；二是恶意请求，比如攻击者不断请求随机 ID。解决思路的核心在于：让这些请求不要每次都落到数据库。最常见的做法是对“空结果”进行缓存，例如当数据库返回不存在时，也在 Redis 中写入一个短 TTL 的占位值。这样在 TTL 期间，同样的请求会被缓存直接拦截。
在数据规模更大、key 空间不可控的场景下，布隆过滤器是一个更工程化的方案。通过在请求进入 Redis 之前判断 key 是否“可能存在”，可以在入口层直接拒绝绝大多数无效请求，从而在架构上消除穿透问题。
2. 缓存击穿：热点 key 失效引发的瞬时洪峰
缓存击穿关注的不是“有没有这个 key”，而是“这个 key 太重要了”。当某个热点 key（例如首页配置、爆款商品信息）在某一时刻过期，大量并发请求会同时发现缓存失效，并同时去查询数据库，形成瞬时的并发洪峰。
与缓存穿透不同，缓存击穿往往发生在业务正常运行过程中，并且具有明显的时间点特征。解决这个问题的关键在于：避免在同一时间有大量请求去重建同一个缓存。常见的工程手段是引入互斥机制，比如在缓存失效时，通过分布式锁或本地锁保证只有一个请求可以访问数据库并重建缓存，其余请求等待或短暂返回旧值。
另一种更偏“设计层面”的思路是将热点 key 设置为逻辑过期：Redis 中的数据永不过期，过期时间由业务字段控制。当发现数据过期时，仍然先返回旧值，同时异步触发缓存更新。这种方案牺牲了一定的一致性，但换来了系统在高并发下的稳定性，非常适合对实时性要求不极端的读多写少场景。
3. 缓存雪崩：大面积失效导致系统级风险
如果说缓存击穿是“点状事故”，那么缓存雪崩就是系统级灾难。缓存雪崩指的是大量 key 在同一时间失效，或者 Redis 整体不可用，导致请求在短时间内全部涌向数据库。数据库往往无法承受这样的流量，最终导致服务级联失败。
雪崩最常见的诱因是TTL 设置不合理，例如大量 key 使用了相同的过期时间，在某一时刻集中失效。解决方式并不复杂，但非常容易被忽视：在设置过期时间时引入随机因子，让 key 的失效时间分散开来，从概率上避免“同时过期”的情况。
更严重的雪崩来自 Redis 实例本身不可用，这就要求从架构层面进行防护。例如通过主从复制、哨兵或集群保证 Redis 的高可用；在应用层增加限流与降级策略，即使缓存失效，也要限制数据库的最大并发访问，避免“缓存挂了，数据库也跟着挂”的连锁反应。
4. 性能优化的本质：让异常路径也可控
从表面看，缓存穿透、击穿、雪崩是三个不同的问题，但它们的共同点在于：都发生在缓存失效或异常的路径上。很多系统在正常命中缓存时性能很好，但一旦进入“未命中路径”，就会暴露出设计上的脆弱性。真正成熟的缓存设计，关注的不是“99% 命中时有多快”，而是“1% 异常情况下系统是否仍然稳定”。
因此，Redis 缓存的性能优化并不只是调参数、加内存，更重要的是在设计阶段就思考：如果缓存失效了怎么办？如果热点 key 同时过期怎么办？如果 Redis 挂了怎么办？只有把这些问题提前纳入设计，缓存才能真正成为系统的“减压阀”，而不是隐藏的风险点。
