使用缓存的时候，我们需要关注Redis与DB数据的一致性。如果Redis缓存与DB数据不一致，就可能导致用户一直只能获取到数据错误的缓存，严重影响用户体验。那如何让Redis与DB数据一致性呢？
如何保证数据库和缓存的一致性
首先我们来讨论几个更新时的方案吧，我将从各个方案进行剖析，让你知道这些方案会出现的问题，并且最终会得出如何保证数据库和缓存的一致性。(使用的图解皆来源于网络)
先更新缓存再更新数据库
我们来举个例子，在并发情况下，请求A 和 请求B 两个请求，同时更新同一个数据时，什么样的执行流程会导致数据不一致。
如图，如果请求A先更新了缓存(值为1)，请求B在它之后也更新了缓存(值为2)，然后请求B继续执行，把数据库更新为2，之后请求A也继续执行，把数据库更新为1。
此时，缓存的值为2，数据库的值为1。很明显，出现了缓存不一致的情况。那我们再换一种思路试试看？
先更新数据库再更新缓存
我们也来分析一下这种情况下，什么样的顺序会出现缓存不一致。
请求A把数据库数据更新为1，之后请求B把数据库更新为2。接着，缓存被请求B更新为2，缓存再被请求A更新为1。
很明显，这种思路也会出现数据不一致的情况。至此，同时更新缓存和数据库的方案，都明显出现了数据不一致的现象，那还有什么其他的思路可以用吗？
有的，更新数据库的同时删除缓存，当缓存未命中时，查询缓存。那我们按照这个思路来进行分析。
先删除缓存再更新数据库
如图，我们能够分析出，请求A先删除了缓存，请求B在其之后发现缓存未命中然后就去读取数据库更新缓存，最后请求A再更新了数据库。此时缓存为20，数据库为21，出现了不一致。实际上，只有数据库更新后，再被查询数据时，才会是更新后的数据。按照这个思路，又引出了另一种策略。
先更新数据库再删除缓存
请求A发现缓存没有命中，然后去请求数据库，之后请求B更新了数据库并删除了缓存，请求A再将数据写入缓存。可以发现，依旧是有不一致的情况发生。
前面四种策略应该怎么选择
从上面的分析来看，四种策略都是会有不一致的现象发生的。虽然是这样的没错，但是先更新数据库再删除缓存的不一致现象发生的概率会小一些，因为数据库更新是没有缓存写入快的，所以在实际中很难出现请求 B 已经更新了数据库并且删除了缓存，请求 A 才更新完缓存的情况。
所以先更新数据库再删除缓存是可以在一定程度上保证一致性的，对于可能发生的不一致情况，我们可以给数据加上过期时间作为对一致性的兜底。
不过这也仅仅是在我们的操作全部执行成功的情况下才能保证一致性，在实际情况中，由于网络等因素，我们的操作是可能会失败的，而更新数据库和删除缓存是两个操作(非原子)，所以当删除缓存失败的时候，一致性就无法保证了。
但是在一般的业务上，这四种策略已经是足够使用了，一般使用第四种。对于不同场景下，还是有不同的选择，并不一定无脑选择第四种。当你的业务是对于缓存命中率要求高的业务时，可以采用先更新数据库，再更新缓存，不过我们必须引入一些其他方法来减少不一致发生的情况。例如：
- 在更新完缓存时，给缓存加上较短的过期时间，这样即使出现缓存不一致的情况，缓存的数据也很快会保持一致。
在其他情况下，就无脑使用先更新数据库再更新缓存就行。
有没有真正能够保证一致性的方案
先说结论，是有的，但是会更加复杂。
首先我们要明确：其实不管是先操作数据库，还是先操作缓存，只要删除缓存操作失败都会出现数据一致的问题。
问题原因知道了，该怎么解决呢？有两种方法：
1.重试机制
我们可以引入消息队列，将第二个操作（删除缓存）要操作的数据加入到消息队列，由消费者来操作数据。
重试机制的大致步骤：
- 写请求更新数据库
- 缓存因为某些原因，删除失败
- 把删除失败的key放到消息队列
- 消费消息队列的消息，获取要删除的key
- 重试删除缓存操作
弊端是造成大量业务代码入侵。不过这个是小事情。
2.订阅Mysql binlog
先更新数据库，再删缓存的策略的第一步是更新数据库，那么更新数据库成功，就会产生一条变更日志，记录在 binlog 里。
于是我们就可以通过订阅 binlog 日志，拿到具体要操作的数据，然后再执行缓存删除，阿里巴巴开源的 Canal 中间件就是基于这个实现的。
这个方法我是在网上偶然看见的，还没有尝试过，有兴趣的小伙伴可以深入去了解下。
希望我的文章对大家学习缓存与DB一致性有所帮助。
