1. 主动更新-4种核心缓存更新策略
核心原则：根据业务的 "读写比例""一致性要求""性能要求" 选择策略，优先保证数据一致性，其次优化性能。
1.1. Cache-Aside（旁路缓存）
这是最常用、最经典的策略，也叫 "先查缓存，再查数据库，更新时先更库再删缓存"。
- 读取数据：先查询缓存，命中则直接返回；未命中则查询数据库，将结果写入缓存并返回。
- 更新数据：先更新数据库，再删除缓存（而非更新缓存）。
java
@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（写穿透）
更新时 "先更缓存，再更数据库"，读取时只查缓存（缓存一定有最新数据）。
- 读取数据：直接从缓存读取，缓存必然命中（因为更新时同步写缓存）；
- 更新数据：先更新缓存；再由缓存同步更新数据库（通常是缓存框架自动完成）。
java
@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 一致（先查缓存，未命中查库）。
java
/**
* 业务场景：用户点赞数（写多读少，允许短时间缓存与数据库不一致）
*/
@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），当前请求仍返回缓存旧值。
java
/**
* 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());
}
}
}线程池配置
java
@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）
最终一致性策略基于分布式事件系统实现数据同步：
- 数据变更时发布事件到消息队列
- 缓存服务订阅相关事件并更新缓存
- 即使某些操作暂时失败，最终系统也会达到一致状态 首先定义数据变更事件：
java
@Data
@AllArgsConstructor
public class DataChangeEvent {
private String entityType;
private String entityId;
private String operation; // CREATE, UPDATE, DELETE
private String payload; // JSON格式的实体数据
}实现事件发布者：
java
@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);
}
}
}实现事件消费者更新缓存：
java
@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);
}
}
}使用示例：
java
@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、随机等）自动淘汰部分缓存数据，本质是 "内存管理手段"，而非 "保证数据一致性的更新策略"。
- 典型行为：Redis 内存占满后，淘汰最少使用的 key（LRU 策略）；
- 核心目标 ：当 Redis 内存达到
maxmemory上限时，主动淘汰部分键，释放内存以保证 Redis 能继续接收新写入； - 核心定位 ：目的是避免 Redis 内存溢出，而非保证缓存与数据库的一致性 ------ 淘汰的可能是最新的、也可能是旧的缓存数据，完全不考虑业务逻辑；
- 常见策略 ：
volatile-lru：淘汰设置了过期时间的键中，最近最少使用的；allkeys-lru：淘汰所有键中最近最少使用的；volatile-ttl：淘汰设置了过期时间的键中，剩余过期时间最短的；noeviction（默认）：不淘汰任何键，内存满时拒绝新写入并返回错误；
- 是否属于：❌ 严格来说，不算 "业务层面的缓存更新策略"，而是 Redis 底层的内存保护机制；但广义上可视为 "被动清理缓存的补充手段"。
简单记：主动更新是 "主动做事"，过期淘汰是 "被动兜底做事"，内存淘汰是 "实在没内存了才清理"，前两者属于缓存更新策略范畴，后者是底层机制。