如何保证mysql与redis双写一致性

MySQL 与 Redis 的双写一致性是缓存架构的核心难题。由于网络延迟、故障回滚、并发竞态等因素，两者只能追求最终一致性，无法保证强一致性（除非牺牲性能用分布式锁）。

什么是双写一致性

在分布式系统中，双写一致性主要指在一个数据同时存在于缓存（如Redis）和持久化存储（如数据库）的情况下，
任何一方的数据更新都必须确保另一方数据的同步更新，以保持双方数据的一致状态。
这一问题的核心在于如何在并发环境下正确处理缓存与数据库的读写交互，防止数据出现不一致的情况。

解决方式

1.旁路缓存 （Cache-Aside）（最常用）

读操作：先从缓存中查，若命中，则直接返回；若未命中，从数据库中查并放入缓存中。
写操作：先更新数据库，然后删除缓存。
优点：实现简单，适合大多是读多写少的场景。
缺点：存在短暂数据不一致的场景。如刚更新数据库还未删除缓存时读取数据就会读到旧数据。
优化：对热点数据使用读写锁或互斥锁。如redis的setnx。

2.延时双删

延时双删主要用于解决高并发场景下，由于网络延迟，并发控制等原因造成的数据不一致的情况。
第一次删除：更新数据库后删除缓存。
第二次删除：隔一段设定好的暂停时间后再次删除。
优点：解决脏数据概率。
缺点：需维护定时任务，增加系统复杂度。

3.删除缓存重试机制

执行更新数据库操作之后删除缓存，若删除失败，系统进入重试逻辑，按照预先设定的策略进行多次尝试，
直到删除成功或达到最大次数。
优点：确保删除缓存成功。
缺点：占用额外的系统资源和时间，重试次数过多可能阻塞其他操作。

4.消息队列异步同步

写操作成功后发送消息到MQ，消费MQ，更新或删除缓存。
通过MQ解耦数据库和缓存操作，保证最终一致性。
支持异步重试。如RabbitMQ的死信队列。
优点：高吞吐，解耦系统。
缺点：依赖MQ可靠性，需处理消息积压和重复消费。

5.分布式锁

写操作前获取分布式锁（如redis的RedLock）
更新数据库->删除缓存->释放锁
串行化写操作，避免并发冲突。
优点：保证强一致性。
缺点：性能差，锁粒度控制困难。

总结

没有绝对完美的方案，根据不同的场景选择不同的方案
强一致性：分布式锁
最终一致性：Cache Aside或消息队列
高并发：延时双删