| ||||||||||||||||||||||||||||||||||||
在电商系统中，分布式缓存（如 Redis 集群）和本地缓存（如 Caffeine、Guava）的组合使用能显著提升性能，但两者的数据一致性是核心挑战。由于本地缓存存在于应用进程内、分布式缓存独立部署且多节点共享，数据更新时易出现不一致（如本地缓存未及时更新，导致读旧数据）。以下是保证一致性的常见策略及实现细节： 一、核心原则：明确一致性优先级 电商场景中，数据一致性需结合业务场景权衡： 强一致性：适用于库存、订单状态等核心数据（不一致可能导致超卖、支付异常）。 最终一致性：适用于商品详情、分类列表等非实时数据（短时间不一致可接受）。 多数情况下，会采用 “最终一致性 + 关键场景强一致” 的混合策略，避免过度设计导致性能损耗。
二、保证数据一致性的具体策略 1. 写操作时的同步更新策略（核心手段） 数据变更（如商品价格修改、库存扣减）时，需通过 “写透” 或 “先删后更” 确保缓存与数据源同步，避免缓存脏数据。 策略 1：Cache Aside Pattern（旁路缓存模式） 最常用的经典模式，流程为： 先更新数据库（如 MySQL）； 再删除缓存（而非更新缓存）。 理由：直接更新缓存可能因并发写导致覆盖（如 A、B 同时更新，A 的缓存更新被 B 覆盖），而删除缓存可强制后续读请求从数据库加载最新数据并回填缓存，保证最终一致。 注意： 需先更数据库再删缓存（若顺序颠倒，可能出现 “删缓存后、更数据库前” 的读请求加载旧数据到缓存）。 针对分布式缓存，需确保删除操作是 “原子性” 的（如 Redis 的 DEL 命令）；本地缓存则直接调用 remove 方法。 策略 2：Write Through（写透模式） 流程为： 先更新缓存； 缓存同步更新数据库（或由缓存组件异步同步）。 适用场景：本地缓存（如 Caffeine）与数据库的同步，因本地缓存单进程可见，无分布式并发问题。 缺点：增加写操作耗时（需等数据库确认），不适合高并发写场景（如秒杀库存扣减）。 策略 3：Write Back（写回模式） 流程为： 先更新缓存，标记为 “脏数据”； 缓存组件定期异步将脏数据批量更新到数据库。 适用场景：非核心数据（如用户浏览历史），追求写性能，可接受短时间数据不一致。 风险：若应用崩溃，缓存中未同步的脏数据会丢失，电商核心场景慎用。
2. 针对本地缓存的特殊处理 本地缓存因存在于应用实例内存中（如每个 Tomcat 节点有独立本地缓存），分布式环境下易出现 “各节点本地缓存不一致” 问题，需额外处理： 策略 1：本地缓存设置短过期时间 为本地缓存设置比分布式缓存更短的 TTL（如分布式缓存 10 分钟，本地缓存 1 分钟），通过自动失效强制刷新，避免长期脏数据。 适用场景：非核心数据（如商品详情），结合分布式缓存兜底，平衡性能与一致性。 策略 2：分布式通知 invalidation（失效通知） 当数据更新时，通过消息队列（如 RabbitMQ、Kafka）或分布式事件（如 Redis Pub/Sub）通知所有应用实例删除本地缓存： 节点 A 更新数据并删除自身本地缓存 + 分布式缓存； 节点 A 向消息队列发送 “数据 X 已更新” 的通知； 其他节点（B、C、D）收到通知后，删除自身本地缓存中数据 X。 实现细节： 通知需保证 “至少一次送达”（如消息队列持久化），避免漏删； 本地缓存删除需加锁（如 ReentrantLock），防止并发读导致删除后立即加载旧数据。 策略 3：禁用本地缓存的 “写透”，仅做 “读缓存” 本地缓存仅用于读取，不主动更新： 读请求先查本地缓存，未命中则查分布式缓存，再未命中则查数据库并回填两级缓存； 写请求仅更新数据库 + 删除分布式缓存，本地缓存依赖过期时间自动失效或被通知删除。 优点：避免本地缓存与分布式缓存的同步成本，适合本地缓存仅作为 “热点数据加速层” 的场景。 3. 解决并发读写冲突（关键补充） 高并发场景下（如秒杀），即使按上述流程操作，仍可能因时序问题导致不一致（如 “缓存删除后、数据库更新前” 的读请求加载旧数据）。需通过以下手段解决： 手段 1：加分布式锁 对写操作加分布式锁（如 Redis 的 SET NX），确保同一时间只有一个线程更新数据，避免并发写导致的缓存混乱。 示例：库存扣减时，用商品 ID 作为锁键，获取锁后再执行 “更新数据库 + 删缓存”，释放锁后其他请求才能操作。 手段 2：延迟双删（解决缓存删除后的数据回写） 针对 “先删缓存、再更数据库” 期间可能的读请求脏数据，流程优化为： 第一次删除缓存； 更新数据库； 延迟 N 毫秒（如 500ms）后，第二次删除缓存。 理由：延迟时间覆盖 “读请求加载旧数据到缓存” 的耗时，第二次删除可清除可能的脏数据。 手段 3：版本号控制（防缓存覆盖） 缓存中存储数据时附带版本号（如{data:..., version: 3}），写操作时： 数据库更新时版本号 + 1； 删缓存时，若本地缓存有旧版本，直接删除；若分布式缓存有旧版本，通过 CAS（Compare And Swap）机制确保只有旧版本被删除。 4. 读操作时的兜底策略（减少不一致影响） 即使写操作处理完善，仍可能因网络延迟、节点故障导致缓存不一致，需在读取时做兜底： 策略 1：缓存过期时间兜底 为所有缓存（本地 + 分布式）设置合理的过期时间（如 10 分钟），即使出现脏数据，也会在过期后自动失效，由读请求从数据库加载最新数据。 注意：本地缓存过期时间需短于分布式缓存（如本地 1 分钟，分布式 10 分钟），避免本地缓存长期持有旧数据。 策略 2：关键数据双读校验 对核心数据（如订单金额、库存数量），读取时同时检查本地缓存、分布式缓存和数据库，若存在不一致，以数据库为准，并触发缓存更新。
三、分布式与本地缓存的协同注意事项 本地缓存的 “范围控制” 本地缓存仅存储高频访问、低变更的数据（如首页 Banner、热门商品列表），避免存储高频变更数据（如库存），减少一致性维护成本。 缓存穿透与击穿的防护 一致性策略需与防穿透（如布隆过滤器）、防击穿（如互斥锁）结合，例如： 防止 “缓存被删除后，大量请求直击数据库” 导致的性能崩溃； 避免恶意请求（如查询不存在的商品 ID）穿透缓存攻击数据库。 监控与告警 部署缓存一致性监控： 对比缓存与数据库的关键数据（如定期抽样校验库存数量）； 监控缓存删除成功率、本地缓存与分布式缓存的版本差异； 出现不一致时告警，人工介入修复（如手动清理脏缓存）。 四、总结 电商系统中保证分布式缓存与本地缓存的一致性，核心是 “写操作时优先保证数据源与缓存同步，读操作时通过过期和校验兜底，结合业务场景平衡一致性与性能”。具体实践中，建议： 非核心场景：采用 “Cache Aside + 过期时间 + 本地缓存短 TTL”； 核心场景（如库存）：采用 “Cache Aside + 分布式锁 + 延迟双删 + 双读校验”。 通过分层设计和场景化策略，既能满足业务对一致性的要求，又能保持系统的高可用性和性能。 | ||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||
|
