如何对Spring Cache Redis对象进行版本化？解决部署缓存结构不匹配问题

除了缓存版本化，以下几种方案也能有效处理对象结构变更后的缓存兼容性问题：

1. 缓存批量迁移/转换 #

在新版本部署前或部署过程中，编写脚本批量处理Redis中的旧缓存数据：

• 用SCAN命令（避免KEYS阻塞Redis）遍历所有相关旧缓存键
• 取出旧结构数据，转换为新对象结构
• 将转换后的数据写入新缓存键（或覆盖原键，根据业务需求）
• 清理旧缓存键（或设置短过期时间）

适用场景：缓存数据量不大、结构转换逻辑简单的情况。
优缺点：一次性解决缓存不兼容问题，但需要提前规划迁移脚本，大缓存量下可能需要分批次执行避免影响Redis性能。

示例脚本伪代码：

import redis

r = redis.Redis(host='localhost', port=6379)
cursor = 0
while True:
    cursor, keys = r.scan(cursor, match='user:*', count=100)
    for key in keys:
        old_user = r.get(key)
        # 转换旧结构到新结构
        new_user = {
            'id': old_user['id'],
            'name': old_user['name'],
            'new_field': old_user.get('old_field', 'default_value')  # 字段映射或补默认值
        }
        r.set(key, new_user)
    if cursor == 0:
        break

2. 缓存降级与懒加载 #

新版本服务中加入缓存结构校验逻辑，当读取到不匹配的缓存数据时，直接回源数据库获取最新数据并更新缓存：

• 读取缓存后，校验数据结构是否符合当前版本（比如检查是否存在必填新字段、字段类型是否正确）
• 若结构不匹配，跳过旧缓存，直接从DB拉取最新数据
• 将新结构的数据写入缓存，覆盖旧数据

适用场景：缓存数据可快速从DB重建、允许短暂DB压力上升的场景。
优缺点：无需提前处理缓存，实现简单；但可能导致部署初期DB访问量增加，需配合限流、熔断等措施避免雪崩。

示例Java代码片段：

public User getUser(Long userId) {
    String cacheKey = "user:" + userId;
    User cachedUser = redisTemplate.opsForValue().get(cacheKey);
    
    // 校验缓存结构：比如检查新增的`email`字段是否存在
    if (cachedUser != null && cachedUser.getEmail() == null) {
        // 缓存结构不兼容，回源DB
        cachedUser = userRepository.findById(userId).orElseThrow();
        // 更新缓存为新结构
        redisTemplate.opsForValue().set(cacheKey, cachedUser, Duration.ofHours(1));
    }
    return cachedUser;
}

3. 双写兼容与逐步淘汰 #

在过渡阶段，新版本服务同时支持新旧两种缓存结构的读写：

• 读逻辑：优先读取新结构缓存；若不存在，读取旧结构缓存，转换为新结构后返回，并将新结构写入缓存
• 写逻辑：同时写入新旧两种结构的缓存
• 等待一段时间（确保旧缓存被新数据覆盖或自然过期）后，移除旧结构的读写逻辑

适用场景：需要平滑过渡、不能接受服务中断或DB压力突增的核心业务。
优缺点：完全兼容新旧版本，无服务风险；但会暂时增加代码复杂度和Redis写入量。

4. 缓存键前缀区分 #

为不同结构版本的缓存设置独立的键前缀，比如旧版本用v1:user:123，新版本用v2:user:123：

• 新版本服务仅读写带有新前缀的缓存键
• 旧缓存键可设置过期时间自动失效，或在部署后批量删除
• 若需要兼容旧版本流量，可让服务根据版本号选择对应前缀的缓存

适用场景：对象结构变更极大、无法通过转换兼容的情况。
优缺点：隔离彻底，避免结构冲突；但需要修改缓存键生成逻辑，且旧缓存会占用Redis空间直到过期。

5. 预部署缓存失效 #

在新版本上线前，主动批量删除所有相关的旧缓存键：

• 用SCAN命令匹配目标缓存键，执行DEL操作
• 若缓存数据量大，可分批次删除，避免阻塞Redis
• 上线后，所有请求都会回源DB并重建新结构的缓存

适用场景：缓存数据重建成本低、允许短暂缓存击穿的场景。
优缺点：操作简单直接；但删除缓存后会导致大量请求直接访问DB，需确保DB能承受突发流量，可配合热点数据预热优化。

内容的提问来源于stack exchange，提问作者Bill Pfeiffer