Kafka 2.x 升 3.x，生产者和消费者要不要一起升？我画了张图

写在前面

公司项目要升级 Kafka，领导让我负责调研。

拿到手一看，好家伙，Producer、Broker、Consumer 三个组件，是不是要一起升级？能不能分开升？升级顺序是啥？

网上的文档要么太深奥，要么太简单。没办法，只能自己一点点啃，顺便把踩坑经历记下来。

如果你也是新手，希望这篇笔记能帮到你。

---

环境信息

• Kafka Broker: 2.x → 3.x
• Kafka Producer: 2.x → 3.x
• Kafka Consumer: 2.x → 3.x
• Spring Boot: 2.7.18
• Spring Kafka: 2.8.x

---

我画了张升级兼容性图

说实话，一开始我也懵，不知道能不能分开升级。

后来画了张表，总算搞明白了：

Producer	Broker	Consumer	是否可行	说明
2.x	2.x	2.x	✅	全部旧版本
2.x	2.x	3.x	✅	只有 Consumer 升级
2.x	3.x	2.x	✅	只有 Broker 升级
2.x	3.x	3.x	✅	Broker + Consumer 升级
3.x	2.x	2.x	✅	只有 Producer 升级
3.x	2.x	3.x	✅	Producer + Consumer 升级
3.x	3.x	2.x	✅	Broker + Producer 升级
3.x	3.x	3.x	✅	全部新版本

看懂了吗？我第一次看的时候，眼睛都花了。

说人话就是：

所有组合都可行！ Kafka 的兼容性做得非常好，Producer、Broker、Consumer 可以任意组合升级。

我当时看到这个表，心想：这不就是随便升吗？

后来实际测试才发现，虽然都能用，但有些组合会有"小脾气"。

---

我实际测试的 5 种升级路径

路径 1：只升级 Broker（推荐）

配置：

• Producer: 2.x
• Broker: 3.x ✅
• Consumer: 2.x

我的感受：

• ✅ 最简单，风险最低
• ✅ 生产者和消费者都不用改代码
• ✅ 可以逐步滚动升级 Broker
• ⚠️ 享受不到 3.x 的新特性

适用场景：

• 想先试试水
• 生产环境求稳
• 客户端太多，不好改

升级步骤：

# 1. 备份配置
cp server.properties server.properties.bak

# 2. 停止一个 Broker
bin/kafka-server-stop.sh

# 3. 升级 Kafka 到 3.x
# 下载新版本，解压

# 4. 启动 Broker（配置不变）
bin/kafka-server-start.sh config/server.properties

# 5. 观察日志，确认正常
tail -f logs/server.log

# 6. 继续升级下一个 Broker（一个一个来！）

教训：Broker 升级要一个一个来，别一起重启！

---

路径 2：先升级 Consumer（次推荐）

配置：

• Producer: 2.x
• Broker: 2.x or 3.x
• Consumer: 3.x ✅

我的感受：

• ✅ Consumer 端升级相对简单
• ✅ 可以先测试，没问题再升 Producer
• ⚠️ 注意 Consumer 配置变更

适用场景：

• Consumer 数量少，好升级
• 想先体验 3.x 的消费者特性
• 对消费者性能有要求

Consumer 配置变更：

# 2.x 配置
spring:
  kafka:
    consumer:
      auto-offset-reset: earliest
      enable-auto-commit: true

# 3.x 配置（多了这些）
spring:
  kafka:
    consumer:
      isolation-level: read_committed  # 3.x 新增
      max-poll-records: 500            # 默认值变了

教训：升级 Consumer 前，先把配置过一遍！

---

路径 3：先升级 Producer（一般推荐）

配置：

• Producer: 3.x ✅
• Broker: 2.x or 3.x
• Consumer: 2.x

我的感受：

• ✅ Producer 升级也简单
• ⚠️ 注意序列化器变更
• ⚠️ 注意配置项变更

适用场景：

• Producer 数量少
• 想先体验 3.x 的生产者特性
• 对生产者性能有要求

Producer 配置变更：

# 2.x 配置
spring:
  kafka:
    producer:
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.apache.kafka.common.serialization.StringSerializer

# 3.x 配置（注意这些）
spring:
  kafka:
    producer:
      acks: all                          # 建议改成 all
      retries: Integer.MAX_VALUE         # 无限重试
      enable-idempotence: true           # 启用幂等性（3.x 推荐）

教训：Producer 升级后，记得测试消息格式兼容性！

---

路径 4：Consumer + Broker 一起升（激进）

配置：

• Producer: 2.x
• Broker: 3.x ✅
• Consumer: 3.x ✅

我的感受：

• ⚠️ 风险较高，要谨慎
• ✅ 升级完成后，消费者能享受新特性
• ⚠️ 需要充分测试

适用场景：

• 测试环境先试
• 对消费者性能要求高
• 有充足的测试时间

教训：这种升级方式，一定要在测试环境先跑一周！

---

路径 5：全部一起升（头铁）

配置：

• Producer: 3.x ✅
• Broker: 3.x ✅
• Consumer: 3.x ✅

我的感受：

• ❌ 风险最高，不推荐
• ✅ 升级完成后最干净
• ⚠️ 出问题不好排查

适用场景：

• 新项目，还没上线
• 测试环境随便折腾
• 有完整的回滚方案

教训：生产环境别这么干！别头铁！

---

我推荐的升级顺序

根据我的实际经验，推荐这个顺序：

第 1 步：只升级 Broker（滚动升级，一个一个来）
       ↓
       观察 1-2 天，确认没问题
       ↓
第 2 步：升级 Consumer（先升级不重要的服务）
       ↓
       观察 1-2 天，确认没问题
       ↓
第 3 步：升级 Producer（先升级非核心业务）
       ↓
       观察 1-2 天，确认没问题
       ↓
完成！🎉

为什么这么推荐？

1. Broker 优先：Broker 升级后，兼容所有旧版本客户端
2. Consumer 其次：Consumer 升级相对简单，影响小
3. Producer 最后：Producer 升级要谨慎，怕消息格式不兼容

我的感受：

• 虽然慢了点，但心里有底
• 每一步都能回滚
• 出了问题好排查

---

升级前后的变化

Broker 升级后的变化

2.x Broker：

# 需要 ZooKeeper
zookeeper.connect: zk1:2181,zk2:2181,zk3:2181/kafka
zookeeper.connection.timeout.ms: 18000

3.x Broker：

# 还是用 ZooKeeper（KRaft 是可选的）
zookeeper.connect: zk1:2181,zk2:2181,zk3:2181/kafka

# 3.x 新增配置
inter.broker.protocol.version: 3.0
log.message.format.version: 3.0

我的感受：

• 配置变化不大
• 多了些性能优化参数
• Controller 选举快了很多

---

Producer 升级后的变化

2.x Producer：

// 配置
props.put(ProducerConfig.ACKS_CONFIG, "1");
props.put(ProducerConfig.RETRIES_CONFIG, 3);

// 发送消息
producer.send(new ProducerRecord<>("topic", "key", "value"));

3.x Producer：

// 配置（建议调整）
props.put(ProducerConfig.ACKS_CONFIG, "all");  // 改成 all
props.put(ProducerConfig.RETRIES_CONFIG, Integer.MAX_VALUE);  // 无限重试
props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, true);  // 启用幂等

// 发送消息（一样）
producer.send(new ProducerRecord<>("topic", "key", "value"));

我的感受：

• API 基本没变
• 配置建议调整
• 性能略有提升

---

Consumer 升级后的变化

2.x Consumer：

// 配置
props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");
props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "true");

// 消费消息
ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));

3.x Consumer：

// 配置（多了些）
props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");
props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "true");
props.put(ConsumerConfig.ISOLATION_LEVEL_CONFIG, "read_committed");  // 新增

// 消费消息（一样）
ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));

我的感受：

• API 基本没变
• 多了些配置项
• 消费者重平衡更快了

---

我踩过的坑

坑 1：一起重启所有 Broker

# ❌ 我当时手贱，一起重启了
kill -9 <pid1>
kill -9 <pid2>
kill -9 <pid3>

# 结果：集群挂了，重启了好久

# ✅ 正确做法：一个一个来
kill -9 <pid1>
# 等 1 分钟，确认正常
kill -9 <pid2>

教训：别手贱！一个一个重启！

---

坑 2：没看配置变更

# ❌ 我直接升级，没看配置
# 结果：有些配置项被废弃了

# ✅ 正确做法：先看升级文档
# 检查所有配置项
# 调整不推荐的配置

教训：升级前先过一遍配置！

---

坑 3：没监控就升级

# ❌ 我当时头铁，直接升级
# 结果：出问题了不知道哪的问题

# ✅ 正确做法：先配监控
# - CPU 使用率
# - 内存使用率
# - 磁盘 IO
# - 网络流量
# - 消息堆积量

教训：监控很重要！很重要！很重要！

---

验证步骤

1. 检查 Broker 版本

# 查看 Broker 版本
bin/kafka-broker-api-versions.sh --bootstrap-server localhost:9092

# 预期结果：应该显示 3.x.x

2. 检查 Producer 和 Consumer

# 查看客户端版本（需要启用 JMX）
# 在 producer/consumer 启动参数中添加：
-Djava.security.auth.login.config=/path/to/jaas.conf

# 查看消息是否正常发送和消费
bin/kafka-console-producer.sh --topic test --bootstrap-server localhost:9092
bin/kafka-console-consumer.sh --topic test --from-beginning --bootstrap-server localhost:9092

3. 检查性能指标

# 观察这些指标
- 消息发送延迟
- 消息消费延迟
- Broker CPU 使用率
- Broker 内存使用率

预期结果：应该和升级前差不多，或者更好。

---

回滚方案

如果升级后出现问题，可以快速回滚：

回滚 Broker

# 1. 停止 Broker
bin/kafka-server-stop.sh

# 2. 恢复旧版本 Kafka
# 解压旧版本

# 3. 恢复配置文件
cp server.properties.bak server.properties

# 4. 启动 Broker
bin/kafka-server-start.sh config/server.properties

回滚 Producer/Consumer

<!-- pom.xml 恢复旧版本 -->
<dependency>
    <groupId>org.apache.kafka</groupId>
    <artifactId>kafka-clients</artifactId>
    <version>2.8.2</version>  <!-- 恢复旧版本 -->
</dependency>

教训：升级前一定要留好退路！

---

总结

升级兼容性

• ✅ 所有组合都可行：Producer、Broker、Consumer 可以任意组合
• ✅ 向下兼容：3.x 客户端兼容 2.x Broker
• ✅ 向上兼容：2.x 客户端兼容 3.x Broker

我推荐的升级顺序

1. 第 1 步：只升级 Broker（滚动升级）
2. 第 2 步：升级 Consumer（先测试环境）
3. 第 3 步：升级 Producer（先非核心业务）

核心要点

• 必须一个一个升级 Broker：别一起重启！
• 必须先在测试环境测试：别直接上生产！
• 必须配监控：出问题了能发现！
• 必须留退路：随时能回滚！

最后说两句

其实也没多难，就是一步步来。

我刚开始也懵，后来一点点试，总算是搞定了。

肯定有理解不对的地方，欢迎大佬指正。

如果你也遇到类似问题，希望这篇笔记能帮到你。