核心流程

1. 删除数据库同步删除缓存：

缩小可能发生脏数据的时间窗

2. Binlog + MQ删除缓存：

兜底所有入口，避免遗漏删除缓存场景，同时通过MQ的消息重试保证缓存一定删除成功

3. 监听Binlog延迟N秒进行数据一致性校验：

每个更新操作后延迟校验数据库与缓存的一致性，异常则修复，解决极端场景下的脏数据问题

4. 过期删除缓存：

刚更新过的缓存存在不一致性的概率相对会大很多，因此可以在更新场景下设置更小的过期时间

5. 存在数据库更新的链路禁用缓存：

因为数据库更新后，立刻查询缓存，缓存可能还没来的及更新，此时可直接查询数据库降低读脏数据风险

6. 【集群问题】强制读Redis主节点：

更新Redis后，立刻读取，如果读的是从节点，可能数据不是最新的，此时可强制读主节点降低读脏数据风险

7. 【监控分析】查询异步数据一致性校验：

查询完数据库之后，通过线程池再异步的查一次缓存，将数据库数据和缓存数据做比较，结果进行打点统计，如果概率超1%说明流程还不可靠，需分析不一致性数据，分析原因，继续优化。如果概率小于0.01%，证明流量基本可靠。

8. 【灰度放量】新方案试点后再逐步放开：

没有经过线上验证的方案，不要全切，让风险可控，逐步放开

设计流程图：

参考文章：https://blog.csdn.net/v123411739/article/details/124237900