Avro Schema 兼容性规则：Backward、Forward、Full、None 四种模式详解

好，咱们今天来啃一块硬骨头——Avro 的四种兼容性模式。说实话，我刚接触 Avro 那会儿，也被 Backward、Forward、Full、None 这几个词绕得晕头转向。后来在线上踩过几次坑，才真正搞明白它们各自管什么、什么时候该用哪个。

简单来说，这四种模式定义了一个核心问题：新 Schema 和旧 Schema 之间，到底能不能互相读得懂？ 你想想看，Kafka 消息队列里生产者升级了 Schema，消费者还是老版本，要是兼容性没配好，轻则丢字段，重则直接反序列化失败。嗯，咱们今天就把它彻底理清楚。

4.1 四种兼容性模式的核心逻辑

在深入细节之前，我先画一张图，帮你建立整体认知。这张图展示了四种模式在「读」和「写」两个维度上的约束关系。

4.2 Backward 兼容（向后兼容）

定义：使用新 Schema 的 reader 能够成功读取使用旧 Schema 写入的数据。

说白了，就是「新版本能读懂老版本写的东西」。这在微服务架构里非常常见——你先把消费者升级到新 Schema，生产者还在用老 Schema 发数据，消费者得能正常消费。

4.2.1 允许的操作

• 添加有默认值的字段——新 Schema 多了个字段，但旧数据里没有，reader 就用默认值填充。
• 删除字段——新 Schema 删掉了一个字段，旧数据里还有，reader 直接忽略它。
• 修改字段默认值——只要不改变字段类型，改默认值是安全的。

4.2.2 禁止的操作

• 添加没有默认值的字段——旧数据里没有这个字段，reader 不知道填什么，直接报错。
• 改变字段类型——比如把 int 改成 string，reader 没法自动转换。

// 旧 Schema (v1)
{
  "type": "record",
  "name": "User",
  "fields": [
    {"name": "name", "type": "string"},
    {"name": "age", "type": "int"}
  ]
}

// 新 Schema (v2) — Backward 兼容
{
  "type": "record",
  "name": "User",
  "fields": [
    {"name": "name", "type": "string"},
    {"name": "age", "type": "int"},
    {"name": "email", "type": "string", "default": ""}  // 有默认值，OK
  ]
}

4.3 Forward 兼容（向前兼容）

定义：使用旧 Schema 的 reader 能够成功读取使用新 Schema 写入的数据。

Forward 和 Backward 正好反过来——「老版本能读懂新版本写的东西」。什么时候用？比如你的生产者先升级了 Schema，但消费者还没来得及升级，消费者得能继续消费新数据。

4.3.1 允许的操作

• 添加字段——新 Schema 多了字段，旧 reader 直接忽略它（Avro 的 reader 默认会忽略未知字段）。
• 删除有默认值的字段——新 Schema 删了字段，旧 reader 读不到，就用默认值填充。

4.3.2 禁止的操作

• 删除没有默认值的字段——旧 reader 期望有这个字段，但新数据里没有，直接报错。
• 改变字段类型——同上，类型不匹配就炸。

// 旧 Schema (v1)
{
  "type": "record",
  "name": "User",
  "fields": [
    {"name": "name", "type": "string"},
    {"name": "age", "type": "int"}
  ]
}

// 新 Schema (v2) — Forward 兼容
{
  "type": "record",
  "name": "User",
  "fields": [
    {"name": "name", "type": "string"}
    // 删掉了 age 字段，但 v1 中 age 没有默认值 → 不兼容！
  ]
}

4.4 Full 兼容（完全兼容）

定义：同时满足 Backward 和 Forward 兼容。新 Schema 能读旧数据，旧 Schema 也能读新数据。

Full 是最严格的模式，也是我最推荐在生产环境中使用的模式。它要求 Schema 的变更必须同时考虑两个方向——你想想看，这其实意味着：你只能添加有默认值的字段，或者删除有默认值的字段。 说白了，就是不能动那些「没有默认值」的字段。

4.4.1 允许的操作

• 添加有默认值的字段——新 reader 用默认值补旧数据，旧 reader 忽略新字段。
• 删除有默认值的字段——新 reader 忽略被删字段，旧 reader 用默认值补。
• 修改字段默认值——只要不改类型。

4.4.2 禁止的操作

• 添加或删除没有默认值的字段——任何一方都会缺数据。
• 改变字段类型——双向都不兼容。
• 重命名字段——Avro 的字段名是强绑定的，改名等于删旧加新，除非用别名（aliases）。

// 旧 Schema (v1)
{
  "type": "record",
  "name": "User",
  "fields": [
    {"name": "name", "type": "string"},
    {"name": "age", "type": "int", "default": 0}
  ]
}

// 新 Schema (v2) — Full 兼容
{
  "type": "record",
  "name": "User",
  "fields": [
    {"name": "name", "type": "string"},
    {"name": "age", "type": "int", "default": 0},
    {"name": "email", "type": "string", "default": ""}
  ]
}

4.5 None 兼容（无兼容性）

定义：不进行任何兼容性检查。新 Schema 可以任意修改，哪怕和旧 Schema 完全不搭边。

None 模式说白了就是「放飞自我」。你可以加字段、删字段、改类型、改名字，想怎么改就怎么改。但代价是——所有使用旧 Schema 的 reader 都会挂掉。

4.5.1 什么时候用 None？

• 开发/测试环境——Schema 还在快速迭代，不关心兼容性。
• 一次性数据管道——数据消费完就删，没有历史包袱。
• Topic 重建场景——旧数据全部清空，重新开始。

4.6 四种模式对比总结

模式	新 Schema 读旧数据	旧 Schema 读新数据	允许添加字段	允许删除字段	推荐场景
Backward	✅ 兼容	❌ 不保证	✅ 需默认值	✅ 可删除	消费者先升级
Forward	❌ 不保证	✅ 兼容	✅ 可添加	✅ 需默认值	生产者先升级
Full	✅ 兼容	✅ 兼容	✅ 需默认值	✅ 需默认值	双向升级不确定
None	❌ 不兼容	❌ 不兼容	✅ 无限制	✅ 无限制	开发/测试环境

4.7 实战选择建议

说了这么多，到底该怎么选？我个人的经验是：

1. 默认用 Full——除非你有明确的理由换别的模式。Full 虽然限制多，但能避免绝大多数线上事故。
2. Backward 用于消费者先行升级——比如你要加一个新字段，消费者先改代码适配，生产者慢慢升级。
3. Forward 用于生产者先行升级——比如你要删一个字段，生产者先不发这个字段了，消费者后升级。
4. None 只在开发环境用——生产环境用 None 就是给自己埋雷。