缓存失效方案

一、背景

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

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

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

二、缓存失效方案

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

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

	脏数据生成时间窗口	脏数据存在时间窗口
Redis有数据	T0 - T2（小于Mysql主从延迟耗时）	T0 - T2 期间生成的，那么脏数据存在时间是生成那刻 —— 下次更新前。
Redis没有数据	T1 - T2 （Mysql主从延迟耗时）	1、若是 T1 - T0 期间生成的，那么脏数据存在时间 T1 - T0 2、若是 T0 - T2 期间生成的，那么脏数据存在时间是生成那刻 —— 下次更新前。

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

	脏数据生成时间窗口	脏数据存在时间窗口
Redis存在数据	无，存在缓存不重新生成	T1 - T0
Redis不存在数据	T1 - T2（Mysql主从延迟耗时）	写入Redis那一刻 —— T0 （Mysql主从延迟耗时 + binlog消息发送与拉取耗时）

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

	脏数据生成时间窗口	脏数据存在时间窗口
Redis存在数据	T0 - T2 因为 T1 - T0 期间有缓存，所以不重新生成，那么 肯定是 T0 - T2 期间生成的	T1 - T5
Redis不存在数据	T1 - T2（Mysql主从延迟耗时）	1、若是 T1 - T0 期间生成的，那么脏数据存在时间 T1 - T0 2、若是 T0 - T2 期间生成的，T0 - T5

2.4 三种方案对比

方案	脏数据生成时机窗口	脏数据可能存在的时间窗口	改造复杂度
方案1：同步失效	MySQL 主从延迟期间	可能很长，无法容忍 生成那刻 —— 下次更新前。	中，所有更新操作同步失效
方案2：监听binlog失效缓存	MySQL 主从延迟期间	Mysql主从延迟耗时 + binlog消息发送与拉取耗时	简单，接入Binlog统一失效
方案3：同步失效缓存 + 监听binlog失效缓存	MySQL 主从延迟期间	Mysql主从延迟耗时 + binlog消息发送与拉取耗时	复杂，接入DTS统一失效 + 所有更新操作同步失效

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