3. 版本控制基础：为什么需要版本控制、版本号策略、乐观锁与悲观锁在缓存中的体现

3.1 为什么需要版本控制

在分布式缓存与微服务架构中，缓存数据与业务实体之间天然存在“契约耦合”。当服务 A 写入缓存的数据结构被服务 B 消费时，双方必须对数据格式、字段含义、序列化方式达成一致。一旦契约发生变更（如新增字段、修改类型、删除属性），缺乏版本控制将导致以下问题：

• 反序列化失败：旧版本代码尝试读取新格式数据，抛出异常。
• 数据静默损坏：字段错位或类型转换错误，业务逻辑产生错误结果。
• 灰度发布困难：无法同时支持多个版本的消费者，阻碍渐进式升级。
• 回滚风险：回滚代码后，缓存中残留的新版本数据无法被旧版本正确解析。

3.2 版本号策略

版本号策略定义了如何标识和演进缓存数据的结构。常见的策略包括：

版本号在缓存 Key 中的常见嵌入方式：

// 方式一：版本号作为 Key 后缀
user:profile:123:v2

// 方式二：版本号作为 Value 元数据字段
{
  "_version": "2.1.0",
  "name": "张三",
  "email": "zhangsan@example.com"
}

// 方式三：版本号存储在 Redis Hash 的单独 field
HSET user:123 profile "{...}" _version "2.1.0"

3.3 乐观锁与悲观锁在缓存中的体现

版本控制不仅用于数据格式兼容，还用于并发控制。在缓存系统中，乐观锁和悲观锁是两种典型的并发策略，它们与版本号机制紧密相关。

3.3.1 乐观锁（Optimistic Locking）

乐观锁假设并发冲突较少，在更新数据时检查版本号是否被修改。Redis 通过 WATCH 命令或 Lua 脚本实现乐观锁。

• 工作原理：读取数据时获取版本号，更新时比较版本号是否一致，一致则更新并递增版本号，不一致则重试。
• 优点：读操作无锁，性能高；适合读多写少的场景。
• 缺点：写冲突时需要重试，高并发写场景下可能导致大量重试。

-- Lua 脚本实现乐观锁更新
local key = KEYS[1]
local expected_version = ARGV[1]
local new_data = ARGV[2]
local new_version = tonumber(expected_version) + 1

local current_version = redis.call('HGET', key, '_version')
if not current_version or current_version == expected_version then
    redis.call('HSET', key, 'data', new_data, '_version', new_version)
    return 1  -- 更新成功
else
    return 0  -- 版本冲突，更新失败
end

3.3.2 悲观锁（Pessimistic Locking）

悲观锁假设并发冲突频繁，在操作数据前先获取锁，确保独占访问。Redis 通常使用 SETNX 或 Redlock 算法实现分布式锁。

• 工作原理：写入或读取前先尝试获取锁，获取成功后才能操作，操作完成后释放锁。
• 优点：强一致性，适合写多读少或写冲突严重的场景。
• 缺点：锁竞争降低吞吐量，锁超时或死锁风险增加系统复杂度。

// 使用 SETNX 实现简单悲观锁
String lockKey = "lock:user:123";
String requestId = UUID.randomUUID().toString();
Boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, requestId, 10, TimeUnit.SECONDS);

if (locked) {
    try {
        // 执行缓存读写操作
        // 操作完成后释放锁
        if (requestId.equals(redisTemplate.opsForValue().get(lockKey))) {
            redisTemplate.delete(lockKey);
        }
    } catch (Exception e) {
        // 处理异常，确保锁释放
    }
}

3.3.3 对比分析

3.4 版本控制与领域边界的关系

在领域驱动设计中，缓存契约版本号应映射到聚合根（Aggregate Root）的版本。每个聚合根的变化都会触发版本号递增，缓存中的版本号与数据库中的聚合根版本号保持一致。这种设计确保了：

• 边界清晰：版本号的变化范围被限制在聚合边界内，不会跨聚合传播。
• 一致性：缓存版本与数据库版本同步，避免脏数据。
• 可追溯：通过版本号可以回溯领域事件的变更历史。

3.5 版本控制实施清单

1. 选择版本号策略：根据领域复杂度选择实体级语义化版本或全局递增版本。
2. 嵌入版本号：在缓存 Value 的元数据中显式存储版本号，或在 Key 中编码。
3. 实现乐观锁更新：使用 Lua 脚本保证版本检查与更新的原子性。
4. 处理版本冲突：定义冲突时的重试策略（指数退避）或降级方案（读取数据库）。
5. 版本兼容性测试：在 CI/CD 中增加缓存契约的向前/向后兼容性测试。
6. 监控版本分布：监控缓存中不同版本数据的比例，辅助灰度发布决策。