redis缓存和MysqL数据一致性方案详解

• 方案1：延时双删策略
• 方案2：异步更新缓存（基于订阅binlog的同步机制）

需求起因

1. 在高并发的业务场景下，数据库访问成为用户并发最薄弱的环节，所以就需要redis做一个缓冲操作，
   让请求先访问到redis，而不是直接访问MysqL数据库
2. 读取redis缓存一般没有什么问题，但是一旦涉及到数据更新，更新数据库和redis缓存，
   就容易出现缓存redis和数据库MysqL间的数据一致性问题
3. 不管是先写库，在删除缓存；还是先删除缓存，在写库，都有可能出现数据不一致的问题，比如

• 先删除缓存，还没来得及写入MysqL，此时另外一个线程来读了，发现缓存没有，就去库里读并写入缓存，此时的缓存就是脏数据
• 先写入MysqL库，在删除缓存前，写库的线程挂了，没有删除掉缓存，也会出现数据不一致的情况

方案1：采用延时双删策略

1. 在写库前后都进行redis.del(key)操作，并且设定合理的超时时间
   步骤：先删除缓存---写入数据库---休眠500Ms---在删除缓存
   休眠500ms的意思就是写请求可以删除读请求造成的脏数据
2. 设置缓存过期时间
   从理论上讲，给缓存设置过期时间，是保证最终一致性的解决方案，所有的写操作都以数据库为准
   只要缓存达到过期时间，则后面的读请求自然会从数据库中读取数据然后填回缓存
3. 弊端：
   结合双删策略+缓存超时时间，这样最差的情况就是在超时时间内数据存在不一致，而且又增加了写请求的耗时

异步更新缓存（基于订阅binlog的同步机制）

1. 读取binlog后分析，利用消息队列，推送到各台的redis缓存数据
   可以采用阿里开源的canal框架订阅MysqL的binlog，来实现推送更新redis