Schema Registry 解决什么
Kafka 消息本身是字节数组，生产者和消费者必须对结构达成一致。没有集中管理时，结构变更靠口头同步，消费端往往在反序列化失败时才发现上游改了字段。Schema Registry 把这件事收拢：生产者注册 schema 拿到一个全局 ID，消息体里只带这个 ID，消费者按 ID 拉取 schema 再反序列化，结构变更在注册阶段就接受兼容性检查，破坏性变更会被直接拒绝。
基本信息
| 管理对象 | subject，通常为 <topic>-value 与 <topic>-key |
|---|---|
| 兼容性策略 | BACKWARD（默认）/ FORWARD / FULL / NONE |
| 支持格式 | Avro、Protobuf、JSON Schema |
| 部署形态 | Confluent Schema Registry 或兼容实现，独立服务 |
典型使用场景
- 订单、支付等核心主题的结构治理：字段新增必须通过兼容性检查
- 多团队共享主题：消费方众多，结构变更必须可向后兼容
- 数据入湖前的校验：先用 Registry 里的 schema 过滤非法消息
- Protobuf/Avro 服务间通信：避免手写序列化逻辑带来的不一致
- 结构演进审计：每次 schema 版本变更都留有可追溯记录
注册 schema 与查询版本
注册 schema 与查询版本
curl -X POST -H "Content-Type: application/vnd.schemaregistry.v1+json" \
--data '{"schema": "{\"type\": \"string\"}"}' \
http://localhost:8081/subjects/orders-value/versions # 注册新版本并返回 id
curl -s http://localhost:8081/subjects/orders-value/versions/latest # 查看最新 schema
curl -s -X PUT -H "Content-Type: application/vnd.schemaregistry.v1+json" \
--data '{"compatibility": "BACKWARD"}' \
http://localhost:8081/config/orders-value # 设置该 subject 的兼容性策略兼容性策略读法
| 策略 | 含义 | 典型后果 |
|---|---|---|
| BACKWARD | 新 schema 能读旧数据，升级消费端即可 | 默认策略，适合消费端先升级 |
| FORWARD | 旧 schema 能读新数据 | 生产端先升级的场景 |
| FULL | 双向兼容，字段只能增删可选字段 | 最严格，演进空间最小 |
| NONE | 不做检查，任何变更都放行 | 消费端极易直接反序列化失败 |
兼容性检查默认发生在注册阶段；BACKWARD 表示用新 schema 可以读旧数据，是最常用的默认策略。策略既可在全局配置，也可按 subject 覆盖。
删除 schema 版本分软删与硬删：软删后仍可恢复，硬删后用该 ID 编码的历史消息将无法反序列化，等于永久丢失可读性。历史主题上不要做硬删。