数据库与redis缓存一致性问题解决方案

缓存数据同步的常见方式有三种：

• 设置有效期：给缓存设置有效期，到期后自动删除。再次查询时更新
  • 优势：简单、方便
  • 缺点：时效性差，缓存过期之前可能不一致
  • 场景：更新频率较低，时效性要求低的业务
• 延时双删：在修改数据库的同时，直接修改缓存
  • 优势：时效性强，缓存与数据库强一致
  • 缺点：有代码侵入，耦合度高；
  • 场景：对一致性、时效性要求较高的缓存数据
• 异步通知（MQ或监听bin log）：修改数据库时发送事件通知，相关服务监听到通知后修改缓存数据
  • 优势：低耦合，可以同时通知多个缓存服务
  • 缺点：时效性一般，可能存在中间不一致状态
  • 场景：时效性要求一般，有多个服务需要同步

延时双删的方案来解决，思路是，更新完数据库之后，再sleep一段时间，然后再次删除缓存。

sleep的时间要对业务读写缓存的时间做出评估，sleep时间大于读写缓存的时间即可。

延时双删方案执行步骤
1.删除redis
2.更新数据库
3.延时N秒(N秒的时间要大于一次写操作的时间，一般为3-5秒)
4.删除redis

• 问题一：为何要延时N秒？
  这是为了我们在第二次删除redis之前能完成数据库的更新操作。
  假象一下，如果没有第三步操作时，有很大概率，在两次删除redis操作执行完毕之后，数据库的数据还没有更新，此时若有请求访问数据，便会出现我们一开始提到的那个问题。
• 问题二: 为何要两次删除redis?
  如果我们没有第二次删除操作，此时有请求访问数据，有可能是访问的之前未做修改的redis数据，删除操作执行后，redis为空，有请求进来时，便会去访问数据库，此时数据库中的数据已是更新后的数据，保证了数据的一致性。

比如基于 RocketMQ 的可靠性消息通信，来实现最终一致性。

方案四：订阅mysql的binlog

我们可以借助监听binlog的消息队列来做删除缓存的操作。这样做的好处是，删除动作无需侵入到业务代码，消息中间件帮你做了解耦，同时，中间件的这个东西本身就保证了高可用。

4、总结

删除缓存有两种方式

针对缓存一致性要求不是很高的场景，那么只通过设置超时时间就可以了

• 延迟双删用比较简洁的方式实现 mysql 和 redis 数据最终一致性，但它不是强一致。
• 延迟，是因为 mysql 和 redis 主从节点数据同步不是实时的，所以需要等待一段时间，去增强它们的数据一致性。
• 延迟是指当前请求逻辑处理延时，而不是当前线程或进程睡眠延迟。
• mysql 和 redis 数据一致性是一个复杂的课题，通常是多种策略同时使用，例如：延迟双删、redis 过期淘汰、通过路由策略串行处理同类型数据、分布式锁等等。

• 删除缓存失败怎么办？

  其实先写数据库，再删缓存的方案，跟缓存双删的方案一样，有一个共同的风险点，即：如果缓存删除失败了怎么办？

  方案一：设置过期时间

  缓存设置一个过期时间，比如5分钟。当然这种方案只适合数据更新不是太频繁的业务。

  方案二：同步重试

  在接口中判断是否删除成功，如果失败就重试，直到成功或超过最大重试次数为止，返回数据。当然，这种方案的缺点就是可能影响接口性能。

  方案三：消息队列

  将删除缓存任务写入mq等消息中间件中，在mq的consumer中处理。但问题也很多：

• 引入消息中间件之后，问题更复杂了，对业务代码有一定侵入性、消息丢失怎么办
• 消息本身的延迟也会带来短暂的不一致性，不过这个延迟相对来说还是可以接受的

• 先删除缓存，再更新数据库。解决方案是使用延迟双删。

• 先更新数据库，再删除缓存。解决方案是消息队列或者监听binlog同步，引入消息队列会带来更多的问题，对业务代码有一定侵入性，并不推荐直接使用。