📚 课程目录第4章兼容性检查策略

4、兼容性检查策略：BACKWARD、FORWARD、FULL、NONE策略详解

兼容性检查，说白了就是回答一个问题：Schema变了，老数据和新数据还能不能愉快地玩耍？

我刚开始接触CDC时，觉得这玩意儿就是个开关——要么兼容，要么不兼容。后来在线上栽过跟头才明白，兼容性策略选错了，轻则消费端报错，重则整个数据管道瘫痪。嗯，今天咱们就把这四种策略掰开揉碎了讲清楚。

4.1 四种策略的核心逻辑

先看一张总览图，把四种策略的定位搞清楚：

4.2 BACKWARD策略：向后兼容

定义：新Schema能读老Schema写的数据。

你想想看，在CDC场景里，最常见的情况是什么？消费者已经上线了，生产者还在用老Schema写数据。这时候如果改了Schema，消费者必须能继续消费历史数据。

我个人习惯把BACKWARD叫做"保守派"策略。它只允许两种操作：

添加可选字段（带默认值）——消费者读到老数据时，自动补默认值
删除字段——消费者不再需要这个字段了

实战经验：我在做金融交易系统的CDC时，交易记录表经常要加新字段。比如加一个"风控标签"，但历史交易没有这个字段。用BACKWARD策略，给新字段设默认值""，消费者读到老数据自动补空字符串，完全没问题。

来看一个Avro Schema的兼容性检查示例：

// 老Schema (v1)
{
  "type": "record",
  "name": "Order",
  "fields": [
    {"name": "order_id", "type": "string"},
    {"name": "amount", "type": "double"}
  ]
}

// 新Schema (v2) — BACKWARD兼容
{
  "type": "record",
  "name": "Order",
  "fields": [
    {"name": "order_id", "type": "string"},
    {"name": "amount", "type": "double"},
    {"name": "discount", "type": ["null", "double"], "default": null}  // ✅ 添加可选字段
  ]
}

// 消费者用v2读v1写的数据：discount字段自动补null → 兼容

⚠️ 避坑指南：我曾经遇到一个团队，在BACKWARD策略下删除了一个字段。结果下游有个报表系统依赖这个字段做聚合计算，直接报错。记住：删除字段前，必须确认所有消费者都不再使用它。

4.3 FORWARD策略：向前兼容

定义：老Schema能读新Schema写的数据。

这个策略正好反过来。什么时候用？生产者先升级了Schema，但消费者还没来得及升级。

说白了，FORWARD策略允许的是：

添加字段（新生产者写更多字段）——老消费者忽略不认识的字段
删除可选字段（老消费者不再需要）

你可能会问：老消费者怎么忽略新字段？嗯，这依赖于序列化框架的能力。Avro和Protobuf都支持这个特性——消费者只反序列化自己认识的字段，不认识的直接跳过。

// 老Schema (v1) — 消费者用的版本
{
  "type": "record",
  "name": "User",
  "fields": [
    {"name": "user_id", "type": "string"},
    {"name": "name", "type": "string"}
  ]
}

// 新Schema (v2) — 生产者升级后的版本
{
  "type": "record",
  "name": "User",
  "fields": [
    {"name": "user_id", "type": "string"},
    {"name": "name", "type": "string"},
    {"name": "email", "type": "string"}  // ✅ 添加字段，老消费者忽略
  ]
}

// 老消费者用v1读v2写的数据：忽略email字段 → 兼容

  关键区别：BACKWARD关心的是"新消费者读老数据"，FORWARD关心的是"老消费者读新数据"。两者方向完全相反。

4.4 FULL策略：全兼容

定义：同时满足BACKWARD和FORWARD。

这是最严格的策略。它要求Schema变更后，新老消费者都能读新老数据。说白了，就是双向兼容。

FULL策略只允许一种操作：添加或删除可选字段（带默认值）。

为什么这么严格？因为你要同时保证：

新消费者能读老数据（BACKWARD）→ 新字段必须有默认值
老消费者能读新数据（FORWARD）→ 新字段对老消费者不可见

我在项目中很少用FULL策略。为什么？太严格了，容易卡住Schema演进。有一次我们想给订单表加一个必填字段"payment_method"，FULL策略直接拒绝了——因为老数据没有这个字段，新消费者读老数据时会报错。

什么时候用FULL？我建议只在公共API的Schema上使用。比如你提供一个数据订阅服务，外部客户用各种版本的消费者消费数据，你没法控制他们的升级节奏。这时候FULL策略最安全。

4.5 NONE策略：不检查

定义：关闭兼容性检查，任何Schema变更都允许。

嗯，这个策略听起来很爽——想怎么改就怎么改。但我要泼一盆冷水：NONE策略是给"懂行"的人用的，新手慎用。

我见过一个团队，上线初期图省事用了NONE策略。结果某天DBA把字段类型从int改成了bigint，下游的实时计算任务直接崩溃——反序列化失败。整个数据管道停了2小时。

⚠️ 避坑指南：如果你非要用NONE策略，请确保满足以下条件之一：

所有生产者和消费者都由你统一控制，能同步升级
数据管道有完善的容错和重试机制
只在开发/测试环境使用

我曾经在内部日志采集系统上用过NONE策略，因为所有消费端都是我们自己维护的，可以做到"变更即重启"。但生产环境的核心业务数据，我从来不敢用NONE。

4.6 策略选择指南

怎么选？我总结了一个简单的决策树：

场景	推荐策略	理由
消费者先升级，生产者后升级	BACKWARD	新消费者必须能读老数据
生产者先升级，消费者后升级	FORWARD	老消费者必须能读新数据
无法控制升级顺序，或对外提供API	FULL	双向兼容最安全
开发/测试环境，或全链路可控	NONE	灵活，但风险自担
CDC场景，Kafka Connect + Avro	BACKWARD	大多数CDC工具默认使用此策略

我个人习惯：生产环境默认用BACKWARD。因为CDC场景里，数据是源源不断产生的，消费者通常比生产者更难升级。你想想看，一个实时数仓可能有几十个表、上百个消费者，逐个升级太痛苦了。

4.7 实际案例对比

最后，用一个真实案例把四种策略串起来。假设我们有一个用户表，Schema如下：

// 初始Schema (v1)
{
  "name": "User",
  "type": "record",
  "fields": [
    {"name": "id", "type": "int"},
    {"name": "name", "type": "string"}
  ]
}

现在我们要做三次变更，看看不同策略的反应：

变更操作	BACKWARD	FORWARD	FULL	NONE
① 添加可选字段 email (string, default: "")	✅ 通过	✅ 通过	✅ 通过	✅ 通过
② 删除字段 name	✅ 通过（消费者不再需要）	❌ 拒绝（老消费者依赖name）	❌ 拒绝	✅ 通过
③ 添加必填字段 age (int, 无默认值)	❌ 拒绝（老数据无age）	✅ 通过（老消费者忽略）	❌ 拒绝	✅ 通过

你看，同一个变更在不同策略下结果完全不同。我记得有一次，团队里有人想用NONE策略绕过检查，直接添加必填字段。我拦住了——短期看省事，长期看埋雷。后来我们统一改成了BACKWARD策略，虽然每次加字段都要设默认值，但再也没出过兼容性问题。

  总结一句话：兼容性检查不是限制你，而是保护你。选对策略，Schema演进才能既快又稳。