1、背景

数据库与缓存一致性是指当数据同存在于数据库和缓存中时，如何确保两者数据保持同步，避免出现数据不一致的情况

2、核心问题

1、写入顺序问题：先更新数据库还是先更新缓存
2、并发操作问题：多个请求同时操作数据库和缓存
3、失败场景处理：操作过程中部分失败导致的不一致

3、常见解决方案

【1】缓存更新策略

[1]旁路缓存模式（Cache-Aside）

读取流程：

1、先查缓存，名字则返回
2、未命中则查数据库，写入缓存后返回

写入流程：

1、更新数据库
2、删除缓存

优点：

实现简单，缓存不负责数据加载

缺点：

首次请求必然穿透到数据库

[2]写穿透模式（Write-Through）

写入流程：

1、先更新缓存
2、缓存组件同步更新数据库

优点：

确保缓存和数据库强一致性

缺点：

写入延迟高

[3]写回模式

写入流程：

1、只更新缓存
2、异步批量更新数据库

优点：

写入性能高

缺点：

存在数据丢失风险

【2】删除与更新策略

[1]先更新数据库再删除缓存

1、更常用，减少脏数据窗口
2、但删除缓存失败会导致不一致

[2]先删除缓存再更新数据库

1、可能会导致"脏读"问题
2、读请求可能在删除后、更新前将旧数据加载到缓存

【3】一致性保障机制

[1]双删策略

1、先删除缓存
2、更新数据库
3、延迟一段时间后再次删除缓存

解决并发读导致的脏数据问题

[2]消息队列补偿

1、通过消息队列异步处理缓存更新
2、确保最终一致性

[3]版本号/时间戳

1、数据携带版本信息
2、只接受版本更高的更新

4、实际应用建议

1、根据业务需求选择策略：强一致性要求高的场景用写穿透模式，可接受最终一致性的用旁路缓存模式
2、设置合理的缓存过期时间：即使不一致也有自动恢复机制
3、监控和告警：即使发现不一致情况
4、考虑读写比例：读多写少适合旁路缓存模式，写多读少考虑写穿透模式

5、典型问题场景

1、缓存击穿后并发重建：使用互斥锁防止多个请求同时重建缓存
2、主从延迟：主库更新后从库可能还未同步，导致读取到旧数据
3、热点数据竞争：对热点key采样本地缓存或分布式锁