在这里，我们讨论三种更新策略：
1.先更新数据库，再更新缓存
2.先删除缓存，再更新数据库
3.先更新数据库，再删除缓存

1.先更新数据库，再更新缓存
  1. 线程A更新了数据库
  2. 线程B更新了数据库
  3. 线程B更新了缓存
  4. 线程A更新了缓存

这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。这就导致了脏数据，因此不考虑。

2.先删除缓存，再更新数据库
  1. 请求A进行写操作，删除缓存
  2. 请求B查询发现缓存不存在
  3. 请求B去数据库查询得到旧值
  4. 请求B将旧值写入缓存
  5. 请求A将新值写入数据库

解决方案：采用延时双删策略

  1. 先淘汰缓存
  2. 再写数据库（这两步和原来一样）
  3. 休眠1秒，再次淘汰缓存

如果你用了mysql的读写分离架构怎么办？
一个请求A进行更新操作，另一个请求B进行查询操作。

  1. 请求A进行写操作，删除缓存
  2. 请求A将数据写入数据库了，
  3. 请求B查询缓存发现，缓存没有值
  4. 请求B去从库查询，这时，还没有完成主从同步，因此查询到的是旧值
  5. 请求B将旧值写入缓存
  6. 数据库完成主从同步，从库变为新值
    上述情形，就是数据不一致的原因。还是使用双删延时策略。只是，睡眠时间修改为在主从同步的延时时间基础上，加几百ms。

采用这种同步淘汰策略，吞吐量降低怎么办？
那就将第二次删除作为异步的。自己起一个线程，异步删除。这样，写的请求就不用沉睡一段时间后了，再返回。这么做，加大吞吐量。

第二次删除,如果删除失败怎么办？

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

假设这会有两个请求，一个请求A做查询操作，一个请求B做更新操作，那么会有如下情形产生

  1. 缓存刚好失效
  2. 请求A查询数据库，得一个旧值
  3. 请求B将新值写入数据库
  4. 请求B删除缓存
  5. 请求A将查到的旧值写入缓存
    ok，如果发生上述情况，确实是会发生脏数据。

解决方案：
首先，给缓存设有效时间是一种方案。其次，采用策略（2）里给出的异步延时删除策略，保证读请求完成以后，再进行删除操作。

如何解决删缓存失败？

提供一个保障的重试机制即可，这里给出两套方案。

redis作为一级缓存 redis缓存一致性解决方案_缓存


流程如下所示

（1）更新数据库数据；

（2）缓存因为种种问题删除失败

（3）将需要删除的key发送至消息队列

（4）自己消费消息，获得需要删除的key

（5）继续重试删除操作，直到成功

然而，该方案有一个缺点，对业务线代码造成大量的侵入。于是有了方案二，在方案二中，启动一个订阅程序去订阅数据库的binlog，获得需要操作的数据。在应用程序中，另起一段程序，获得这个订阅程序传来的信息，进行删除缓存操作。

redis作为一级缓存 redis缓存一致性解决方案_更新数据_02


（1）更新数据库数据

（2）数据库会将操作信息写入binlog日志当中

（3）订阅程序提取出所需要的数据以及key

（4）另起一段非业务代码，获得该信息

（5）尝试删除缓存操作，发现删除失败

（6）将这些信息发送至消息队列

（7）重新从消息队列中获得该数据，重试操作。

备注说明：上述的订阅binlog程序在mysql中有现成的中间件叫canal，可以完成订阅binlog日志的功能。至于oracle中，博主目前不知道有没有现成中间件可以使用。另外，重试机制，博主是采用的是消息队列的方式。如果对一致性要求不是很高，直接在程序中另起一个线程，每隔一段时间去重试即可，这些大家可以灵活自由发挥，只是提供一个思路。