根据以上的流程没有问题，但是当数据变更的时候，如何把缓存变到最新，使我们下面要讨论的问题

1. 更新数据库再更新缓存

场景：数据库更新成功，但缓存更新失败。

问题：

• 当缓存失效或过期时，读取到的可能是旧数据。这样会导致读取到的不一致数据，从而影响系统的正确性和用户体验。

2. 更新缓存再更新数据库

场景：缓存更新成功，但数据库更新失败。

问题：

• 此时，读取的缓存可能是错误的，因为数据库的状态并未同步到缓存。这会导致后续的数据查询不准确，从而影响业务逻辑。

3. 先删除缓存再更新数据库

优点：

• 这种方式在一定程度上缓解了数据不一致的问题。即使数据库更新失败，缓存也会被清空。

问题：

• 高并发场景下的问题：
  • 假设有两个线程 A 和 B：
    • A 线程删除了缓存并正在更新数据库。
    • B 线程发现缓存已被删除，便去查询数据库并将旧数据放入缓存。
  • 结果是，B 线程可能会将过时的数据写入缓存，导致后续的请求获取到过期数据。

延迟双删策略

为了解决上述问题，可以采用延迟双删的策略：

1. 步骤：

   • 在删除缓存后，更新数据库。
   • 数据库更新成功后，再次删除缓存。

2. 目的：

   • 第一次删除缓存是为了确保下次请求能重新加载最新数据。
   • 第二次删除是为了确保即使在高并发情况下，B 线程获取到的旧缓存也能被及时清除(但延迟双删存在一个潜在问题：在第二次删除缓存的过程中，如果有新的线程访问缓存，这些线程仍然有可能获取到旧数据，导致系统状态不一致)

扩展思路

1. 消息队列补偿机制：

   • 当缓存删除失败时，可以将失败信息作为消息发送到消息队列（MQ）。
   • MQ 消费者监听这些消息，并进行重试，确保缓存得到正确的更新。
   • 优点：异步处理，提高系统的可用性与稳定性。

2. Canal：

   • 通过 Canal 等工具监听数据库的变化。
   • 将数据库变更事件发送到缓存刷新服务。
   • 优点：业务逻辑解耦，减少冗余代码，提高系统的复杂度可管理性。