只要用到redis，就可能会涉及到缓存与数据库的存储双写，只要是双写，就一定会有数据一致性的问题，因为这是两个原子操作（写数据库，写缓存）。
方案一：Cache Aside Pattern（旁路缓存模式）
最经典的缓存+数据库读写的模式，就是 Cache Aside Pattern：
1、读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。
2、更新的时候，先更新数据库，然后再删除缓存
问题一：为什么是删除缓存而不是更新缓存
1、线程A先发起一个写操作，第一步先更新数据库；
2、线程B再发起一个写操作，第二步更新了数据库；
3、由于网络等原因，线程B先更新了缓存；
4、线程A更新缓存。
这时候，缓存保存的是A的数据（老数据），数据库保存的是B的数据（新数据），数据不一致了，脏数据出现啦。如果是删除缓存取代更新缓存则不会出现这个脏数据问题。
问题二：删除缓存失败怎么办呢？
如果删除缓存失败，则会存在较长时间的数据不一致，这个时间会一直持续到缓存过期。
方案二：删除缓存重试机制（基于方案一优化）
在方案一种，如果删除缓存失败，则会存在较长时间的数据不一致，通常有一下几种解决办法：
1、延迟双删策略
延迟双删是先删Cache，后写DB，最后延迟一定时间，再次删Cache。
缺点：
（1）如果写操作比较频繁，可能会对Redis造成一定的压力；
（2）极端情况下，第二次延迟删Cache失败，还是会存在数据不一致问题；
所以实际上生产中应用较少
2、基于队列删缓存
引入高可用RocketMq消息队列之后，执行双写操作的Provider A的操作流程，有小幅度的调整。Provider A需要将删除Cache的操作，序列化成Rocketmq消息，然后写入高可用Rocketmq消息队列中间件即可。然后，由专门的消费者（Cache Delete Consumer）进行消息的消费，根据消息内容执行Cache记录删除工作。
DB和Redis双写的场景下，Provider A先更数据库，后基于消息队列删缓存的并发执行案例的执行流程
引入高可用的独立组件RocketMq消息队列之后，Provider A的写入逻辑变得很简单，删Cache的时候，只需要发送消息到RocketMq即可，大大简化了Provider A程序的写入逻辑。只是为了保证消息的高可靠传递，这里Provider A在发送消息的时候，需要使用同步发送模式，而不能使用异步发送的模式。
在消息投递的环节，由RocketMq高可用组件的ACK机制保证消息的高可靠投递。如果消息第一次消费失败，RocketMq会重复多次进行投递，确保消息被正常消费，如果一直不能被成功消费，在重复投递一定的次数之后（默认16次），消息会进入死信队列。系统的监控程序会对死信队列进行监控，一旦发现死信消息，监控程序会进行运维告警，由运维人员解决最终的缓存删除问题。除非Redis集群崩溃，一般都不会出现这样的极端情况。
3、队列删除缓存重试机制
直接基于队列删缓存，还是会存在一定的性能风险，比如消息队列阻塞，实际上我们生产环境的redis集群99%的时间是很稳定的，删除缓存不会失败，所以
我们可以先删除缓存，只有删除失败了，才通过消息队列重试再删除缓存。如下图
4、binlog异步删除缓存
通过队列删除缓存重试机制，虽然还不错，但是有业务代码侵入，可以通过binlog异步删除缓存，如下
不过这种方案限制性挺多，很多场景下，redis key跟数据库中变动的数据不一定能匹配，就是说，通过解析单一的binlog，还原不了key。所以通常还是推荐
第三种队列删除缓存重试机制，把删除缓存（重试删除）操作封装一下，业务调用方直接调用即可。
