- 先更新数据库，再删除缓存
- 先更新数据库，再更新缓存
- 先删除缓存，再更新数据库
- 先更新缓存，再更新数据库
- 解决方案
- 使用 CAS
- 使用分布式锁
- 异步更新
- 延时双删
执行写操作时，需要确保从缓存读取到的数据与数据库中持久化的数据一致。为此，需要对缓存进行更新，但由于涉及到数据库和缓存两步操作，难以保证更新的原子性。因此，在设计更新策略时，需要考虑多个方面的问题。首先，需要考虑更新缓存策略和删除缓存策略对系统吞吐量的影响。比如，更新缓存策略产生的数据库负载小于删除缓存策略的负载。其次，需要考虑并发安全性。并发读写时，某些异常操作顺序可能造成数据不一致，例如缓存中长期保存过时数据。此外，还需要考虑更新失败的影响，以及如何对业务影响降到最小。最后，需要考虑检测和修复故障的难度。操作失败导致的错误会在日志留下详细的记录，容易检测和修复。并发问题导致的数据错误没有明显的痕迹，难以发现，且在流量高峰期更容易产生并发错误，产生的业务风险较大。
更新缓存有两种方式：删除失效缓存和更新缓存。删除失效缓存时，读取时会因为未命中缓存而从数据库中读取新的数据并更新到缓存中。更新缓存时，直接将新的数据写入缓存覆盖过期数据。更新缓存和更新数据库有两种顺序：先数据库后缓存和先缓存后数据库。两两组合共有四种更新策略，需要逐一进行分析。并发问题通常由于后开始的线程却先完成操作导致，我们把这种现象称为“抢跑”。下面我们逐一分析四种策略中“抢跑”带来的错误。
先更新数据库，再删除缓存
若数据库更新成功，删除缓存操作失败，则此后读到的都是缓存中过期的数据，造成不一致问题。
可能存在读写线程竞争导致的并发错误
先更新数据库，再更新缓存
同删除缓存策略一样，若数据库更新成功缓存更新失败则会造成数据不一致问题。
该策略同样存在读写线程竞争导致数据不一致的问题:
也可能因为两个写线程竞争导致并发错误:
先删除缓存，再更新数据库
可能发生的并发错误:
先更新缓存，再更新数据库
若缓存更新成功数据库更新失败， 则此后读到的都是未持久化的数据。因为缓存中的数据是易失的，这种状态非常危险。
因为数据库因为键约束导致写入失败的可能性较高，所以这种策略风险较大。
可能发生的并发错误:
两个写线程竞争也会导致数据不一致:
解决方案
使用 CAS
CAS (Check-And-Set 或 Compare-And-Swap)是一种常见的保证并发安全的手段。CAS 当且仅当客户端最后一次取值后该 key 没有被其他客户端修改的情况下，才允许当前客户端将新值写入。
由上图可见，CAS 可以有效的避免并发错误的发生。
目前一些兼容 Redis 协议的中间件已经提供了 CAS 命令的支持，比如阿里的 Tair 以及腾讯的 Tendis。
Redis 官方提供了 Watch + 事务的方法来支持 CAS, 或者使用 redis 中 lua 脚本原子性执行的特点来实现 CAS。不过由于代码较为复杂，这两种方案都不常见。
使用分布式锁
CAS 假设发生并发问题的概率不大, 所以 CAS 也被称为乐观锁。那么悲观锁能否解决我们的问题呢？
还是以「先更新数据库，再更新缓存」方案中两个写线程竞争为例， 我们要求任何线程在写入或读取数据库前都需要获取排它锁。
分布式锁同样可以解决并发问题，只是成本可能略高。
异步更新
阿里开源了 MySQL 数据库binlog的增量订阅和消费组件 - canal。canal 模拟从库获得主库的 binlog 更新，然后将更新数据写入 MQ 或直接进行消费。
我们可以让API服务器只负责写入数据库，另一个线程订阅数据库 binlog 增量进行缓存更新。
因为 binlog 是有序的，因此可以避免两个写线程竞争。但我们仍然需要解决读写线程竞争的问题:
这里同样可以 CAS 解千愁：
延时双删
使用删除缓存策略时读线程先开始却后写缓存会导致不一致，那么我们在读线程结束后再次清除缓存是不是就可以解除错误状态了？延时双删就是写线程等待一段时间“确保”读线程都结束后再次删除缓存，以此清除可能的错误缓存数据。
从理论上来说，我们无法给出一个确切的时间来“确保”所有读线程都已经结束，因此，在某些情况下，并发问题仍然可能存在。如果我们使用延时双删的方法，虽然无法完全消除并发问题的出现，但是可以极大地降低其出现概率。延时双删的成本相对较低，同时也是一种简单而实用的解决方法。此外，我们还可以在代码中添加一些额外的逻辑处理来更好地保障线程安全，如加锁、队列等。这些方法虽然可能会增加一些额外的开发成本，但是可以让我们的程序更加健壮、稳定。
