1. 主动更新-4种核心缓存更新策略
核心原则：根据业务的 “读写比例”“一致性要求”“性能要求” 选择策略，优先保证数据一致性，其次优化性能。
1.1. Cache-Aside（旁路缓存）
这是最常用、最经典的策略，也叫 “先查缓存，再查数据库，更新时先更库再删缓存”。
- 读取数据：先查询缓存，命中则直接返回；未命中则查询数据库，将结果写入缓存并返回。更新数据：先更新数据库，再删除缓存（而非更新缓存）。
@Service public class UserServiceCacheAside { @Resource private UserMapper userMapper; @Resource private RedisTemplate<String, Object> redisTemplate; public User getUserById(Long userId) { String cacheKey = "user:" + userId; // 1. 查询缓存 User user = (User) redisTemplate.opsForValue().get(cacheKey); if (user != null) { return user; //缓存命中，直接返回 } // 2. 缓存未命中，查询数据库 user = userMapper.selectById(id); if (user != null) { // 3. 将数据库结果写入缓存（设置过期时间） redisTemplate.opsForValue().set(cacheKey, user, 30, TimeUnit.MINUTES); } return user; } public void updateUser(User user) { // 1. 先更新数据库 userMapper.updateById(user); // 2. 再删除缓存（而非更新缓存，避免并发问题） String cacheKey = "user:" + user.getId(); redisTemplate.delete(cacheKey); } } 优点逻辑简单，易于实现；适合读多写少的业务场景；避免 “更新缓存” 带来的并发数据不一致问题（比如两个线程同时更新，缓存可能存旧值）。缺点缓存未命中时会有 “缓存穿透” 的风险（可通过布隆过滤器解决）；数据库更新后、缓存删除前，若有读请求，可能读到旧值（概率极低，可接受）。
1.2. Write-Through（写穿透）
更新时 “先更缓存，再更数据库”，读取时只查缓存（缓存一定有最新数据）。
- 读取数据：直接从缓存读取，缓存必然命中（因为更新时同步写缓存）；更新数据：先更新缓存；再由缓存同步更新数据库（通常是缓存框架自动完成）。
@Service public class UserWriteThroughService { @Autowired private RedisTemplate<String, Object> redisTemplate; @Autowired private UserMapper userMapper; /** * 新增用户（Write Through：先写缓存，再写数据库） * 加事务保证缓存和数据库要么都成功，要么都失败 */ @Transactional(rollbackFor = Exception.class) public void addUser(User user) { // 1. 先写缓存（设置过期时间，兜底） String cacheKey = "user:write_through:" + user.getId(); redisTemplate.opsForValue().set(cacheKey, user, 1, TimeUnit.HOURS); // 2. 同步写数据库（若数据库写入失败，事务回滚，缓存也会被删除） int insertCount = userMapper.insertUser(user); if (insertCount <= 0) { // 数据库写入失败，主动删除缓存，避免脏数据 redisTemplate.delete(cacheKey); throw new RuntimeException("新增用户到数据库失败"); } } /** * 更新用户（Write Through：先更新缓存，再更新数据库） */ @Transactional(rollbackFor = Exception.class) public void updateUser(User user) { String cacheKey = "user:write_through:" + user.getId(); // 1. 先更新缓存（若缓存不存在，先查数据库再更新，保证缓存有数据） User oldUser = (User) redisTemplate.opsForValue().get(cacheKey); if (oldUser == null) { oldUser = userMapper.selectUserById(user.getId()); if (oldUser == null) { throw new RuntimeException("用户不存在，ID: " + user.getId()); } } redisTemplate.opsForValue().set(cacheKey, user, 1, TimeUnit.HOURS); // 2. 同步更新数据库 int updateCount = userMapper.updateUser(user); if (updateCount <= 0) { // 数据库更新失败，回滚缓存（恢复旧值） redisTemplate.opsForValue().set(cacheKey, oldUser, 1, TimeUnit.HOURS); throw new RuntimeException("更新用户到数据库失败，ID: " + user.getId()); } } /** * 读取用户（Write Through：只查缓存，不查数据库） */ public User getUserById(Long userId) { String cacheKey = "user:write_through:" + userId; User user = (User) redisTemplate.opsForValue().get(cacheKey); if (user == null) { // 理论上 Write Through 策略下缓存一定有数据，此处仅做异常兜底 user = userMapper.selectUserById(userId); if (user != null) { redisTemplate.opsForValue().set(cacheKey, user, 1, TimeUnit.HOURS); } } return user; } } 优点读取性能极高，无需访问数据库；数据一致性强，缓存与数据库同步更新。缺点写入性能低（每次写都要操作缓存 + 数据库）；数据库写入失败会导致缓存与数据库不一致（需加事务 / 重试）。
1.3. Write-Behind（写回）
也叫 “延迟更新”，更新时只更缓存，不立即更数据库，而是等缓存过期 / 淘汰时，再批量同步到数据库。
- 更新流程：更新缓存，并标记缓存为 “脏数据”；缓存过期 / 被淘汰时，异步将 “脏数据” 批量写入数据库。读取流程：与 Cache Aside 一致（先查缓存，未命中查库）。
/** * 业务场景：用户点赞数（写多读少，允许短时间缓存与数据库不一致） */ @Service public class LikeCountWriteBackService { // Redis Key前缀：用户点赞数缓存 private static final String CACHE_LIKE_COUNT_KEY = "like:count:"; // Redis Key：脏数据标记（记录需要同步到数据库的用户ID） private static final String DIRTY_DATA_SET_KEY = "like:dirty:user:ids"; // 缓存过期时间（兜底，避免脏数据永久不刷新） private static final long CACHE_EXPIRE_TIME = 24 * 60 * 60; @Resource private RedisTemplate<String, Object> redisTemplate; @Resource private LikeCountMapper likeCountMapper; /** * 核心操作：更新用户点赞数（只更缓存，标记脏数据） * @param userId 用户ID * @param increment 增加的点赞数（正数） */ public void updateLikeCount(Long userId, int increment) { String cacheKey = CACHE_LIKE_COUNT_KEY + userId; try { // 1. 原子更新Redis缓存中的点赞数（避免并发问题） redisTemplate.opsForValue().increment(cacheKey, increment); // 设置缓存过期时间（兜底） redisTemplate.expire(cacheKey, CACHE_EXPIRE_TIME, TimeUnit.SECONDS); // 2. 将用户ID加入脏数据集（标记为需要同步到数据库） // 使用ZSet存储，score为当前时间戳，便于后续按时间筛选 redisTemplate.opsForZSet().add(DIRTY_DATA_SET_KEY, userId, System.currentTimeMillis()); } catch (Exception e) { // 异常时降级：直接更新数据库（避免数据丢失） fallbackUpdateDb(userId, increment); } } /** * 读取用户点赞数（先查缓存，未命中查库并回填缓存） * @param userId 用户ID * @return 最新点赞数 */ public Long getLikeCount(Long userId) { String cacheKey = CACHE_LIKE_COUNT_KEY + userId; // 1. 先查缓存 Object cacheValue = redisTemplate.opsForValue().get(cacheKey); if (cacheValue != null) { return Long.parseLong(cacheValue.toString()); } // 2. 缓存未命中：查数据库 Long dbCount = likeCountMapper.selectLikeCountByUserId(userId); if (dbCount == null) { dbCount = 0L; } // 3. 回填缓存（并标记为脏数据，避免后续同步时覆盖） redisTemplate.opsForValue().set(cacheKey, dbCount); redisTemplate.expire(cacheKey, CACHE_EXPIRE_TIME, TimeUnit.SECONDS); redisTemplate.opsForZSet().add(DIRTY_DATA_SET_KEY, userId, System.currentTimeMillis()); return dbCount; } /** * 核心异步任务：定时将脏数据同步到数据库（Write Back核心） * 定时规则：每5分钟执行一次（可根据业务调整） */ @Scheduled(cron = "0 */5 * * * ?") @Transactional(rollbackFor = Exception.class) public void syncDirtyDataToDb() { ZSetOperations<String, Object> zSetOps = redisTemplate.opsForZSet(); // 1. 批量获取脏数据集中的用户ID（最多取1000条，避免单次同步过多） Set<Object> dirtyUserIds = zSetOps.range(DIRTY_DATA_SET_KEY, 0, 999); if (dirtyUserIds == null || dirtyUserIds.isEmpty()) { return; } // 2. 遍历脏数据，同步到数据库 List<Long> failUserIds = new ArrayList<>(); // 记录同步失败的用户ID for (Object userIdObj : dirtyUserIds) { Long userId = Long.parseLong(userIdObj.toString()); String cacheKey = CACHE_LIKE_COUNT_KEY + userId; try { // 2.1 获取缓存中的最新点赞数 Object cacheCountObj = redisTemplate.opsForValue().get(cacheKey); if (cacheCountObj == null) { zSetOps.remove(DIRTY_DATA_SET_KEY, userId); // 移除脏数据标记 continue; } Long cacheCount = Long.parseLong(cacheCountObj.toString()); // 2.2 更新数据库 likeCountMapper.updateLikeCountByUserId(userId, cacheCount); // 2.3 同步成功：移除脏数据标记 zSetOps.remove(DIRTY_DATA_SET_KEY, userId); } catch (Exception e) { failUserIds.add(userId); // 记录失败ID，后续重试 } } // 3. 处理同步失败的用户ID（简单重试：重新加入脏数据集） if (!failUserIds.isEmpty()) { for (Long failUserId : failUserIds) { zSetOps.add(DIRTY_DATA_SET_KEY, failUserId, System.currentTimeMillis()); } } } /** * 降级策略：缓存更新失败时，直接更新数据库 */ private void fallbackUpdateDb(Long userId, int increment) { try { Long currentCount = likeCountMapper.selectLikeCountByUserId(userId); if (currentCount == null) { currentCount = 0L; } likeCountMapper.updateLikeCountByUserId(userId, currentCount + increment); } catch (Exception e) { // 可进一步接入消息队列/告警，保证数据不丢失 } } } 优点：写入性能极高（只需操作缓存，数据库异步批量更新）；适合写多读少的场景（如计数器、点赞数）。缺点数据一致性差（缓存未同步到数据库时，服务宕机会丢失数据）；实现复杂（需处理脏数据标记、异步同步、数据恢复）。
1.4. 刷新过期（Refresh-Ahead）
本质是 Cache-Aside（旁路缓存）的优化 / 增强版
- 更新流程：与 Cache Aside 一致（先更新数据库，再删除缓存）。读取流程：先查询缓存，未命中则查询数据库，将结果写入缓存并返回；命中则检查缓存剩余过期时间，若剩余过期时间 ≥ 阈值：直接返回缓存中的旧值；若剩余过期时间 < 阈值：异步触发缓存刷新（后台查数据库最新数据 → 重写缓存并重置 TTL），当前请求仍返回缓存旧值。
/** * Refresh-Ahead（提前刷新）策略实现示例 * 核心逻辑：访问缓存时检查剩余过期时间，若小于阈值则异步刷新缓存，当前请求仍返回旧值 */ @Service public class RefreshAheadCacheService { // 缓存过期时间（示例：30分钟） private static final long CACHE_TTL_SECONDS = 30 * 60; // Refresh-Ahead 触发阈值（过期时间剩余10%时触发，示例：3分钟） private static final long REFRESH_THRESHOLD_SECONDS = CACHE_TTL_SECONDS / 10; @Resource private RedisTemplate<String, Object> redisTemplate; @Resource private ProductCategoryMapper productCategoryMapper; /** * 获取商品分类数据（核心Refresh-Ahead逻辑） */ public ProductCategory getCategoryWithRefreshAhead(Long categoryId) { String cacheKey = "category:" + categoryId; ValueOperations<String, Object> valueOps = redisTemplate.opsForValue(); // 1. 先查缓存 ProductCategory category = (ProductCategory) valueOps.get(cacheKey); if (category == null) { // 缓存未命中：查库 + 写入缓存（常规Cache Aside逻辑） category = productCategoryMapper.selectById(categoryId); if (category != null) { redisTemplate.opsForValue().set(cacheKey, category, CACHE_TTL_SECONDS, TimeUnit.SECONDS); } return category; } // 2. 缓存命中：检查剩余过期时间，判断是否触发Refresh-Ahead Long remainExpireSeconds = redisTemplate.getExpire(cacheKey, TimeUnit.SECONDS); // 剩余时间小于阈值 且 缓存未过期（避免已过期的情况） if (remainExpireSeconds != null && remainExpireSeconds > 0 && remainExpireSeconds < REFRESH_THRESHOLD_SECONDS) { // 3. 异步刷新缓存（不阻塞当前请求） asyncRefreshCategoryCache(categoryId, cacheKey); } // 当前请求仍返回旧值，异步刷新不影响响应速度 return category; } /** * 异步刷新缓存（核心：不阻塞主线程） */ @Async("refreshExecutor") // 指定自定义异步线程池（避免用默认线程池） public void asyncRefreshCategoryCache(Long categoryId, String cacheKey) { try { // 1. 从数据库查询最新数据 ProductCategory latestCategory = productCategoryMapper.selectById(categoryId); if (latestCategory != null) { // 2. 重新设置缓存（覆盖旧值 + 重置过期时间） redisTemplate.opsForValue().set(cacheKey, latestCategory, CACHE_TTL_SECONDS, TimeUnit.SECONDS); } } catch (Exception e) { System.err.println("Refresh-Ahead刷新缓存失败：Key=" + cacheKey + "，原因：" + e.getMessage()); } } }
线程池配置
@Configuration @EnableAsync // 开启异步功能 public class ThreadPoolConfig { @Bean public ThreadPoolTaskExecutor refreshExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(5); executor.setMaxPoolSize(20); executor.setQueueCapacity(100); executor.setThreadNamePrefix("cache-refresh-"); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } } 优点保证数据一致性；避免 “缓存穿透” 的风险。仅在 “缓存快过期且被访问” 时刷新，比定时刷新更精准，避免无意义的全量刷新，节省资源；缺点需额外开发 “过期时间预判”“异步刷新”“线程池管理” 逻辑，增加开发和维护成本；触发刷新后、异步更新完成前，客户端仍会读取到旧值（窗口极短，通常可接受）；异步线程池耗尽、数据库查询失败等，可能导致刷新失败，需增加重试 / 日志监控机制；刷新阈值（如总 TTL 的 10%）设置不合理时：过大→频繁刷新浪费资源，过小→刷新完成前缓存已过期。
2. 3种补充策略
2.1. Read-Through（读穿透）
Read-Through是Cache Aside的 “封装版 / 框架版”，核心是封装缓存读取逻辑，让业务层聚焦业务而非缓存操作。
只需要将Cache Aside是缓存的逻辑封装，所有业务复用即可。
优点 ：封装性好，应用代码无需关心缓存逻辑集中处理缓存加载，减少冗余代码适合只读或读多写少的数据缺点：缓存未命中时引发数据库请求，可能导致数据库负载增加无法直接处理写操作，需要与其他策略结合使用需要额外维护一个缓存管理层适用场景读操作频繁的业务系统需要集中管理缓存加载逻辑的应用复杂的缓存预热和加载场景2.2. 最终一致性（Eventual Consistency）
最终一致性策略基于分布式事件系统实现数据同步：
- 数据变更时发布事件到消息队列缓存服务订阅相关事件并更新缓存即使某些操作暂时失败，最终系统也会达到一致状态 首先定义数据变更事件：
@Data @AllArgsConstructor public class DataChangeEvent { private String entityType; private String entityId; private String operation; // CREATE, UPDATE, DELETE private String payload; // JSON格式的实体数据 }
实现事件发布者：
@Component public class DataChangePublisher { @Autowired private KafkaTemplate<String, DataChangeEvent> kafkaTemplate; private static final String TOPIC = "data-changes"; public void publishChange(String entityType, String entityId, String operation, Object entity) { try { // 将实体序列化为JSON String payload = new ObjectMapper().writeValueAsString(entity); // 创建事件 DataChangeEvent event = new DataChangeEvent(entityType, entityId, operation, payload); // 发布到Kafka kafkaTemplate.send(TOPIC, entityId, event); } catch (Exception e) { log.error("Failed to publish data change event", e); throw new RuntimeException("Failed to publish event", e); } } }
实现事件消费者更新缓存：
@Component @Slf4j public class CacheUpdateConsumer { @Autowired private RedisTemplate<String, Object> redisTemplate; private static final long CACHE_EXPIRATION = 30; @KafkaListener(topics = "data-changes") public void handleDataChangeEvent(DataChangeEvent event) { try { String cacheKey = buildCacheKey(event.getEntityType(), event.getEntityId()); switch (event.getOperation()) { case "CREATE": case "UPDATE": // 解析JSON数据 Object entity = parseEntity(event.getPayload(), event.getEntityType()); // 更新缓存 redisTemplate.opsForValue().set( cacheKey, entity, CACHE_EXPIRATION, TimeUnit.MINUTES); log.info("Updated cache for {}: {}", cacheKey, event.getOperation()); break; case "DELETE": // 删除缓存 redisTemplate.delete(cacheKey); log.info("Deleted cache for {}", cacheKey); break; default: log.warn("Unknown operation: {}", event.getOperation()); } } catch (Exception e) { log.error("Error handling data change event: {}", e.getMessage(), e); // 失败处理：可以将失败事件放入死信队列等 } } private String buildCacheKey(String entityType, String entityId) { return entityType.toLowerCase() + ":" + entityId; } private Object parseEntity(String payload, String entityType) throws JsonProcessingException { // 根据实体类型选择反序列化目标类 Class<?> targetClass = getClassForEntityType(entityType); return new ObjectMapper().readValue(payload, targetClass); } private Class<?> getClassForEntityType(String entityType) { switch (entityType) { case "User": return User.class; case "Product": return Product.class; // 其他实体类型 default: throw new IllegalArgumentException("Unknown entity type: " + entityType); } } }
使用示例：
@Service @Transactional public class UserServiceEventDriven { @Autowired private UserRepository userRepository; @Autowired private DataChangePublisher publisher; public User createUser(User user) { // 1. 保存用户到数据库 User savedUser = userRepository.save(user); // 2. 发布创建事件 publisher.publishChange("User", savedUser.getId().toString(), "CREATE", savedUser); return savedUser; } public User updateUser(User user) { // 1. 更新用户到数据库 User updatedUser = userRepository.save(user); // 2. 发布更新事件 publisher.publishChange("User", updatedUser.getId().toString(), "UPDATE", updatedUser); return updatedUser; } public void deleteUser(Long userId) { // 1. 从数据库删除用户 userRepository.deleteById(userId); // 2. 发布删除事件 publisher.publishChange("User", userId.toString(), "DELETE", null); } } 优点 ：支持分布式系统中的数据一致性削峰填谷，减轻系统负载峰值服务解耦，提高系统弹性和可扩展性缺点：一致性延迟，只能保证最终一致性实现和维护更复杂，需要消息队列基础设施可能需要处理消息重复和乱序问题适用场景大型分布式系统可以接受短暂不一致的业务场景需要解耦数据源和缓存更新逻辑的系统
2.3. 过期淘汰（被动更新）
本质：依赖 Redis 自身的过期策略（如 TTL 过期、LRU 淘汰）被动更新缓存，配合核心策略使用（比如 Cache Aside 中给缓存设 TTL，到期自动淘汰旧数据）。特点：不主动更新，而是 “被动清理旧数据”，是所有策略的基础保障（避免缓存永久有效）。简单说：过期淘汰是 “策略目标”（让过期缓存被清理），惰性删除 + 定期删除是 “技术手段”。
2.3.1. 惰性删除（Lazy Delete）
逻辑：当用户访问某个 key 时，Redis 先检查该键是否过期，若过期则立即删除，不返回值；定位：过期淘汰的核心实现手段之一，被动触发，节省 CPU 资源（不用轮询所有 key）。2.3.2. 定期删除（Periodic Delete）
逻辑：Redis 会启动一个后台线程，每隔一段时间（默认 100ms） 随机抽取一部分过期 key 检查，删除其中已过期的；为了不阻塞主线程，每次检查的时间和数量都有限制。定位：补充惰性删除的不足（避免过期 key 长期不被访问，一直占用内存），主动但轻量化。2.3.3. 两者结合的原因
只靠惰性删除：过期 key 若长期不被访问，会一直占内存；只靠定期删除：轮询所有 key 会消耗大量 CPU，影响性能；结合使用：既保证了过期 key 最终会被清理（定期删除兜底），又避免了过度消耗 CPU（惰性删除减少检查），是 Redis 平衡性能和内存的最优方案。3. 内存淘汰
内存淘汰属于「兜底型缓存清理机制」，是指 Redis 达到最大内存（maxmemory）时，按照预设规则（如 LRU、LFU、随机等）自动淘汰部分缓存数据，本质是 “内存管理手段”，而非 “保证数据一致性的更新策略”。
maxmemory 上限时，主动淘汰部分键，释放内存以保证 Redis 能继续接收新写入；核心定位：目的是避免 Redis 内存溢出，而非保证缓存与数据库的一致性 —— 淘汰的可能是最新的、也可能是旧的缓存数据，完全不考虑业务逻辑；常见策略：volatile-lru：淘汰设置了过期时间的键中，最近最少使用的；allkeys-lru：淘汰所有键中最近最少使用的；volatile-ttl：淘汰设置了过期时间的键中，剩余过期时间最短的；noeviction（默认）：不淘汰任何键，内存满时拒绝新写入并返回错误；是否属于：❌ 严格来说，不算 “业务层面的缓存更新策略”，而是 Redis 底层的内存保护机制；但广义上可视为 “被动清理缓存的补充手段”。
简单记：主动更新是 “主动做事”，过期淘汰是 “被动兜底做事”，内存淘汰是 “实在没内存了才清理”，前两者属于缓存更新策略范畴，后者是底层机制。
到此这篇关于Redis缓存更新策略的文章就介绍到这了,
