Redis的缓存与数据库双写不一致问题

一、Cache Aside Pattern

在了解这个问题之前，我们有必要知道缓存+数据库读写数据的模式，也就是Cache Aside Pattern

（1）读的时候：先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应；
（2）写的时候：先更新数据库，然后再删除缓存。
写的时候模式分析为什么是删除缓存，而不是更新缓存？：
①假设我们有10次写，若是更新缓存的话需要更新10次缓存，10次数据库，我们优化为只需要删除一次缓存，更新10次数据库，当有一个读请求过来只是没有命中，去数据库读取一下，这样对性能的影响也不是很大；
②这是 一个 lazy 计算的思想，不要每次都重新做复杂的计算，不管它会不会用到，而是让它到需要被使用的时候再重新计算。像mybatis，hibernate，都有懒加载思想。

二、缓存与数据库双写不一致

1、双写不一致情况

线程1在写数据库与更新缓存之间卡顿了一下，然后线程2在线程1卡顿的这个空隙去写了数据库并刷新了缓存，然后线程2都已经执行完了，线程1又把脏数据更新到了缓存，造成了数据库与缓存不一致。

2、读写并发不一致

先更新写操作的，由于中间网络问题或者什么问题造成更新数据推后，最后造成了脏数据的更新，导致数据库与缓存双写不一致。

三、解决方案

（1）对于并发几率很小的数据(如个人维度的订单数据、用户数据等)，这种几乎不用考虑这个问题，很少会发生缓存不一致，可以给缓存数据加上过期时间，每隔一段时间触发读的主动更新即可。
（2）就算并发很高，如果业务上能容忍短时间的缓存数据不一致(如商品名称，商品分类菜单等)，缓存加上过期时间依然可以解决大部分业务对于缓存的要求。

1、消息队列串行化

（1）主要思路：在后台进程中我们可以创建多个队列，然后根据hash算法将写请求路由到不同的队列中，当来读请求的时候，就加入队列中，当写请求处理完毕后，再去处理读请求。
（2）分析：如果对于同一份数据有多个写请求同时在队列中，那么来一个读请求中加入队列中之后，一般写请求耗时比较久，那么读请求会需要很久才能返回，这样会特别影响性能，但能保证一致性（一般情况下建议不要用）

2、加分布式锁

通过加分布式读写锁保证并发读写或写写的时候按顺序排好队，读读的时候相当于无锁。

3、用阿里开源的canal

可以用阿里开源的canal通过监听数据库的binlog日志及时的去修改缓存，但是引入了新的中间件，增加了系统的复杂度