以下部分节选自这里。
本文主要讨论这么几个问题：
（1）啥时候数据库和缓存中的数据会不一致
（2）不一致优化思路
（3）如何保证数据库与缓存的一致性
小马提醒，这些问题大厂面试一般会问到的概率很大。
上一篇《缓存架构设计细节二三事》引起了广泛的讨论，其中有一个结论：当数据发生变化时，“先淘汰缓存，再修改数据库”这个点是大家讨论的最多的。
上篇文章得出这个结论的依据是，由于操作缓存与操作数据库不是原子的，非常有可能出现执行失败。
假设先写数据库，再淘汰缓存：第一步写数据库操作成功，第二步淘汰缓存失败，则会出现DB中是新数据，Cache中是旧数据，数据不一致【如上图：db中是新数据，cache中是旧数据】。
假设先淘汰缓存，再写数据库：第一步淘汰缓存成功，第二步写数据库失败，则只会引发一次Cache miss【如上图：cache中无数据，db中是旧数据】。
结论：先淘汰缓存，再写数据库。这是简单地解决缓存不一致的问题，但是在分布式或者存在并发的情况下这个方式解决不了缓存不一致的问题。如下文。
引发大家热烈讨论的点是“先操作缓存，在写数据库成功之前，如果有读请求发生，可能导致旧数据入缓存，引发数据不一致”，这就是本文要讨论的主题。
也就是先淘汰缓存，再写数据库还是存在并发问题。小马看到这里其实想到了分布式锁的思路来解决，就是只允许一个请求去更新缓存。后发的请求不能也更新缓存，要等待先发的请求更新缓存完毕。下面是并发导致的不一致原因分析。
回顾一下上一篇文章中对缓存、数据库进行读写操作的流程。
写流程：
（1）先淘汰cache
（2）再写db
读流程：
（1）先读cache，如果数据命中hit则返回
（2）如果数据未命中miss则读db
（3）将db中读取出来的数据入缓存
什么情况下可能出现缓存和数据库中数据不一致呢？
在分布式环境下，数据的读写都是并发的，上游有多个应用，通过一个服务的多个部署（为了保证可用性，一定是部署多份的），对同一个数据进行读写，在数据库层面并发的读写并不能保证完成顺序，也就是说后发出的读请求很可能先完成（读出脏数据）：
（a）发生了写请求A，A的第一步淘汰了cache（如上图中的1）
（b）A的第二步写数据库，发出修改请求（如上图中的2）
（c）发生了读请求B，B的第一步读取cache，发现cache中是空的（如上图中的步骤3）
（d）B的第二步读取数据库，发出读取请求，此时A的第二步写数据还没完成，读出了一个脏数据放入cache（如上图中的步骤4）
即在数据库层面，后发出的请求4比先发出的请求2先完成了，读出了脏数据，脏数据又入了缓存，缓存与数据库中的数据不一致出现了。
相关阅读：
