解决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日志及时的去修改缓存，但是引入了新的中间件，增加了系统的复杂度
总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。