缓存一致性问题的根源：读写并发、数据过期、分布式环境下的数据冲突
缓存一致性是分布式系统中最棘手的问题之一。要设计出可靠的缓存策略，首先必须深刻理解问题的三个核心根源：读写并发、数据过期和分布式环境下的数据冲突。这三者往往交织在一起，导致缓存与数据库之间的数据不一致。
根源一：读写并发 —— 时序交错引发的数据错乱
当多个线程或进程同时对同一份数据进行读写操作时，由于操作时序的不确定性，缓存与数据库之间会产生数据不一致。这是最基础也是最常见的根源。
典型的并发写场景如下：
- 线程A 更新数据库中的值（v1 → v2）。
- 线程A 删除缓存（或更新缓存）。
- 线程B 在步骤2完成之前，读取缓存（读到旧值v1）。
- 线程B 将旧值v1写入缓存（覆盖了线程A的更新）。
最终缓存中存留的是旧值v1，而数据库中是v2，产生不一致。
关键洞察： 读写并发的本质是“读操作”与“写操作”在时间窗口内的交错执行。只要读操作在写操作完成“缓存失效”之前读取并回填了旧数据，不一致就会发生。
根源二：数据过期 —— 缓存与数据库的生命周期差异
缓存中的数据通常设置了TTL（生存时间），而数据库中的数据是持久化的。当缓存数据过期后，新的读请求会穿透到数据库，此时如果数据库中的数据已经被其他事务修改，就会产生不一致。
数据过期导致不一致的典型场景：
| 时间点 | 操作 | 数据库状态 | 缓存状态 |
|---|---|---|---|
| T1 | 写入数据 | v1 | v1（TTL=60s） |
| T2 | 更新数据 | v2 | v1（未失效） |
| T3 | 缓存TTL到期 | v2 | 空 |
| T4 | 读请求穿透到DB | v2 | v2（重新加载） |
在T2到T3之间，缓存中始终是旧值v1，而数据库中是v2。这段时间窗口内，所有读请求都会读到过期数据。
常见误区： 很多人认为设置较短的TTL可以解决一致性问题。实际上，TTL只能保证最终一致性，无法保证强一致性。在TTL窗口内，不一致依然存在。TTL越短，数据库压力越大，需要在一致性与性能之间做权衡。
根源三：分布式环境下的数据冲突 —— 多副本、多节点、网络分区
在分布式系统中，缓存和数据库往往分布在不同的节点上，甚至缓存本身也可能是分布式缓存（如Redis Cluster）。这引入了额外的复杂性：
- 网络延迟与分区： 写操作可能先到达缓存节点，后到达数据库节点，或者反之。网络抖动可能导致操作顺序错乱。
- 节点故障： 缓存节点宕机后，数据丢失；恢复后从数据库重新加载，可能加载到的是旧数据。
- 时钟偏差： 不同服务器之间的系统时钟不一致，导致基于时间的失效策略失效。
- 副本延迟： 数据库主从架构下，写主库后读从库，从库可能尚未同步最新数据。
三种根源的对比与总结
| 根源 | 核心原因 | 典型场景 | 影响范围 | 解决难度 |
|---|---|---|---|---|
| 读写并发 | 多线程/多进程操作时序交错 | 先删缓存后更新DB，读请求回填旧数据 | 单机/集群 | 中等（需加锁或延迟双删） |
| 数据过期 | TTL窗口内数据未同步 | 缓存TTL未到，数据库已更新 | 所有使用TTL的场景 | 较低（缩短TTL或主动失效） |
| 分布式冲突 | 网络分区、节点故障、时钟偏差 | 主从延迟导致读从库读到旧数据 | 分布式系统 | 高（需分布式事务或最终一致性方案） |
实践建议： 在Spring Boot项目中，首先要识别你的业务场景属于哪种根源主导。对于高并发读写场景（如商品库存），优先解决读写并发问题；对于数据时效性要求不高的场景（如用户资料），数据过期可能是可接受的；对于跨数据中心的分布式系统，必须考虑网络分区和节点故障的影响。