引言
缓存与数据库的一致性即更新数据库中的记录后，缓存的数据也可要同步更新，不然会读到脏数据。事实上我们是无法保证缓存与数据库中的强一致性的，一定会有延迟，我们只能保证其最终一致性。
首先要明确的是，我们不更新缓存的数据，而是删除缓存，然后由下个请求去去缓存，发现不存在后再读取数据库，写入缓存。因为操作简单，带来的副作用也只是一次cache miss而已，删除缓存可能会因为线程安全的原因导致脏数据，比如线程a，b先后更新数据库，但是由于网络阻塞等原因，更新缓存的顺序是b，a，从而导致脏数据。
明确了删除缓存而非更新缓存的原则后，实现一致性无外乎就两种思路：
- 先删除缓存，再更新数据库
- 先更新数据库，再删除缓存
下面我们深入剖析这两种思路，看看谁优谁劣？
先缓存后数据库
考虑这种情况：
（1）请求 A 进行写操作，删除缓存
（2）请求 B 查询发现缓存不存在
（3）请求 B 去数据库查询得到旧值
（4）请求 B 将旧值写入缓存
（5）请求 A 将新值写入数据库
上述情况下，即使A删除了缓存，缓存中依然存在脏数据，如果没有设置过期时间，这个脏数据永远不会被清除。
这么看来这种思路并非最优解，但是上有政策下有对策，聪明的程序员们想到了使用“延迟双删”来解决这个问题。还是这个问题，使用延迟双删是这样执行的：
（1）请求 A 进行写操作，删除缓存
（2）请求 B 查询发现缓存不存在
（3）请求 B 去数据库查询得到旧值
（4）请求 B 将旧值写入缓存
（5）请求 A 将新值写入数据库
（6）请求A休眠一秒，再次删除缓存
延迟双删策略下每次更新数据库都会二次删除缓存，确保读请求结束，写请求可以删除读请求造成的缓存脏数据。
先数据库再缓存
这种方式同样会有问题，考虑这种情况：
（1）缓存刚好失效
（2）请求 A 查询数据库，得一个旧值
（3）请求 B 将新值写入数据库
（4）请求 B 删除缓存
（5）请求 A 将查到的旧值写入缓存
但是实际上很难发生这种情况，因为请求A查询完数据库一般很快就会写入缓存，很难等到 请求B更新完数据库再删除删除 还没写入缓存。如果真发生这种情况，同样可以使用延迟双删解决。
因此，保证缓存与数据库一致性一般情况下应先更新数据库，再删除缓存。
重试机制
看似问题都解决了，其实还有一个因素没有考虑到，那就是缓存删除失败怎么办？无论是第一次还是第二次，只要缓存删除失败都有可能会造成脏数据未被清空，所以我们需要重试机制保证删除缓存成功
方案一：异步重试
把需要删除的key发送至消息队列，自己消费信息，获取需要删除的key进行重试删除操作，直至成功
这种方案的缺点是需要维护消息队列，还会对业务代码造成侵入
方案二：订阅bin log
更新数据库数据时，数据库会将操作信息写入 binlog 日志当中，订阅程序提取出所需要的数据以及 key，另起一段非业务代码，获得该信息，尝试删除缓存操作。发现删除失败将这些信息发送至消息队列 重新从消息队列中获得该数据，重试操作。
总结
如果我们要保证缓存与数据库的一致性，一般情况下选择先更新数据库再删除缓存，配合消息队列或者订阅binlog的方式防止删除缓存失败。此外，如果对缓存中数据的实时性要求不高，可以等待key过期，这样也能保证一致性。