1. 课程导论：什么是缓存契约、为什么需要版本控制、Redis在契约校验中的角色
1.1 什么是缓存契约
缓存契约（Cache Contract）是服务调用方与缓存层之间达成的一组结构化约定，它明确定义了缓存数据的结构、语义、有效期、序列化方式以及失效策略。在微服务架构中，缓存不再是简单的 key-value 存储，而是承担着状态同步、降级容灾和性能加速的核心角色。没有契约的缓存，就像没有接口文档的 API——调用方不知道数据长什么样、什么时候过期、该用什么版本解析。
核心要素：缓存契约通常包含数据模型（字段名、类型、嵌套结构）、TTL 策略、序列化协议（JSON/Protobuf/MessagePack）、版本标识（version field）以及降级兜底行为。
1.2 为什么需要版本控制
缓存数据在分布式系统中会经历多次迭代：字段新增、类型变更、枚举值调整、甚至整个结构重构。如果缓存层与服务端代码的版本脱节，就会发生反序列化异常、字段丢失、业务逻辑错乱等严重故障。版本控制为缓存数据提供了“向前兼容”和“灰度迁移”的能力。
| 场景 | 无版本控制 | 有版本控制 |
|---|---|---|
| 字段新增 | 旧缓存反序列化失败，引发 500 错误 | 根据版本号跳过新字段，使用默认值 |
| 字段类型变更 | 类型转换异常，缓存雪崩 | 版本路由到对应解析器，平滑迁移 |
| TTL 策略调整 | 缓存与业务逻辑不一致，数据脏读 | 版本标记过期策略，渐进式刷新 |
| 多服务共享缓存 | 不同服务版本冲突，数据覆盖 | 版本隔离，各服务只读写兼容版本 |
常见陷阱：很多团队只在应用层做版本兼容，却忽略了缓存中残留的旧版本数据。当新版本上线后，旧缓存仍在被读取，导致“一半新一半旧”的混乱状态。缓存契约版本控制正是为了解决这个“缓存数据版本漂移”问题。
1.3 Redis 在契约校验中的角色
Redis 作为高性能内存数据库，在缓存契约校验体系中承担着数据载体、版本存储、校验执行三重角色。它不仅仅是缓存数据的容器，更是契约版本信息的“注册中心”和“校验引擎”。
- 数据载体：Redis 的 String、Hash、JSON 模块直接存储带版本号的缓存数据。
- 版本存储：利用 Redis 的 key 命名空间或 Hash field 存储版本标识，支持按版本查询和过滤。
- 校验执行：通过 Lua 脚本或 Redis 模块在读取时自动校验版本号，不匹配则触发降级或刷新。
- 灰度发布：结合 Redis 的 TTL 和发布订阅，实现版本数据的渐进式替换。
1.4 契约版本的生命周期
一个完整的缓存契约版本从定义到废弃，通常经历以下阶段：
- 定义阶段：由服务提供方定义契约结构、版本号、兼容规则。
- 发布阶段：将契约注册到版本中心，同时写入 Redis 的版本元数据。
- 校验阶段：每次缓存读取时，校验版本号是否匹配，不匹配则触发降级或刷新。
- 迁移阶段：新版本上线后，旧版本数据逐步过期或被主动刷新。
- 废弃阶段：旧版本数据全部淘汰，版本号从注册中心移除。
1.5 课程核心收益
通过本课程的学习，你将掌握以下能力：
- 设计可版本化的缓存数据结构，避免字段变更引发的线上故障。
- 在 Redis 中实现契约校验逻辑，包括 Lua 脚本校验、JSON Schema 校验。
- 构建版本注册中心，管理多版本缓存数据的共存与迁移。
- 制定降级策略，在版本不匹配时优雅降级而非直接报错。
- 通过灰度发布机制，平滑升级缓存契约版本。
课程定位：本课程面向有 Redis 使用经验、正在或即将面临缓存数据版本管理挑战的架构师和高级开发工程师。我们将从理论到实战，逐步构建一套完整的缓存契约版本校验体系。