JSON 向后兼容、RPC 调用与 Redis 缓存失效全解析

排序接口需要新增两个通用属性，用来标识数据项的状态与业务配置类型：

关键点在于：这两个字段并不存储在本服务对应的本地数据库，而是由上游的基础数据微服务统一维护。因此本次改动不是"查一张本地表"那么简单，而是需要跨服务获取数据——这就引出了必须理解的两条底层链路：JSON 序列化与 RPC 调用。

服务端把响应对象返回给客户端（Web、iOS、Android 或小程序）时，通常会将 Java 对象转换为通用的文本格式，这个过程叫 JSON 序列化（常见工具如 Jackson、Fastjson 等）。

• •什么是 JSON？ 它是一种轻量级的文本数据交换格式，独立于具体的编程语言。
• •什么是向后兼容（Backward Compatibility）？ 假设客户端原本只解析 id 与 name，现在响应里多出了 configType，客户端反序列化时默认会忽略未定义的未知字段，原有业务逻辑完全不受影响。

// 变更前
{ "id": 1, "name": "示例项" }

// 变更后：增量扩展，旧客户端会自动忽略未知字段
{ "id": 1, "name": "示例项", "statusCode": "ACTIVE", "configType": "TYPE_A" }

新字段由上游服务维护，需要通过 RPC（远程过程调用） 框架（如 Dubbo、gRPC 等）进行跨服务获取。你在本地代码里写下一行调用，体验上就像执行一个本地函数：

// 调用体验极简，但底层远不止这一行
List<BaseItem> list = iBaseDataMicroService.queryAllList();

RPC 框架在底层帮你完成了完整的一串动作：

1. 1参数序列化：把入参编码成可传输的字节流。
2. 2网络传输：通过 TCP / HTTP2 发送到目标服务。
3. 3目标服务解包并执行：反序列化入参，执行真正的业务逻辑。
4. 4结果序列化返回：把返回值编码后回传。
5. 5本地反序列化：调用方拿到结果对象，像本地方法一样使用。

这是本次接口修改中最核心、最严谨的技术细节。为了提升接口响应速度，业务代码里通常设计了两条数据组装路径：

1. 1路径 A（缓存命中路径）：请求进来后检测到 Redis 中已存在该数据的名称映射关系，直接从缓存获取名称，再与其他基础属性组合后返回。
2. 2路径 B（缓存未命中路径 / 实时查询路径）：Redis 缓存缺失，穿透查询远程多语言服务，获取最新名称并组装数据，随后同步写入 Redis 缓存。

// 反面：只在未命中分支补字段，命中分支漏赋值
if (cachedName != null) {
    vo.setDisplayName(cachedName);            // 命中：statusCode / configType 缺失
} else {
    vo.setDisplayName(rpc.getDisplayName());
    vo.setStatusCode(rpc.getStatusCode());    // 未命中：字段齐全
    vo.setConfigType(rpc.getConfigType());
}

// 正面：分支只决定数据来源，组装收敛到一处
String name = cachedName != null ? cachedName : rpc.getDisplayName();
return assembleVo(rpc, name);                 // 命中与否，新字段都在这一个方法里统一回填

为什么不把接口的所有字段都一股脑塞进 Redis？因为不同字段的变更频率与查询成本并不相同：

• •多语言译名：涉及跨服务的多语言字典表查询，网络开销大、调用频率高，但内容相对稳定，非常适合缓存。
• •基础属性（statusCode、configType）：随 RPC 主列表查询直接返回，无需额外的跨服务二次查询，因此没必要增加 Redis 的存储负担。

该接口的缓存失效采用了"比对式校验"策略：每次接口被调用时，先获取 RPC 最新返回的主列表数据，再与 Redis Hash 里的数据对比。Key 按语言维度进行 Hash 分桶存储（例如按 lang_zh、lang_en 区分），随后逐项校验：

1. 1校验点一：Redis 记录条数与最新列表条数是否一致？
2. 2校验点二：Redis 里的主键 ID 集合与最新列表的主键 ID 集合是否完全重合？
3. 3失效动作：只要任意一项对不上，就判定"基础元数据已发生变更，缓存已失效"，随即清空旧缓存并重新构建。
4. 4命中动作：两项都吻合则直接复用缓存译名，避免重复的跨服务查询。

任何技术方案都是在性能、复杂度与业务现状之间做出的权衡。本次评估的技术方案中，也包含一个历史遗留的小局限（非本次改动引入，但值得思考）。

在更完善的分布式架构中，通常有两种标准解法：

• •给缓存加上 TTL（过期时间）：即使没有主动触发失效，缓存到期后也会自动重建，保证最终一致性。
• •数据变更事件通知（MQ）：后台修改译名时，通过消息队列（如 Kafka / RocketMQ）发送变动事件，订阅方主动清除对应的 Redis Key。

对调用方（前端）而言，本次接口升级的对接成本极低：

• •零破坏性变更：响应结构为增量扩展，完全向下兼容，旧版客户端无需强制更新即可正常运行。
• •枚举值映射：statusCode 返回标准枚举编码（字符串格式），客户端按协议契约映射为对应的 UI 状态展现。
• •配置项应用：configType 返回业务配置代码，可直接用于前端逻辑判断，或透传给后续的下游模块。