🎯 缓存经典问题

1. 什么是缓存穿透？怎么解决？

穿透：查询不存在的 key——缓存没有、数据库也没有。恶意攻击者用不存在的 ID 疯狂请求，每次都打到数据库。

解决：

1. 缓存空值：查不到也写缓存（value=null，TTL 短，如 60s）。简单有效，但浪费空间且短窗口内 DB 仍被打
2. 布隆过滤器（推荐）：请求先过布隆（所有可能存在的 key 预置其中），不在则直接返回。误判率可控（1%），不存在的 key 100% 被拦
3. 参数校验：非法 ID（≤0、超范围）直接拒绝

// 一个 bit 数组 + k 个哈希函数
// 插入：key 经 k 个哈希函数，把对应 k 位全部置 1
// 查询：k 位只要有一位是 0 → 一定不存在（不漏报）
//         k 位全是 1 → 可能存在（有误报，因位被其他 key 置 1）

// Redis 实现：
// - 手动：SETBIT/GETBIT + 多哈希（简单但麻烦）
// - Redisson：RBloomFilter，开箱即用
// 注意：布隆不支持删除（位可能被多个 key 共享）→ 数据删除后误报率上升

2. 缓存击穿和缓存雪崩的区别？

• 击穿：单个热点 key 过期瞬间，大量并发请求同时打到数据库（同一时刻）。点状问题
• 雪崩：大量 key 同时过期（或 Redis 挂了），请求洪峰直接压垮数据库。面状问题

击穿解决：

1. 互斥锁：缓存过期后只让一个线程去查库回填，其他线程等锁后读新缓存（SETNX 或 JVM 锁）
2. 逻辑过期：缓存永不过期（TTL 不设），value 里带过期时间字段；读时发现逻辑过期 → 异步线程更新缓存，先返回旧值（牺牲一致性换可用性）
3. 热点 key 的 TTL 错开 + 预热

雪崩解决：

1. 过期时间加随机值（基础 TTL + random(0~300s)），错开过期时间
2. 多级缓存（本地缓存 Caffeine + Redis），Redis 挂了本地扛
3. Redis 集群高可用（哨兵/Cluster），避免单点挂
4. 限流降级：DB 扛不住时降级返回默认值/旧数据

3. 数据库与缓存如何保证一致性？

问题根源：缓存更新和 DB 更新不是原子的，乱序执行就会不一致。先分析四个方案：

• 先更新 DB，再更新缓存 → 并发下两个线程交叉写，缓存可能存旧值 ❌
• 先删缓存，再更新 DB → 更新期间有请求读到 DB 旧值回填缓存 ❌（旧值又进缓存）
• 先更新 DB，再删缓存 → 读请求在"删之前"读到旧值，但删后下次读就是新的 ✅ 主流方案

业界主流：Cache Aside（旁路缓存）——先更新数据库，再删除缓存：

1. 读：缓存有 → 返回；没有 → 查库回填，TTL 兜底
2. 写：先更新 DB，成功后删除缓存（下次读再回填）

仍可能不一致的窗口与补救：

• 删缓存失败 → 重试（消息队列/定时对账）
• 极端并发：A 读缓存未命中 → A 先查库拿到旧值 → B 更新数据库 → B 删除缓存 → A 才把旧值回填进缓存 → 旧值滞留一个 TTL。缓解：延迟双删（更新库并删缓存后，在事务提交之后再延迟 500ms~1s 删一次）或 key 加版本号
• 强一致要求 → 别用缓存，或读改写都走 DB（缓存仅加速）

4. 缓存预热和缓存降级？

• 预热：系统上线/大促前，把热点数据提前写入缓存（后台任务扫库回填 + 手动触发），避免启动瞬间击穿。配合本地缓存 + 热 key 识别（LRU 统计）
• 降级：缓存不可用时（Redis 故障/超时），策略性返回兜底数据：默认值、旧快照、空数据——保系统可用不拖垮 DB。分：读降级（限流+熔断）和写降级（同步写转异步 MQ）