详细介绍：分布式缓存的正确姿势：Cache-Aside、更新策略与分布式锁在 Java 微服务中的实战

news/2025/10/3 10:02:18/文章来源:https://www.cnblogs.com/yxysuanfa/p/19124357

分布式缓存的正确姿势：Cache-Aside、更新策略与分布式锁在 Java 微服务中的实战

实际场景引入

想象你正在开发一个大型电商平台的商品详情微服务。前端频繁访问同一张商品详情页，数据库压力骤增，搜索/浏览的峰值时常导致热点数据数据库命中率下降，用户体验下降。为了提升响应速度与稳定性，我们需要把热点数据放到分布式缓存中。但缓存并不能简单地等同于数据库，缓存失效、数据不一致、击穿/雪崩等问题都可能让系统变得乱套。本文以城市交通信号网的比喻，逐步揭开分布式缓存背后的设计要点，帮助你在实际系统中落地。

比喻解释：把缓存比作“路网中的路牌”——它能迅速提供路况信息，但若路牌信息过时（缓存失效），你仍需要回到路口的信号灯系统（数据库）来核对最新信息。正确的缓存设计，是在路牌信息过时时，能够智能、快速地回源并更新路牌，确保后续路况信息的正确性与时效性。

核心知识点1：Cache-Aside 模式的实现与落地

在分布式场景中，最常用的缓存模式是 Cache-Aside（ Cache-Aside/Cache-Aside 机制）。读请求先尝试命中缓存；如果缓存未命中（Miss），再回源数据库获取数据，同时将数据写回缓存。这样可以最大限度地降低数据库压力，同时避免缓存写入时序问题。

场景示例：商品详情

热点商品查询，通过缓存快速返回。
数据更新时，主动清理缓存，确保后续查询更新为最新数据。

代码示例 1：基于 RedisTemplate 的 Cache-Aside 实现

@Service
public class ProductService {private static final String CACHE_KEY = "product:";@Autowiredprivate RedisTemplate redis;@Autowiredprivate ProductRepository repo;public Product getProduct(Long id) {String key = CACHE_KEY + id;// 1) 先从缓存命中Product cached = (Product) redis.opsForValue().get(key);if (cached != null) {return cached;}// 2) 缓存未命中，回源数据库Product fromDb = repo.findById(id).orElse(null);if (fromDb != null) {// 3) 将新数据写回缓存，设定合理 TTLredis.opsForValue().set(key, fromDb, 10, TimeUnit.MINUTES);}return fromDb;}public void updateProduct(Product p) {// 更新数据库repo.save(p);// 删除缓存，确保下次读取回源获取最新数据redis.delete(CACHE_KEY + p.getId());}
}

该实现的核心点：先读缓存、再回源、最后回写缓存；更新数据时清理缓存，避免缓存与数据库之间的数据不一致。若你需要强一致性，可以在更新后再回写缓存，但要承担写放大和双写一致性的问题，这里主要介绍清晰简单的缓存一致性路径。

#### 代码分析
- 优点：实现简单、对大多数写多读少场景友好；降低数据库压力。
- 缺点：在高并发的尖峰时段，仍可能出现缓存穿透或缓存击穿，需要结合分布式锁或其他策略做优化。

核心知识点2：更新策略、失效与幂等性

当商品数据发生变更时，如何有效地让缓存尽快过期或回写，避免老数据继续流传？常见做法有两类：

缓存失效+主动刷新：触发数据库更新后，显式删除缓存条目，后续请求触发回源并重新缓存；
异步刷新：在发布变更后，后台任务异步刷新缓存，缩短前端用户看到的过期时间。

代码示例 2：被动清理 + 异步刷新

@Service
public class ProductService {// 省略注入字段// 直接清理缓存，使用异步任务进行回填public void updateProduct(Product p) {repo.save(p);redis.delete(CACHE_KEY + p.getId());// 异步回填（示意），实际可使用消息队列或任务调度器AsyncExecutor.submit(() -> {Product refreshed = repo.findById(p.getId()).orElse(null);if (refreshed != null) {redis.opsForValue().set(CACHE_KEY + p.getId(), refreshed, 10, TimeUnit.MINUTES);}});}
}

要点是尽量让热数据的缓存命中在数据变更后保持快速且可控，同时对更新路径强调幂等性：多次更新不会导致数据错乱或重复计算。实际生产中常结合消息队列来实现幂等性与可追踪性。

核心知识点3：分布式锁与防止缓存击穿/雪崩

当缓存失效时，单机锁并不足以保护并发请求回源造成数据库压力剧增的情况。这时需要引入分布式锁，确保同一时间只有一个请求去回源更新缓存，其他请求等待锁释放后再读取缓存，从而避免击穿与雪崩。

代码示例 3：Redisson 分布式锁

@Service
public class ProductServiceWithLock {@Autowired private RedisTemplate redis;@Autowired private RedissonClient redisson;@Autowired private ProductRepository repo;public Product getProduct(Long id) {String key = "product:" + id;Product cached = (Product) redis.opsForValue().get(key);if (cached != null) return cached;RLock lock = redisson.getLock("lock:product:" + id);try {lock.lock();// 双重检查cached = (Product) redis.opsForValue().get(key);if (cached != null) return cached;Product fromDb = repo.findById(id).orElse(null);if (fromDb != null) {redis.opsForValue().set(key, fromDb, 10, TimeUnit.MINUTES);}return fromDb;} finally {lock.unlock();}}public void updateProduct(Product p) {repo.save(p);redis.delete("product:" + p.getId());}
}

要点如下：