一、背景
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场景的话，入口太多。
