ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花

缓存是提升系统读写性能、降低数据库压力的核心手段，根据部署范围、数据共享性分为本地缓存和分布式缓存两大类。两者定位不同、特性迥异，更新策略也需适配自身架构特点，避免数据不一致、缓存雪崩等问题。

一、本地缓存 vs 分布式缓存：核心区别

本地缓存属于单机/进程内缓存，数据仅存在单个服务实例；分布式缓存属于集群共享缓存，数据跨节点统一存储，两者核心差异对比如下：

二、本地缓存：更新策略与实现方式

本地缓存无跨节点同步能力，更新核心目标是保证单机数据新鲜度，同时避免频繁更新影响性能，主流方案分为被动过期和主动更新两大类：

1. 被动过期更新（懒更新，最常用）

给缓存数据设置过期时间，缓存到期后自动失效，下次查询时重新从数据库加载最新数据并回填缓存。

• 实现逻辑：查询缓存→命中则直接返回→未命中/过期→查询DB→回填缓存并重置过期时间
• 优点：实现简单、无额外开销、适配绝大多数静态/低频变更数据
• 缺点：存在数据短暂不一致，过期窗口内读取旧数据
• 适用场景：配置项、字典表、低频更新的业务数据

2. 主动淘汰更新（触发式更新）

数据发生变更（增删改）时，立即删除/更新本地缓存，强制下次查询加载最新数据，避免过期窗口的脏数据。

• 实现逻辑：业务数据更新DB→同步删除本地缓存key→下次查询重新加载
• 优点：数据实时性高，无过期延迟
• 缺点：多实例部署时，仅当前节点缓存更新，其他节点仍存旧数据（本地缓存通病）

3. 定时批量更新

通过定时任务（如Quartz、Spring Schedule）周期性全量/增量刷新本地缓存，适合数据批量变更、无需实时一致的场景。

• 优化方案：增量同步仅更新变更数据，减少全量刷新的性能开销

4. 消息通知同步（多实例折中方案）

借助MQ（如RocketMQ、Kafka）发布数据变更消息，所有服务实例订阅消息，收到后主动淘汰本地缓存，解决多实例不一致问题。

• 缺点：引入MQ增加架构复杂度，存在消息延迟风险

三、分布式缓存：更新策略与一致性保障

分布式缓存是全局共享数据源，更新核心目标是缓存与数据库数据一致，同时避免缓存击穿、并发更新冲突，主流更新方案按一致性优先级排序：

1. 先更DB，再删缓存（失效更新，工业级首选）

这是最稳妥的更新方案，核心是删除缓存而非更新缓存，避免并发读写导致的数据错乱。

• 实现逻辑：开启事务更新数据库→事务提交成功后，异步/同步删除分布式缓存对应key→下次查询自动加载最新数据
• 优点：实现简单、极少出现脏数据、规避并发更新冲突
• 避坑点：必须先更新DB再删缓存，严禁颠倒顺序；删除失败可通过重试、消息队列补偿

2. 先更DB，再更缓存（双写更新）

数据变更后，同步更新数据库和分布式缓存，适合读多写少、对实时性要求极高的场景。

• 风险点：高并发下易出现并发写冲突（如线程A先更新DB、线程B后更新DB并先更新缓存，线程A最终更新缓存导致脏数据）
• 优化方案：加分布式锁、使用版本号/时间戳控制更新顺序，仅最新版本数据可覆盖缓存

3. 缓存预热+定时刷新

针对海量静态热数据，服务启动时提前加载缓存，后续通过定时任务增量刷新，降低运行时查询压力。

• 适用场景：商品详情、首页配置、榜单数据等

4. 读写分离+主从同步（高可用更新）

基于分布式缓存集群（Redis主从、哨兵模式），写操作操作主节点，读操作操作从节点，主节点数据自动同步到从节点，保证集群数据一致。

5. 分布式锁+强一致更新

对库存、订单等强一致数据，更新前加分布式锁，防止并发修改导致缓存与DB不一致，解锁后再淘汰/更新缓存。

四、核心总结与选型建议

选型口诀：单机隔离、极致性能选本地缓存；全局共享、高可用、多实例部署选分布式缓存。

• 本地缓存更新：优先懒过期+主动淘汰，多实例场景用MQ消息同步淘汰，追求极简架构可容忍短暂不一致
• 分布式缓存更新：优先先更DB、再删缓存，高并发场景加版本号/分布式锁，核心数据做重试补偿
• 混合架构：常用本地缓存+分布式缓存二级缓存，分布式缓存保证一致性，本地缓存提升热点数据读写性能

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花