微信二维码
双十一凌晨零点，当无数消费者疯狂点击“下单”按钮时，技术团队的噩梦也随之降临——系统压力如火山喷发般骤增，数据库在瞬间被海量请求淹没，服务崩溃的警报声刺破夜空。这样的场景，无数技术团队都曾经历过，而罪魁祸首，往往藏在看似不起眼的缓存层中。
Redis，作为现代互联网系统的缓存标配，其三大失效场景——缓存击穿、缓存穿透、缓存雪崩，就像三把悬在架构师头顶的达摩克利斯之剑，随时可能斩断系统的稳定性。今天，我们就来揭开这三把剑的真面目，并探讨如何用技术手段化解危机。
第一把剑：缓存击穿——热点数据的“致命瞬间”
场景重现
某个爆款商品的详情页，是无数用户争相访问的热点数据。然而，当这个Key的缓存过期时，噩梦开始了——成千上万的并发请求如潮水般涌向数据库，瞬间将数据库打崩。
危险之处
缓存击穿的危险在于它的突然性和破坏性。平时系统运行如丝般顺滑，但在热点内容缓存过期的那1秒内，数据库可能被触发数千次查询，直接导致服务瘫痪。
破解之道
互斥锁：在缓存失效后，只允许第一个请求去数据库查询并重建缓存，其他请求排队等待。这种方法适合对数据一致性要求极高的场景（如金融交易）。
逻辑过期：缓存永不真正过期，而是在数据中记录一个逻辑过期时间。当检测到逻辑过期时，异步触发缓存重建，当前请求先返回旧数据。这种方法适合对可用性要求高、容忍短暂数据陈旧的场景（如商品列表）。
第二把剑：缓存穿透——恶意请求的“无影攻击”
场景重现
攻击者或恶意爬虫构造大量不存在的ID（如随机生成的商品ID），疯狂请求数据库。由于这些数据在缓存和数据库中都不存在，每次请求都会直接穿透到数据库，最终将数据库打垮。
常见成因
恶意攻击或爬虫
业务逻辑漏洞（如未对用户输入进行校验）
破解之道
空值缓存：当查询不到结果时，在缓存中写入一个特殊的空值（如null），并设置较短的TTL（如5分钟）。后续相同请求直接返回空，不再击穿到数据库。
布隆过滤器：预先将数据库中所有合法ID写入布隆过滤器（一种空间效率极高的概率型数据结构）。请求到来时，先做布隆过滤，对于明确不存在的ID直接拒绝，零成本截流。
第三把剑：缓存雪崩——批量失效的“连锁反应”
场景重现
系统启动时，大量缓存Key被批量预热，且TTL设置相同。当这些Key在同一时间段集中过期时，大批量请求同时穿透缓存，直接打到数据库，引发雪崩式崩溃。
危险之处
缓存雪崩的破坏力在于它的规模性。一旦发生，整个系统可能陷入瘫痪，恢复时间漫长。
破解之道
随机化TTL：在设置缓存过期时间时，加入随机抖动（如基础TTL±10%的随机值），避免大量Key同时过期。
多级缓存：构建本地缓存（如Caffeine）+ Redis缓存的两级缓存架构。即使Redis缓存集中失效，本地缓存仍能承接大部分流量，为系统争取宝贵的恢复时间。
限流降级：在缓存失效高峰期触发限流（如令牌桶算法），保护数据库不被打垮。同时，对降级请求返回默认数据（如“系统繁忙，请稍后再试”），而非直接报错，提升用户体验。
微信二维码