4. 版本号设计策略：语义化版本、时间戳版本、哈希版本、混合版本方案

在缓存契约校验体系中，版本号是契约的“身份证”。选择何种版本号策略，直接决定了缓存失效的粒度、冲突检测的灵敏度以及运维的可追溯性。本节深入剖析四种主流版本号设计方案，帮助你在不同业务场景下做出最优选择。

4.1 版本号设计核心考量

一个优秀的版本号策略需要平衡以下三个维度：

• 唯一性：版本号必须能唯一标识一次数据变更，避免哈希冲突或时间回拨导致误判。
• 有序性：版本号应能反映变更的先后顺序，便于缓存淘汰策略（如 LRU、LFU）和增量同步。
• 可读性：运维人员能通过版本号快速定位问题，例如回滚到某个特定版本。

4.2 语义化版本（Semantic Versioning）

语义化版本采用 主版本号.次版本号.修订号 的格式，例如 2.1.3。在缓存契约中，通常将契约的变更映射到版本号的三个段位上：

• 主版本号：契约结构发生不兼容变更（如删除字段、修改字段类型）。
• 次版本号：契约新增向后兼容的功能（如增加可选字段）。
• 修订号：契约内部实现优化或 Bug 修复，对外接口不变。

# 设置契约版本号
SET user:profile:contract:v2.1.3 '{"name":"string","age":"int","email":"string"}'

# 校验时比较版本号
local current_version = "2.1.3"
local cached_version = redis.call("GET", "user:profile:contract:version")
if cached_version ~= current_version then
    -- 版本不匹配，触发缓存重建
end

优点：语义清晰，开发者能直观理解变更影响范围；适合人工审核和发布流程。

缺点：依赖人工维护版本号递增，在频繁迭代或自动化部署场景下容易遗漏更新；无法自动感知数据内容的变化。

4.3 时间戳版本（Timestamp Versioning）

时间戳版本使用 Unix 毫秒时间戳或高精度时钟作为版本号，例如 1712567890123。在 Redis 中，常配合 EXPIRE 或 TTL 实现基于时间的缓存失效。

-- 获取 Redis 服务器时间
local time = redis.call("TIME")
local timestamp = tonumber(time[1]) * 1000 + math.floor(tonumber(time[2]) / 1000)

-- 写入带时间戳的缓存
redis.call("SET", "order:12345:data", "cached_data")
redis.call("SET", "order:12345:version", timestamp)

优点：自动生成，无需人工干预；天然有序，适合增量同步和滑动窗口淘汰。

缺点：依赖系统时钟，时钟回拨（如 NTP 同步、服务器休眠唤醒）会导致版本号冲突或数据覆盖；高并发下同一毫秒内可能产生重复版本号。

4.4 哈希版本（Hash Versioning）

哈希版本通过对数据内容计算摘要（如 MD5、SHA-256）作为版本号。只要数据内容不变，哈希值就保持不变；内容一旦变更，哈希值随即改变。

-- 计算数据哈希
local data = '{"name":"Alice","age":30}'
local hash = redis.sha256hex(data)  -- 假设 Redis 支持 sha256hex 命令

-- 写入缓存和版本
redis.call("SET", "user:1001:data", data)
redis.call("SET", "user:1001:version", hash)

优点：内容驱动的版本号，自动检测数据变更；适合不可变数据、内容寻址缓存（如 CDN、静态资源）。

缺点：哈希值无序，无法用于范围查询或增量同步；计算哈希消耗 CPU 资源，高频场景需评估性能影响。

4.5 混合版本方案（Hybrid Versioning）

混合版本方案结合多种策略的优点，通常采用 前缀 + 后缀 的结构：

• 前缀：使用时间戳或递增序列号，保证有序性和全局唯一性。
• 后缀：使用哈希值或随机数，防止同一时间戳内的冲突。

常见的混合格式包括：

-- 获取全局递增序列号
local seq = redis.call("INCR", "global:version:seq")
-- 计算数据哈希
local hash = redis.sha256hex(data)
-- 组合版本号
local version = string.format("%010d:%s", seq, string.sub(hash, 1, 8))

-- 写入缓存
redis.call("SET", "product:888:data", data)
redis.call("SET", "product:888:version", version)

优点：兼具有序性、唯一性和内容感知能力；适合分布式系统、微服务架构下的全局缓存契约管理。

缺点：版本号长度较长，占用更多存储空间；实现复杂度较高，需要维护序列号或时间同步机制。

4.6 版本号策略选择决策树

以下 SVG 图展示了在不同业务约束下如何选择版本号策略：

4.7 版本号在 Redis 中的存储与校验模式

无论选择哪种版本号策略，在 Redis 中通常采用 Key-Value 分离存储 或 Hash 结构统一存储 两种模式：