Redis和Mysql 如何保证一致性

方案有三：

- 更新MySQL即可，不管Redis，以过期时间兜底

- 更新MySQL之后，操作Redis

- 异步将MySQL的更新同步到Redis

（1）方案一

使用redis的过期时间，mysql更新时，redis不做处理，等待缓存过期失效，再从mysql拉取缓存。

这种方式实现简单，但不一致的时间会比较明显，具体由你的业务来配置。如果读请求非常频繁，且过期时间设置较长，则会产生很多脏数据。

（2）方案二

不光通过key的过期时间兜底，还需要在更新mysql时，同时尝试操作redis，这里的操作分两种方式，1是更新，直接将结果写入Redis，但实际上很少用更新，而是用删除，等待下次访问再加载回来，为什么呢?因为更新容易带来时序性问题。

（3）方案三

「先更新数据库，再删缓存」的策略的第一步是更新数据库，那么更新数据库成功，就会产生一条变更日志，记录在 bin log 里。

于是我们就可以通过订阅 bin log 日志，拿到具体要操作的数据，然后再执行缓存删除，

把我们搭建的消费服务作为mysql的一个slave，订阅mysql的bin log日志，解析日志内容，再更新到redis。此方案和业务完全解耦，redis的更新对业务方透明，可以减少心智成本。

优点:

- 和业务完全解耦，在更新mysql时，不需要做额外操作;

- 无时序性问题，可靠性强。

缺点:

- 引入了消息队列这种算比较重的组件，还要单独搭建一个同步服务，维护他们是非常大的额外成本

- 同步服务如果压力比较大，或者崩溃了，那么在较长时间内，redis中都是老旧数据

方案选型：

- 首先确认产品上对延迟性的要求，如果要求极高，且数据有可能变化，别用缓存。

- 通常来说，过期时间兜底是行之有效的办法，根据实时性期待不一样，可以增加个删除逻辑，提升一致性

- 长期需要存在的一批数据，那么用消息队列来更新，是一个不错的办法。

总结

cache Aside (旁路缓存模式即可)+基于bin log最终一致性