再看先说大前提，

面试官问“Redis 作为缓存。MySQL 的数据怎么和 Redis 同步”，本质就是在考双写一致性。不过，

但这道题最忌讳的一点。就是上来直接背标准答案，

答题第一步先，必须先交代业务背景。

你的业务到底是要强一致，还是能容忍延迟一致？这两个前提对应的解法完全是两码事。下面我按“强一致”和“延迟一致”两条线，把方案拆开讲清楚。

一、先搞懂什么是双写一致性

至于一句话定义。数据库里的数据改了缓存里的数据也得跟着改，两边不能对不上。

读数据的标准链路是这样的：

• 先查 Redis，命中就直接返回；
• 没命中才去查数据库。顺手把查到的数据写回 Redis，再返回结果。

这就是正常的读流程。

写数据场景里常见方案之一：延时双删

• 步停一小会，第四步再删一次缓存。

痛点一这方面，为什么要这么绕？话说回来，

• 更新时到底先删缓存还是先改库？
• 为什么要删两次而不是一次？

二、先删缓存，还是先改库？

顺序 A：先删缓存，再改数据库。

• 线程① 先把缓存删了还没来得及改库；线程② 这时来读，发现缓存空了跑去数据库读出旧值 写回缓存；等线程③ 把库更新成新值后局面就变成

顺序 B：先改数据库，再删缓存。

• 线程① 查询缓存未命中，从数据库读取旧值准备写入缓存；此时线程② 更新数据库为新值，并删除缓存；随后线程③ 将之前读取的旧值写入缓存，最终导致

无论哪种顺序。都有可能产生脏数据——这是并发导致的隐患。

三、延时双删：为什么要删两次、为什么要等？ 其实，

痛点二：

• No guarantee of strong consistency: 主从同步不确定时间。会导致脏数据仍然出现，
• Cumbersome and error‑prone: 需要精确控制延迟时间。否则既不能保证一致，也无法提高性能。

四、想强一致，就布式互斥锁

痛点三：

• Lack of concurrency control: 没有锁容易出现脏读/覆盖问题。怎么说呢，
The cost of locking: 过度加锁会导致性能瓶颈。Synchronous blocking: 锁竞争可能导致请求排队等待。Cascade deadlock risk: 多服务共享同一个键会引发死锁。Error handling complexity: 失去锁后如何恢复或重试。如有大量并发请求，需要细粒度锁策略以避免热点瓶颈。

' ' ' 能 可用多个同时读取，但禁止任何写操作！ '> 不能 只允许一个线程访问，不管是读还是写都被阻塞！'>

实现思路的观点是。

• 获取同一个分布式键上的- 在业务层做加解锁封装：

说到P.S.，如果你需要更轻量级的乐观并发控制，而非纯粹的互斥模式，这样既可以降低性能成本，又能保持一定程度的一致性。

异步通知 * MQ 异步通知 – 改完 MySQL 后投递消息给队列 → 缓存服务监听 → 消息到达即更新/失效 Cache。* Canal binlog 监听 – Canal 模拟从节点捕获 binlog → 下游服务得到变化事件 → 更新 Cache。再看优点，零侵入、可靠性取决于 MQ 或 Canal 本身；缺点：存在不可避免的短暂不一致。

回到面试现场怎么答

1️⃣ 列举自己实际使用过的场景。2️⃣ 针对每个场景说明“一致性要求”。其实，- 对实时性要求低 → 异步方案。- 对实时性要求高 → 锁机制或强一致方案。不过，3️⃣ 面试官若追问细节，可展开对应技术实现。