「浅谈缓存一致性问题」
大约 2 分钟
来自 gpt 的摘要： 在引入缓存时，性能和一致性无法同时完全满足，一旦决定使用缓存，短期的不一致性是必须容忍的。为了确保 Redis 和 MySQL 数据的一致性，推荐采用“先更新数据库，再删除缓存”的方案，并结合消息队列或订阅变更日志的方式进一步降低不一致的风险。虽然该方案并非万无一失，但实际发生不一致的概率很低。即便出现短暂的不一致性，也可以通过缓存的失效时间来兜底，从而达到最终一致性。
写在前面
一旦我们决定使用缓存，那必然要面临一致性问题。性能和一致性就像天平的两端，无法做到都满足要求。引入缓存之后，如果为了短时间的不一致性问题，选择让系统设计变得更加复杂的话，完全没必要。
如何保证 Redis 与 MySQL 的数据一致性？
想要保证数据库和缓存一致性，推荐采用「先更新数据库，再删除缓存」方案，并配合「消息队列」或「订阅变更日志」的方式来做
先写数据库再删缓存一定万无一失吗 ？
不是万无一失，「理论」来说是可能发生不一致，但实际真的有可能发生吗？其实概率「很低」，这是因为它必须满足 3 个条件：
缓存刚好已失效
读请求 + 写请求并发
更新数据库 + 删除缓存的时间，要比读数据库 + 写缓存时间短
仔细想一下，条件 3 发生的概率其实是非常低的。
因为写数据库一般会先「加锁」，所以写数据库，通常是要比读数据库的时间更长的。
这么来看，「先更新数据库 + 再删除缓存」的方案，是可以保证数据一致性的。
“延时双删”的第二次删除缓存失败了呢，如何解决？
既然决定使用缓存，就必须容忍「一致性」问题，我们只能尽可能地去降低问题出现的概率。缓存都是有「失效时间」的，就算在这期间存在短期不一致，我们依旧有失效时间来兜底，这样也能达到最终一致。