上篇总结了缓存中出现频率比较高的一些问题，今天详细说说web应用中的缓存一致性问题。

主要说以下三个方面

• 数据库与缓存中数据不一致出现的情形
• 发生不一致时的优化思路
• 如何保证数据库与缓存的一致性

先来讨论下结论

由于操作缓存与操作数据库不是原子的，所以非常有可能出现执行失败的情况。

假设先写数据库，再淘汰缓存：这时候如果出现写数据库成功，淘汰缓存失败，则会出现DB中是新数据，cache中是旧数据，数据不一致，此时获取数据仍然为旧数据，在cache失效之前，获取的数据均为异常数据如下:

假设先淘汰缓存，再写数据库：第一步淘汰缓存成功，第二步写数据库失败，则只会引发一次cache miss

综上，在涉及缓存操作时应该先淘汰缓存，再修改数据

不一致出现的情形

在分布式环境下，数据的读写都是并发的，上游有多个应用，通过一个服务的多个部署（为了保证可用性，一定是部署多份的），对同一个数据进行读写，在数据库层面并发的读写并不能保证完成顺序，也就是说后发出的读请求很可能先完成（读出脏数据）：

（1）发生了写请求A，A的第一步淘汰了cache

（2）A的第二步写数据库，发出修改请求

（3）发生了读请求B，B的第一步读取cache，发现cache中是空的

（4）B的第二步读取数据库，发出读取请求，此时A的第二步写数据还没完成，读出了一个脏数据放入cache

即在数据库层面，后发出的请求4比先发出的请求2先完成了，读出了脏数据，脏数据又入了缓存，缓存与数据库中的数据不一致出现了

不一致优化思路

如果能做到先发出的请求先执行完成，那是不是能避免这个问题呢？答案是肯定的。那如何能达到这个目的？这里提供2个思路。

第一个是mysql的可串行化

可串行化——SERIALIZABLE

事务的最高级别，在每个读的数据行上，加上锁，使之不可能相互冲突，因此，会导致大量的超时现象。

同一个数据用同一个链接

在用连接池进行访问数据库的时候，针对同一个数据的DB访问，使用同一个链接进行操作，这样也可以达到先发出的请求完成之后才会进行下一个访问。