70 lines
4.9 KiB
Markdown
70 lines
4.9 KiB
Markdown
## 缓存穿透、缓存击穿、缓存雪崩
|
||
|
||
### **1. 缓存穿透**
|
||
**定义**：查询一个**不存在的数据**（如数据库中无对应记录），导致请求绕过缓存直接访问数据库，可能对数据库造成压力。
|
||
**解决方案**：
|
||
- **缓存空值**：即使查询结果为空，也将空值写入缓存并设置短过期时间，避免重复查询数据库。
|
||
- **布隆过滤器**：通过概率数据结构拦截不存在的查询请求，减少无效数据库访问。
|
||
- **请求校验**：对用户输入参数进行合法性校验（如ID格式），过滤非法请求。
|
||
|
||
### **2. 缓存击穿**
|
||
**定义**：某个**热点数据的缓存失效**，导致大量并发请求直接冲击数据库。
|
||
**解决方案**：
|
||
- **热点数据永不过期**：物理上不设置过期时间，通过后台异步更新缓存。
|
||
- **分布式锁**：缓存失效时，仅允许一个线程回源数据库更新缓存，其他线程等待。
|
||
- **预加载**：在缓存失效前主动加载数据，避免空窗期。
|
||
|
||
### **3. 缓存雪崩**
|
||
**定义**：大量缓存**同时失效**（如设置了相同过期时间），导致请求集中冲击数据库。
|
||
**解决方案**：
|
||
- **过期时间随机化**：为缓存设置基础过期时间+随机值（如1-5分钟），分散失效时间。
|
||
- **服务熔断与限流**：当数据库压力过大时，触发熔断机制或限制请求速率，保护后端系统。
|
||
- **多级缓存**：使用主备缓存（如本地缓存+Redis），主缓存失效时从备缓存或数据库加载。
|
||
- **高可用架构**：构建Redis集群或主从架构，避免单点故障导致的雪崩。
|
||
|
||
### **总结**：
|
||
- **穿透**：防无效查询，用空值缓存+布隆过滤器。
|
||
- **击穿**：保热点数据，用永不过期+锁/预加载。
|
||
- **雪崩**：分散失效时间+熔断限流+多级缓存。
|
||
|
||
|
||
## 缓存一致性
|
||
|
||
### **一、缓存一致性问题的定义与风险**
|
||
缓存与数据库数据不一致的核心矛盾在于：**非原子操作导致中间状态暴露**。
|
||
**典型问题场景**：
|
||
1. **并发写冲突**：多个请求同时修改数据，缓存与数据库更新顺序不一致（如A请求更新数据库，B请求删除缓存）。
|
||
2. **读写分离延迟**：数据库主从架构中，从库同步延迟导致缓存更新读取到旧数据。
|
||
3. **缓存失效窗口**：缓存删除后、新数据加载前的短暂时间内，请求可能读取到旧数据。
|
||
|
||
### **二、优化与解决方案**
|
||
#### **1. 延迟双删策略**
|
||
- **操作流程**：更新数据库后，**延迟删除缓存**（如等待几百毫秒），确保数据库事务提交且从库同步完成后再清理缓存，避免旧数据残留。
|
||
- **适用场景**：对一致性要求较高且能容忍短暂延迟的场景（如电商库存更新）。
|
||
|
||
#### **2. 分布式锁控制并发**
|
||
- **实现方式**：在写操作前加锁（如Redis分布式锁），确保同一时间只有一个线程执行“更新数据库+删除缓存”的流程，防止并发冲突。
|
||
- **缺点**：可能降低系统吞吐量，需权衡性能与一致性。
|
||
|
||
#### **3. 异步消息队列更新**
|
||
- **方案设计**：将数据库变更事件（如增删改）发布到消息队列，由消费者异步更新缓存，通过**最终一致性**降低直接耦合。
|
||
- **优势**：解耦系统组件，提升高并发场景下的稳定性。
|
||
|
||
#### **4. 版本号/时间戳控制**
|
||
- **实现逻辑**：为数据添加版本号或时间戳，缓存更新时校验版本，仅当缓存版本低于数据库时才更新，避免覆盖最新数据。
|
||
- **适用场景**：需要精确控制数据版本的场景（如金融交易系统）。
|
||
|
||
#### **5. 多级缓存协同更新**
|
||
- **架构设计**：结合本地缓存（如Caffeine）与分布式缓存（如Redis），通过层级失效机制（如先更新数据库，再逐级删除本地缓存和分布式缓存）减少不一致窗口。
|
||
- **示例**：更新数据库后，先删除本地缓存，再通过发布-订阅模式通知其他节点删除缓存。
|
||
|
||
#### **6. 物理删除代替更新缓存**
|
||
- **核心思想**：避免直接更新缓存（可能导致脏数据），而是通过删除缓存触发后续请求自动从数据库加载新数据。
|
||
- **实践建议**：优先使用“先更新数据库，再删除缓存”的顺序，降低数据不一致概率。
|
||
|
||
### **三、总结与权衡**
|
||
- **强一致性 vs 性能**：无法完全避免短暂不一致，需根据业务需求选择策略（如金融交易需分布式锁，电商促销可接受最终一致性）。
|
||
- **监控与优化**：通过监控缓存命中率、数据库负载等指标，动态调整过期时间、锁粒度等参数。
|
||
- **技术选型**：结合分布式缓存（如Redis集群）、消息队列（如Kafka）和一致性协议（如CPU缓存MESI协议）提升系统整体一致性。
|
||
|