文章目录一、Redis缓存三大问题1️⃣ 缓存穿透Cache Penetration✔ 本质✔ 解决方案方案1缓存空值最常用方案2布隆过滤器Bloom Filter方案3参数校验2️⃣ 缓存击穿Cache Breakdown✔ 本质✔ 解决方案方案1互斥锁最经典方案2逻辑过期推荐方案3永不过期 后台更新3️⃣ 缓存雪崩Cache Avalanche✔ 本质✔ 解决方案方案1TTL 加随机值最常用方案2多级缓存方案3限流 降级方案4Redis 高可用四、如何设计一个“不会崩”的缓存系统✔ 核心设计思想1️⃣ 多层缓存2️⃣ 热点数据保护3️⃣ 限流Rate Limiting4️⃣ 降级Fallback5️⃣ 异步化6️⃣ 高可用架构五、大厂缓存一致性方案重点✔ 典型方案标准答案写流程✔ 增强版更可靠✔ 再进阶Binlog方案✔ 为什么不用“更新缓存”六、总结面试标准回答结构标准答案再加一句加分项一、Redis缓存三大问题1️⃣ 缓存穿透Cache Penetration✔ 本质 查询一个根本不存在的数据流程请求 → Redis没有 → 查数据库 → 数据库也没有 → 返回空如果攻击者反复请求id -1 / 99999999不存在结果每次都打到数据库 → 数据库被压垮✔ 解决方案方案1缓存空值最常用key不存在 → 存一个空值null并设置短TTL例如SET user:999 null EX 60优点简单有效直接挡住重复请求缺点占用少量内存方案2布隆过滤器Bloom Filter 在 Redis 前加一层“存在性判断”原理不存在的数据 → 直接拦截特点极低内存允许误判但不会漏判适用 高并发 恶意攻击场景方案3参数校验id 0 → 直接拒绝 最简单但非常有效2️⃣ 缓存击穿Cache Breakdown✔ 本质某个热点 key 突然失效场景key 商品详情非常热门 缓存过期瞬间 → 大量请求同时打数据库结果数据库瞬间被打爆✔ 解决方案方案1互斥锁最经典1. 发现缓存失效 2. 加锁SETNX 3. 只有一个线程查数据库 4. 其他线程等待示意线程A → 查数据库 线程B → 等待 线程C → 等待方案2逻辑过期推荐不直接删除缓存而是缓存中存 { data: xxx, expireTime: 时间戳 }流程1. 发现过期 2. 返回旧数据 3. 异步刷新缓存优点不会阻塞请求用户无感知 大厂常用方案方案3永不过期 后台更新key 不设置 TTL 后台定时刷新适合热点数据如排行榜3️⃣ 缓存雪崩Cache Avalanche✔ 本质大量 key 在同一时间失效场景大量缓存设置相同TTL如1小时 → 同一时间全部过期 → 请求全部打数据库结果数据库崩溃✔ 解决方案方案1TTL 加随机值最常用EX 3600 random(1~300) 避免同时过期方案2多级缓存本地缓存Caffeine ↓ Redis ↓ 数据库 分担压力方案3限流 降级限制请求量返回默认数据方案4Redis 高可用使用主从复制SentinelCluster 防止 Redis 本身挂掉四、如何设计一个“不会崩”的缓存系统这是面试中非常关键的一题本质是多层防护 降级机制✔ 核心设计思想1️⃣ 多层缓存浏览器缓存 ↓ CDN ↓ Nginx缓存 ↓ 本地缓存 ↓ Redis ↓ 数据库2️⃣ 热点数据保护永不过期提前预热异步刷新3️⃣ 限流Rate Limiting例如漏桶算法令牌桶算法防止流量冲击数据库4️⃣ 降级Fallback当系统压力过大返回默认值 / 静态页 / 兜底数据5️⃣ 异步化MQ削峰如 Apache Kafka延迟更新缓存6️⃣ 高可用架构Redis SentinelRedis Cluster五、大厂缓存一致性方案重点大厂阿里、字节通常采用最终一致性 多重保障✔ 典型方案标准答案写流程1. 更新数据库 2. 删除缓存✔ 增强版更可靠1. 更新数据库 2. 删除缓存 3. 发送MQ消息 4. 再删一次缓存兜底✔ 再进阶Binlog方案数据库变更 → Binlog → Canal → 更新Redis优点强一致性更高自动化✔ 为什么不用“更新缓存”核心原因缓存 派生数据 数据库 真正数据源 更新缓存容易错 删除缓存更安全六、总结面试标准回答结构如果面试官问你“Redis 缓存有哪些问题”你可以这样答标准答案1️⃣ 缓存穿透→ 缓存空值 / 布隆过滤器2️⃣ 缓存击穿→ 互斥锁 / 逻辑过期3️⃣ 缓存雪崩→ TTL随机 / 多级缓存 / 限流再加一句加分项 “实际工程中会结合 MQ、延迟双删、Binlog 来保证最终一致性”