根据以上的流程没有问题,但是当数据变更的时候,如何把缓存变到最新,使我们下面要讨论的问题
1. 更新数据库再更新缓存
场景:数据库更新成功,但缓存更新失败。
问题:
- 当缓存失效或过期时,读取到的可能是旧数据。这样会导致读取到的不一致数据,从而影响系统的正确性和用户体验。
2. 更新缓存再更新数据库
场景:缓存更新成功,但数据库更新失败。
问题:
- 此时,读取的缓存可能是错误的,因为数据库的状态并未同步到缓存。这会导致后续的数据查询不准确,从而影响业务逻辑。
3. 先删除缓存再更新数据库
优点:
- 这种方式在一定程度上缓解了数据不一致的问题。即使数据库更新失败,缓存也会被清空。
问题:
- 高并发场景下的问题 :
- 假设有两个线程 A 和 B:
- A 线程删除了缓存并正在更新数据库。
- B 线程发现缓存已被删除,便去查询数据库并将旧数据放入缓存。
- 结果是,B 线程可能会将过时的数据写入缓存,导致后续的请求获取到过期数据。
- 假设有两个线程 A 和 B:
延迟双删策略
为了解决上述问题,可以采用延迟双删的策略:
-
步骤:
- 在删除缓存后,更新数据库。
- 数据库更新成功后,再次删除缓存。
-
目的:
- 第一次删除缓存是为了确保下次请求能重新加载最新数据。
- 第二次删除是为了确保即使在高并发情况下,B 线程获取到的旧缓存也能被及时清除(但延迟双删存在一个潜在问题:在第二次删除缓存的过程中,如果有新的线程访问缓存,这些线程仍然有可能获取到旧数据,导致系统状态不一致)
扩展思路
-
消息队列补偿机制:
- 当缓存删除失败时,可以将失败信息作为消息发送到消息队列(MQ)。
- MQ 消费者监听这些消息,并进行重试,确保缓存得到正确的更新。
- 优点:异步处理,提高系统的可用性与稳定性。
-
Canal:
- 通过 Canal 等工具监听数据库的变化。
- 将数据库变更事件发送到缓存刷新服务。
- 优点:业务逻辑解耦,减少冗余代码,提高系统的复杂度可管理性。