在高并发系统中，Redis 缓存是提升性能的核心组件，但缓存穿透、击穿、雪崩三大问题如同隐形炸弹，可能瞬间压垮数据库。本文系统梳理这三类问题的技术成因与实战解决方案，结合电商、支付等场景的落地经验，提供可直接复用的防御体系。
一、缓存穿透：从 “无数据” 到 “有防御”
缓存穿透指查询不存在的数据时，请求穿透缓存直达数据库，导致底层存储压力激增。典型场景如恶意go公鸡时大量查询不存在的用户 ID，每秒数万次请求直接冲击 MySQL。
解决方案分层架构：
- 基础防御：布隆过滤器前置拦截。在缓存层之前部署布隆过滤器，将所有有效 Key 提前载入。当请求到达时，先通过布隆过滤器判断 Key 是否存在，不存在则直接返回，误判率可控制在 0.01% 以下。某电商平台通过此方案，将无效请求拦截率提升至 99.7%。
- 兜底策略：空值缓存 + 过期时间。对查询结果为空的数据，在 Redis 中缓存空值（如null）并设置短期过期时间（通常 5-60 秒），避免重复穿透。需注意设置随机过期时间，防止大量空值同时失效引发新的穿透。
- 终极防护：接口限流 + 恶意 IP 封禁。结合 Nginx 或网关层实现 IP 级别的限流，对短时间内高频访问不存在 Key 的 IP 进行临时封禁，从源头阻断公鸡流量。
二、缓存击穿：热点 Key 的 “单点防御”
缓存击穿指一个高频访问的热点 Key 突然失效（如缓存过期），瞬间所有请求穿透到数据库，造成瞬间压力峰值。例如电商秒杀活动中，某款商品的库存 Key 过期时，数万并发请求同时查询数据库。
三级防护体系：
- 互斥锁机制：当缓存失效时，通过 Redis 的SETNX命令获取锁，只有获得锁的线程能查询数据库并更新缓存，其他线程等待重试。需设置锁的过期时间（如 3 秒），避免死锁。某支付系统通过此方案，将热点 Key 失效时的数据库峰值请求从 10 万 QPS 降至 500QPS。
- 热点 Key 永不过期：两种实现方式：①不设置过期时间，通过后台定时任务主动更新缓存；②将过期时间存入 Value 中，业务逻辑判断是否过期后主动刷新，避免 Redis 自动删除。
- 本地缓存兜底：对极端热点数据（如首页 Banner），在应用服务器本地缓存一份（如使用 Caffeine），当 Redis 缓存失效时，先从本地缓存获取，为 Redis 缓存更新争取时间。
三、缓存雪崩：系统性崩溃的 “熔断机制”
缓存雪崩指短时间内大量缓存 Key 集中过期，或 Redis 集群宕机，导致请求大规模穿透到数据库，引发连锁反应。2023 年某电商大促期间，因缓存雪崩导致数据库宕机 47 分钟，直接损失超千万元。
全方位防御策略：
- 过期时间打散：为 Key 设置随机过期时间（如基础过期时间 + 1-5 分钟随机值），避免集中失效。实验数据显示，此方法可将缓存失效峰值降低 80% 以上。
- 多级缓存架构：构建 “本地缓存 + Redis + 数据库” 三级缓存，当 Redis 集群异常时，本地缓存可临时承接流量。某社交平台通过此架构，在 Redis 宕机 30 分钟内保持了核心功能可用。
- Redis 高可用部署：采用主从 + 哨兵模式或 Redis Cluster，确保单点故障时自动切换。同时配置持久化（AOF+RDB 混合模式），缩短故障恢复时间。
- 熔断降级机制：结合 Sentinel 或 Hystrix，当数据库压力达到阈值时，自动触发降级策略（如返回默认数据、提示系统繁忙），避免全面崩溃。
缓存问题的本质是 “概率性风险” 与 “系统性防御” 的博弈。在实际架构中，需根据业务场景组合使用上述方案 —— 例如金融支付场景侧重互斥锁 + 熔断降级，而电商秒杀场景更依赖布隆过滤器 + 本地缓存。通过多层防护体系，才能在高并发洪流中守住系统的 “最后一道防线”。
