3. 缓存一致性问题的根源：并发写、网络延迟、宕机、主从同步延迟导致的数据不一致分析

缓存一致性是分布式系统中最棘手的挑战之一。当数据在缓存（如 Redis）与数据库（如 MySQL）之间出现差异时，就会产生不一致。本章将深入剖析导致这一问题的四大核心根源，并通过图示和案例帮助您建立系统性的认知。

3.1 问题根源全景图

缓存与数据库之间的数据不一致，本质上是写操作顺序与数据可见性被破坏的结果。下图展示了四种典型场景如何导致数据从“一致”走向“不一致”。

3.2 根源一：并发写 —— 写顺序交错

当多个线程或进程同时对同一份数据进行“更新缓存 + 更新数据库”操作时，由于操作顺序无法保证，就会产生不一致。

3.2.1 典型场景：先写库后写缓存

假设线程A和线程B同时更新商品库存：

1. 线程A：将数据库库存更新为 50，然后写入缓存 50。
2. 线程B：将数据库库存更新为 30，然后写入缓存 30。

如果线程A的“写缓存”操作因某种原因（如网络抖动）晚于线程B的“写缓存”操作，最终缓存中残留的是 50（旧值），而数据库中是 30（新值），导致不一致。

3.3 根源二：网络延迟 —— 请求乱序到达

分布式系统中，网络延迟是常态。延迟会导致请求的到达顺序与发送顺序不一致，从而破坏缓存与数据库的同步逻辑。

3.4 根源三：宕机 —— 数据丢失与回滚

宕机是分布式系统中最严重的故障之一。当缓存或数据库在写操作过程中宕机，会导致数据永久不一致。

3.4.1 缓存宕机

• 场景： 应用先更新数据库，然后准备更新缓存时，缓存服务宕机。
• 后果： 缓存中数据丢失，下次读取时需回查数据库。如果数据库也在此期间被修改，则可能读到旧数据。

3.4.2 数据库宕机

• 场景： 应用先删除缓存，然后准备更新数据库时，数据库宕机。
• 后果： 缓存被删除，数据库未更新。后续请求无法从缓存获取数据，全部穿透到数据库，可能导致数据库压力激增甚至雪崩。

3.4.3 主从切换时的宕机

在 Redis 或 MySQL 主从架构中，如果主节点宕机，从节点晋升为主节点。但此时从节点可能尚未完全同步主节点的最新数据，导致缓存与新的主节点数据不一致。

3.5 根源四：主从同步延迟 —— 读到过期数据

在读写分离架构中，主库负责写，从库负责读。缓存通常与主库同步，但主从同步存在延迟，导致缓存中的数据可能比从库中的数据“新”，或者反过来。

3.6 四种根源的对比与总结