关于Confluent Schema Registry及KafkaAvro序列化器的规范与变化问询

1. Schema Registry与KafkaAvroSerializer/Deserializer的交互范式是否会变化？变化是否基于公开规范？ #

核心交互范式（如通过Schema ID嵌入消息体、依赖Registry的REST API完成Schema注册/查询）相对稳定，不会随意变更。Confluent所有对该范式的调整都会基于公开的Schema Registry REST API规范，且严格保证向后兼容性——现有基于旧版本实现的代码，升级后无需大幅修改即可正常工作。版本变更的细节会在对应版本的官方文档中明确说明。

2. KafkaAvroSerializer/Deserializer向Registry发起的请求类型及Schema添加规则 #

请求类型 #

KafkaAvroSerializer（序列化阶段）

• POST /subjects/{subject}/versions：核心请求，用于提交本地Schema到指定Subject。如果该Schema已在Subject中存在，Registry会返回已有的Schema ID；若不存在，则创建新的Schema版本并返回新ID。
• 若配置了Schema缓存（默认启用），重复使用同一Schema时会直接读取缓存的ID，无需重复发起请求。

KafkaAvroDeserializer（反序列化阶段）

• GET /schemas/ids/{id}：从消息中提取Schema ID后，发起该请求获取对应的Schema内容，用于反序列化消息体。
• 同样会缓存已获取的Schema，避免重复请求。

Schema添加到Registry的规则 #

• 格式合规：提交的Schema必须符合Avro规范（若使用其他格式则对应其规范）。
• 兼容性检查：需满足目标Subject配置的兼容性规则（如BACKWARD、FORWARD、FULL、NONE），不满足则Registry会拒绝添加新版本。
• 去重机制：同一Subject下，完全相同的Schema不会重复创建版本，会直接返回已存在的版本ID。
• 权限控制：若启用RBAC，发起请求的主体需拥有该Subject的写入权限。

3. Confluent Platform 7.5文档中Kafka与Schema Registry通信验证Schema是否为近期变更？ #

Kafka Broker本身仍然对Schema一无所知，这个核心逻辑没有改变。文档图示展示的是Confluent Platform新增的Broker端Schema验证可选功能——这是Confluent基于Kafka扩展的增值特性，并非Kafka核心项目的变更。

该功能通过在Broker侧集成Schema Registry的验证逻辑，拦截不符合指定Schema的消息，属于可选启用的特性，不是默认行为。图示是面向用户的功能说明，而非维护者的变更日志。

内容的提问来源于stack exchange，提问作者Marinos An