面试官缓存一致性问题怎么解决？

　　关于Redis的其他的一些面试问题已经写过了，比如常见的缓存穿透、雪崩、击穿、热点的问题，但是还有一个比较麻烦的问题就是如何保证缓存一致性。
　　对于缓存和数据库的操作，主要有以下两种方式。先删缓存，再更新数据库
　　先删除缓存，数据库还没有更新成功，此时如果读取缓存，缓存不存在，去数据库中读取到的是旧值，缓存不一致发生。
　　解决方案延时双删
　　延时双删的方案的思路是，为了避免更新数据库的时候，其他线程从缓存中读取不到数据，就在更新完数据库之后，再sleep一段时间，然后再次删除缓存。
　　sleep的时间要对业务读写缓存的时间做出评估，sleep时间大于读写缓存的时间即可。
　　流程如下：线程1删除缓存，然后去更新数据库线程2来读缓存，发现缓存已经被删除，所以直接从数据库中读取，这时候由于线程1还没有更新完成，所以读到的是旧值，然后把旧值写入缓存线程1，根据估算的时间，sleep，由于sleep的时间大于线程2读数据+写缓存的时间，所以缓存被再次删除如果还有其他线程来读取缓存的话，就会再次从数据库中读取到最新值
　　先更新数据库，再删除缓存
　　如果反过来操作，先更新数据库，再删除缓存呢？
　　这个就更明显的问题了，更新数据库成功，如果删除缓存失败或者还没有来得及删除，那么，其他线程从缓存中读取到的就是旧值，还是会发生不一致。
　　解决方案消息队列
　　这是网上很多文章里都有写过的方案。但是这个方案的缺陷会更明显一点。
　　先更新数据库，成功后往消息队列发消息，消费到消息后再删除缓存，借助消息队列的重试机制来实现，达到最终一致性的效果。
　　这个解决方案其实问题更多。引入消息中间件之后，问题更复杂了，怎么保证消息不丢失更麻烦就算更新数据库和删除缓存都没有发生问题，消息的延迟也会带来短暂的不一致性，不过这个延迟相对来说还是可以接受的进阶版消息队列
　　为了解决缓存一致性的问题单独引入一个消息队列，太复杂了。
　　其实，一般大公司本身都会有监听binlog消息的消息队列存在，主要是为了做一些核对的工作。
　　这样，我们可以借助监听binlog的消息队列来做删除缓存的操作。这样做的好处是，不用你自己引入，侵入到你的业务代码中，中间件帮你做了解耦，同时，中间件的这个东西本身就保证了高可用。
　　当然，这样消息延迟的问题依然存在，但是相比单纯引入消息队列的做法更好一点。
　　而且，如果并发不是特别高的话，这种做法的实时性和一致性都还算可以接受的。
　　其他解决方案设置缓存过期时间
　　每次放入缓存的时候，设置一个过期时间，比如5分钟，以后的操作只修改数据库，不操作缓存，等待缓存超时后从数据库重新读取。
　　如果对于一致性要求不是很高的情况，可以采用这种方案。
　　这个方案还会有另外一个问题，就是如果数据更新的特别频繁，不一致性的问题就很大了。
　　在实际生产中，我们有一些活动的缓存数据是使用这种方式处理的。
　　因为活动并不频繁发生改变，而且对于活动来说，短暂的不一致性并不会有什么大的问题。为什么是删除，而不是更新缓存？
　　我们以先更新数据库，再删除缓存来举例。
　　如果是更新的话，那就是先更新数据库，再更新缓存。
　　举个例子：如果数据库1小时内更新了1000次，那么缓存也要更新1000次，但是这个缓存可能在1小时内只被读取了1次，那么这1000次的更新有必要吗？
　　反过来，如果是删除的话，就算数据库更新了1000次，那么也只是做了1次缓存删除，只有当缓存真正被读取的时候才去数据库加载。总结
　　首先，我们要明确一点，缓存不是更新，而应该是删除。
　　删除缓存有两种方式：先删除缓存，再更新数据库。解决方案是使用延迟双删。先更新数据库，再删除缓存。解决方案是消息队列或者其他binlog同步，引入消息队列会带来更多的问题，并不推荐直接使用。
　　针对缓存一致性要求不是很高的场景，那么只通过设置超时时间就可以了。
　　其实，如果不是很高的并发，无论你选择先删缓存还是后删缓存的方式，都几乎很少能产生这种问题，但是在高并发下，你应该知道怎么解决问题。
　　微信搜索公众号【艾小仙】回复【PDF】获取百本计算机电子书，文章每周持续更新。我是艾小仙，阿里巴巴技术专家，我们下期见！
　　- END -