缓存失效方案

0、背景

WRITE ： 数据写入Mysql 和 Redis缓存，

READ：先从 Redis 缓存中取数据，拿不到再从Mysql中加载，更新到Redis

一、传统方案的缺点

1.1 删除场景

1.1.1 先删 Redis 再删 Mysql （不一致场景如下图）

线程1：删除Redis，

线程2：查询不到，去查Mysql，然后设置到 Redis中去

线程1：删除Mysql数据

此时 Redis 与 Mysql的数据不一致。

 1.1.2 先删 Mysql 再删 Redis （不一致场景如下图）

线程1：缓存过期，查询不到，去查Mysql

线程2：删除 Mysql 数据

线程2：删除 Redis 数据

线程1：Mysql 的数据设置到 Redis 中去

此时 Redis 与 Mysql的数据不一致。

update的场景和上述是一模一样的。 （并且上述都是指考虑单机，还没考虑Redis集群和Mysql集群的主从同步问题）

二、监听 binlog方案

上图第三阶段，接收Mysql的binlog变更消息，可以参考阿里的 Canal，接入 Kafka

2.1、缓存失效方案

脏数据定义：Redis中取到的数据，不是Mysql-Master中的数据

2.1.1 同步失效（写Mysql后同步失效Redis缓存）

2.1.2 接收到Binlog的MQ消息后，失效Redis缓存

 2.1.3 同步失效 + 接收到Binlog的MQ消息后，失效Redis缓存

2.1.4 三种方案对比

建议：直接方案2 ，方案3 如果存在太多update场景的话，入口太多。