SpringBoot 缓存一致性：缓存与数据库双写策略-洪萨配资

在SpringBoot企业开发中，为了提升系统性能，我们都会给高频查询接口加上缓存（比如Redis、Caffeine），把热点数据缓存起来，减少数据库查询压力，让接口响应速度从几十毫秒提升到几毫秒。

但缓存的引入，也带来了一个核心难题——缓存一致性：当数据库中的数据发生修改（新增、更新、删除）时，缓存中的数据如果没有及时同步，就会出现“缓存数据与数据库数据不一致”的问题，导致用户查询到旧数据、错误数据，引发业务异常。

举个真实场景：用户修改了自己的昵称，数据库中的昵称已经更新，但缓存中还是旧昵称，用户再次查询个人信息时，看到的还是旧昵称，体验极差；更严重的是，订单状态更新后缓存未同步，可能导致运营人员误判订单状态，造成损失。

很多同学一开始处理缓存，只懂“查询时查缓存，没有就查数据库再存缓存”（即Cache-Aside策略），但忽略了数据修改时的缓存同步，导致缓存一致性问题频发。

一、缓存一致性的核心问题

想要解决缓存一致性问题，首先要明白：问题的根源不是“缓存”或“数据库”本身，而是数据修改时，缓存与数据库的操作顺序、同步时机，以及“并发场景下的竞态条件”。

1. 双写顺序与并发竞态

当数据发生修改时，我们需要同时操作“数据库”和“缓存”，但这两个操作无法做到“原子性”（要么同时成功，要么同时失败），因此会出现两种核心问题：

•双写顺序错误：比如先更新缓存、再更新数据库，若更新数据库失败，缓存中是新数据，数据库中是旧数据，导致不一致；
•并发竞态问题：比如一个更新操作（改数据库+删缓存）和一个查询操作（查缓存+查数据库）并发执行，查询操作可能在更新操作删除缓存后、更新数据库前，查询到旧数据并重新写入缓存，导致缓存一直是旧数据。

2. 缓存一致性的目标

我们追求的缓存一致性，不是“绝对一致性”（成本极高，没必要），而是最终一致性：在合理的时间范围内（比如1秒内），缓存数据能同步为数据库的最新数据，满足业务需求即可。

比如用户修改昵称后，100毫秒内缓存同步更新，用户再次查询就能看到新昵称，这种“最终一致性”完全能满足绝大多数业务场景，且实现成本低、性能影响小。

面试必背总结：缓存一致性的核心是“解决双写顺序和并发竞态问题”，企业级落地优先追求“最终一致性”，而非“绝对一致性”，平衡性能与数据准确性。

二、三大主流双写策略

目前业界解决缓存一致性的双写策略主要有3种，各有优缺点和适用场景，没有最优方案，只有最适合业务的方案，下面逐一拆解，包含实现代码、细节说明，直接复制就能用。

前置准备：SpringBoot 2.7.x + Redis + Spring Cache（简化缓存操作），核心依赖如下（已包含Spring Cache和Redis整合）：

<!-- SpringBoot Web --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency><!-- Spring Cache 核心依赖 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-cache</artifactId> </dependency> <!-- Redis 依赖（分布式缓存） --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <!-- Caffeine 依赖（单机缓存，可选） --> <dependency> <groupId>com.github.ben-manes.caffeine</groupId> <artifactId>caffeine</artifactId> <version>3.1.2</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency>

基础配置（application.yml）：

spring: # Redis 配置（分布式缓存） redis: host: localhost port: 6379 password: 123456 database: 0 lettuce: pool: maximum-pool-size: 10 minimum-idle: 2 # 缓存配置 cache: type: redis # 默认使用Redis缓存（单机可改为caffeine） redis: time-to-live: 3600000 # 缓存过期时间（1小时，根据业务调整） cache-null-values: false # 不缓存null值，避免缓存穿透 caffeine: time-to-live: 3600000 # 单机缓存过期时间 initial-capacity: 100 # 初始缓存容量 maximum-size: 1000 # 最大缓存数量（避免内存溢出） # 开启Spring Cache注解支持 spring.cache.type: redis

策略1：Cache-Aside（旁路缓存）

Cache-Aside 是最主流、最易落地的双写策略，核心逻辑：查询走缓存，更新走数据库+删除缓存，不直接更新缓存，避免双写顺序错误。

很多人也称其为“Cache-Aside Pattern”，是企业开发中最常用的缓存策略，兼顾性能和一致性，实现简单。

1. 核心流程

•查询操作：先查缓存 → 缓存有数据，直接返回；缓存无数据，查数据库 → 将数据库数据写入缓存 → 返回数据；
•更新操作：先更新数据库 → 再删除缓存（而非更新缓存）；
•删除操作：先删除数据库 → 再删除缓存。

2. 为什么是“删除缓存”，而非“更新缓存”？

这是很多同学最常问的问题，核心原因有2点：

• 避免双写顺序错误：如果先更新缓存、再更新数据库，数据库更新失败，缓存是新数据、数据库是旧数据，直接不一致；
• 减少冗余操作：如果多条更新操作连续执行，每次都更新缓存，会造成不必要的性能开销；而删除缓存，只需在最后一次更新后删除一次，后续查询再重新写入缓存，更高效。

3. 完整代码

使用Spring Cache的@Cacheable（查询缓存）、@CacheEvict（删除缓存）注解，无需手动操作Redis，简化开发。

import org.springframework.cache.annotation.CacheEvict; import org.springframework.cache.annotation.Cacheable; import org.springframework.stereotype.Service; import javax.annotation.Resource; import java.util.Optional; /** * 商品服务（Cache-Aside策略实现） */ @Service public class ProductService { @Resource private ProductMapper productMapper; /** * 查询商品：先查缓存，无则查数据库，再写入缓存 * value：缓存名称（自定义） * key：缓存key（用商品ID，确保唯一） */ @Cacheable(value = "product", key = "#id") public Product getProductById(Long id) { // 缓存没有时，查询数据库（实际项目可加日志） Optional<Product> product = productMapper.selectById(id); return product.orElse(null); } /** * 更新商品：先更新数据库，再删除缓存 * @CacheEvict：删除缓存，allEntries=false表示只删除当前key的缓存 */ @CacheEvict(value = "product", key = "#product.id") public void updateProduct(Product product) { // 1. 先更新数据库 productMapper.updateById(product); // 2. 注解自动删除缓存（无需手动操作Redis） } /** * 删除商品：先删除数据库，再删除缓存 */ @CacheEvict(value = "product", key = "#id") public void deleteProduct(Long id) { // 1. 先删除数据库 productMapper.deleteById(id); // 2. 注解自动删除缓存 } }

4. 优缺点与适用场景

优点：实现简单、无侵入（依赖Spring Cache注解）、性能好（查询走缓存，更新仅多一次删除缓存操作）、一致性有保障（最终一致性）；

缺点：存在轻微的并发竞态问题（下文会讲解决方案）；

适用场景：绝大多数业务场景，尤其是查询频率高、更新频率中等的场景（比如商品详情、用户信息、订单列表），是企业级落地的首选。

策略2：Write-Through

Write-Through 策略的核心逻辑：更新操作时，先更新数据库，再同步更新缓存；查询操作和Cache-Aside一致（先查缓存，无则查数据库）。

这种策略的特点是“写入即同步”，缓存和数据库的数据几乎是一致的（接近绝对一致性），但性能稍弱（多一次缓存更新操作）。

1. 核心流程

•查询操作：和Cache-Aside一致（先缓存 → 再数据库 → 写缓存）；
•更新操作：先更新数据库 → 再更新缓存（覆盖旧缓存）；
•删除操作：先删除数据库 → 再删除缓存（和Cache-Aside一致）。

2. 完整代码

Write-Through 不适合用Spring Cache注解（注解无法实现“更新数据库后同步更新缓存”的逻辑），需手动操作RedisTemplate。

import org.springframework.data.redis.core.RedisTemplate; import org.springframework.stereotype.Service; import javax.annotation.Resource; import java.util.Optional; import java.util.concurrent.TimeUnit; @Service public class ProductService { @Resource private ProductMapper productMapper; @Resource private RedisTemplate<String, Object> redisTemplate; // 缓存key前缀（避免key冲突） private static final String CACHE_KEY_PREFIX = "product:"; /** * 查询商品（和Cache-Aside一致） */ public Product getProductById(Long id) { String cacheKey = CACHE_KEY_PREFIX + id; // 1. 先查缓存 Product product = (Product) redisTemplate.opsForValue().get(cacheKey); if (product != null) { return product; } // 2. 缓存无，查数据库 Optional<Product> dbProduct = productMapper.selectById(id); if (dbProduct.isPresent()) { // 3. 写入缓存（设置过期时间，避免缓存雪崩） redisTemplate.opsForValue().set(cacheKey, dbProduct.get(), 1, TimeUnit.HOURS); return dbProduct.get(); } return null; } /** * 更新商品：先更数据库，再更缓存（Write-Through策略核心） */ public void updateProduct(Product product) { // 1. 先更新数据库 productMapper.updateById(product); // 2. 同步更新缓存（覆盖旧数据） String cacheKey = CACHE_KEY_PREFIX + product.getId(); redisTemplate.opsForValue().set(cacheKey, product, 1, TimeUnit.HOURS); } /** * 删除商品：先删数据库，再删缓存 */ public void deleteProduct(Long id) { // 1. 先删除数据库 productMapper.deleteById(id); // 2. 再删除缓存 String cacheKey = CACHE_KEY_PREFIX + id; redisTemplate.delete(cacheKey); } }

3. 优缺点与适用场景

优点：缓存与数据库一致性强（接近绝对一致），查询时不会出现旧数据，适合对数据一致性要求高的场景；

缺点：性能稍弱（更新操作多一次缓存写入），存在双写顺序错误风险（若更新缓存失败，数据库是新数据、缓存是旧数据）；

适用场景：对数据一致性要求高、更新频率低的场景（比如金融数据、核心配置数据），不适合高频更新场景。

策略3：Write-Back（写回）

Write-Back 策略的核心逻辑：更新操作时，先更新缓存，不立即更新数据库，而是将缓存标记为“脏数据”，在一定时机（比如缓存过期、缓存满了、定时任务）再批量同步到数据库。

这种策略的特点是“写入性能极高”（只需更新缓存，无需立即操作数据库），但一致性最弱（缓存更新后，数据库可能还是旧数据），实现复杂，很少在业务系统中使用。

1. 核心流程

•查询操作：和前两种策略一致（先缓存 → 再数据库 → 写缓存）；
•更新操作：先更新缓存 → 标记缓存为“脏数据” → 异步/定时同步到数据库；
•删除操作：先删除缓存 → 标记为“脏数据” → 异步/定时删除数据库数据。

2. 简化实现代码

Write-Back 实现复杂，需结合定时任务、脏数据标记，以下是简化版核心逻辑（实际落地需完善异常处理、重试机制）：

import org.springframework.data.redis.core.RedisTemplate; import org.springframework.scheduling.annotation.Scheduled; import org.springframework.stereotype.Service; import javax.annotation.Resource; import java.util.HashMap; import java.util.Map; import java.util.Optional; import java.util.concurrent.TimeUnit; @Service public class ProductService { @Resource private ProductMapper productMapper; @Resource private RedisTemplate<String, Object> redisTemplate; private static final String CACHE_KEY_PREFIX = "product:"; // 存储脏数据（key：缓存key，value：商品对象） private final Map<String, Product> dirtyDataMap = new HashMap<>(); /** * 查询商品 */ public Product getProductById(Long id) { String cacheKey = CACHE_KEY_PREFIX + id; Product product = (Product) redisTemplate.opsForValue().get(cacheKey); if (product != null) { return product; } Optional<Product> dbProduct = productMapper.selectById(id); if (dbProduct.isPresent()) { redisTemplate.opsForValue().set(cacheKey, dbProduct.get(), 1, TimeUnit.HOURS); return dbProduct.get(); } return null; } /** * 更新商品：先更缓存，标记脏数据（Write-Back核心） */ public void updateProduct(Product product) { String cacheKey = CACHE_KEY_PREFIX + product.getId(); // 1. 更新缓存 redisTemplate.opsForValue().set(cacheKey, product, 1, TimeUnit.HOURS); // 2. 标记为脏数据 dirtyDataMap.put(cacheKey, product); } /** * 定时同步脏数据到数据库（每5分钟执行一次，可调整） */ @Scheduled(cron = "0 0/5 * * * ?") public void syncDirtyDataToDb() { if (dirtyDataMap.isEmpty()) { return; } // 批量同步脏数据到数据库 for (Product product : dirtyDataMap.values()) { productMapper.updateById(product); } // 清空脏数据 dirtyDataMap.clear(); } }

3. 优缺点与适用场景

优点：写入性能极高（无需立即操作数据库），适合高频写入、对一致性要求低的场景；

缺点：一致性最弱（缓存更新后，数据库可能延迟同步，若系统崩溃，脏数据会丢失），实现复杂（需处理脏数据、定时同步、异常重试）；

适用场景：高频写入、对数据一致性要求低的场景（比如日志缓存、浏览记录、临时统计数据），业务系统核心数据不推荐使用。

三、解决双写策略的并发竞态问题

前面提到，Cache-Aside 策略存在轻微的并发竞态问题，这是新手落地时最容易踩的坑，也是面试常问的点，下面拆解问题场景，并给出两种企业级解决方案。

1. 并发竞态问题场景

假设两个线程同时执行：线程A（更新操作）、线程B（查询操作），执行顺序如下：

1. 线程A：更新数据库（成功）；
2. 线程A：准备删除缓存（还未执行）；
3. 线程B：查询缓存（缓存中还有旧数据？不，此时缓存还未删除，线程B查到旧数据，准备返回）；
4. 线程A：删除缓存（成功）；
5. 线程B：将查到的旧数据，重新写入缓存；

最终结果：数据库是新数据，缓存是旧数据，出现一致性问题，且后续查询都会拿到旧数据（直到缓存过期）。

2. 解决方案1：延迟删除缓存

核心逻辑：更新数据库后，延迟一段时间（比如100毫秒）再删除缓存，确保线程B在查询时，能查到数据库的新数据，而不是旧数据后写入缓存。

实现方式：使用线程池异步延迟删除，不影响主线程性能。

import org.springframework.cache.annotation.Cacheable; import org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor; import org.springframework.stereotype.Service; import javax.annotation.Resource; import java.util.Optional; import java.util.concurrent.TimeUnit; @Service public class ProductService { @Resource private ProductMapper productMapper; @Resource private ThreadPoolTaskExecutor taskExecutor; /** * 查询商品（不变） */ @Cacheable(value = "product", key = "#id") public Product getProductById(Long id) { Optional<Product> product = productMapper.selectById(id); return product.orElse(null); } /** * 更新商品：延迟删除缓存，解决并发竞态 */ public void updateProduct(Product product) { // 1. 先更新数据库 productMapper.updateById(product); // 2. 异步延迟100毫秒删除缓存（延迟时间可调整） Long productId = product.getId(); taskExecutor.schedule(() -> { // 手动删除缓存（替代@CacheEvict注解） redisTemplate.delete("product:" + productId); }, 100, TimeUnit.MILLISECONDS); } }

✅ 关键说明：延迟时间建议设置为“业务接口的最大响应时间”（比如100-500毫秒），确保线程B的查询操作能在缓存删除前完成数据库查询，避免旧数据写入缓存。

3. 解决方案2：分布式锁

核心逻辑：在查询和更新操作中，给“缓存key”加分布式锁（比如Redis分布式锁），确保同一时间，只有一个线程能执行“查询+写缓存”或“更新+删缓存”操作，彻底解决竞态问题。

实现方式：使用Redisson分布式锁（简化锁的操作，避免死锁），适合分布式系统场景。

import org.redisson.api.RLock; import org.redisson.api.RedissonClient; import org.springframework.data.redis.core.RedisTemplate; import org.springframework.stereotype.Service; import javax.annotation.Resource; import java.util.Optional; import java.util.concurrent.TimeUnit; @Service public class ProductService { @Resource private ProductMapper productMapper; @Resource private RedisTemplate<String, Object> redisTemplate; @Resource private RedissonClient redissonClient; private static final String CACHE_KEY_PREFIX = "product:"; private static final String LOCK_KEY_PREFIX = "product:lock:"; /** * 查询商品：加分布式锁，避免竞态 */ public Product getProductById(Long id) { String cacheKey = CACHE_KEY_PREFIX + id; String lockKey = LOCK_KEY_PREFIX + id; RLock lock = redissonClient.getLock(lockKey); try { // 加锁（10秒自动释放，避免死锁） lock.lock(10, TimeUnit.SECONDS); // 1. 先查缓存 Product product = (Product) redisTemplate.opsForValue().get(cacheKey); if (product != null) { return product; } // 2. 查数据库，写缓存 Optional<Product> dbProduct = productMapper.selectById(id); if (dbProduct.isPresent()) { redisTemplate.opsForValue().set(cacheKey, dbProduct.get(), 1, TimeUnit.HOURS); return dbProduct.get(); } return null; } finally { // 释放锁 if (lock.isHeldByCurrentThread()) { lock.unlock(); } } } /** * 更新商品：加分布式锁，避免竞态 */ public void updateProduct(Product product) { String cacheKey = CACHE_KEY_PREFIX + product.getId(); String lockKey = LOCK_KEY_PREFIX + product.getId(); RLock lock = redissonClient.getLock(lockKey); try { lock.lock(10, TimeUnit.SECONDS); // 1. 更新数据库 productMapper.updateById(product); // 2. 删除缓存 redisTemplate.delete(cacheKey); } finally { if (lock.isHeldByCurrentThread()) { lock.unlock(); } } } }

✅ 关键说明：分布式锁会增加一定的性能开销，适合对一致性要求高的分布式系统；如果是单机系统，可用本地锁（synchronized）替代，更高效。