分布式缓存数据库一致性问题

缓存和数据库一致性问题，有很多解决方案，没有最完美的方案，只有适合自身业务的尽可能完美的方案。

缓存由于其高并发和高性能的特征，已经在项目中被广泛应用。

查询时一般先查询缓存，如果缓存命中的话，那么直接将数据返回。

如果缓存中没有数据（如失效，或者根本没设置数据），那么，应用程序先从数据库中查询数据，如果不为空，则将数据放在缓存中。

那么更新时，怎么处理缓存和数据库呢？先更新数据库后更新缓存？或者先淘汰缓存后更新数据库？

为什么没有先更新缓存后更新数据库？

1）：如果更新数据库失败，那么就造成了数据不一致

先更新数据库后更新缓存的问题：

1）：两个线程并发更新数据库再更新缓存可能出现缓存更新顺序问题

2）：如果更新频繁，读少的情况，那么缓存也被频繁更新，造成不必要的开销

3）：如果缓存的值是需要经过一系列复杂计算的，那么每次都去更新缓存无疑是浪费性能的

先删缓存后更新数据库的问题：

1）：线程A删除缓存更新完数据库前，线程B没有命中缓存，从数据库中查询到了更新前的值存入缓存中

解决方案：延时双删策略（推荐使用）

即先删除缓存，再更新数据库，休眠一段时间，再删除缓存

伪代码如下：

public void write(String key,Object data){
    redis.delKey(key); 
    db.updateData(data); 
    Thread.sleep(1000); redis.delKey(key);
 }

为什要休眠1秒钟？为了将这1秒内造成的脏数据删除，可能有线程读取到了更新前的旧数据还未来得及写入缓存

休眠的时间多少如何确定？评估自身项目读数据业务逻辑的耗时，在这基础了加100ms即可。可以确保脏数据已经写入缓存中

读写分离怎么办？

也是采用延时双删策略，休眠时间确保完成主从同步

为了避免休眠造成吞吐量降低，可以将第二次删除作为异步操作

第二次删除失败怎么办？

删除在更新期间写入缓存的旧值失败

解决方案：将需要删除的key发送到消息队列，然后自己消费消息，获得需要删除的key，继续重试删除操作，直到成功。

先更新数据库后删缓存

即Cache Aside Pattern，即缓存旁路模式

失效：应用程序先从缓存中取数据，没有取到，则从数据库中取数据，成功后，放到缓存中

命中：应用程序从缓存中渠道数据，然后返回

更新：先把数据存到数据库中，成功后，再删除缓存