4. Kafka Connect 分布式模式

分布式模式，才是 Kafka Connect 真正发力的地方。单机模式说白了就是给你开发测试用的，真要上生产环境，你肯定得用分布式。我最早接触 Connect 时，觉得分布式不就是多起几个进程嘛，结果第一次部署就踩了坑——嗯，今天我把这些经验都摊开来讲。

4.1 分布式模式的核心配置

先看配置文件。分布式模式需要每个 worker 节点都配一个 connect-distributed.properties。我习惯把关键参数分成三组：

4.2 集群部署实战

部署其实不复杂。你只需要在多台机器上启动 Connect 进程，它们会自动组成集群。我一般这么操作：

1. 在所有节点上安装 Kafka 二进制包（只用到 libs 和 bin 目录）
2. 复制 connect-distributed.properties 到每个节点
3. 确保 group.id 在所有节点上一致
4. 逐个启动：bin/connect-distributed.sh config/connect-distributed.properties

启动后，每个 worker 都会向 Kafka 注册自己。你可以通过 REST API 查看集群状态：

# 查看所有 worker
curl http://worker1:8083/workers

# 查看集群中的连接器
curl http://worker1:8083/connectors

我记得有一次部署了 5 个 worker，结果只看到 3 个在线。查了半天，原来是两个节点的 group.id 写错了——一个多了个空格。这种低级错误，排查起来最费时间。

4.3 Rebalance 机制深度解析

Rebalance 是分布式模式的核心机制。说白了，就是当集群成员变化时，Connect 需要重新分配任务。你想想看，一个连接器有多个 task，这些 task 分布在不同的 worker 上。如果某个 worker 挂了，task 就得重新分配给其他 worker。

Rebalance 的触发条件有几种：

• Worker 加入或离开——最常见的情况
• 连接器配置变更——比如修改了连接器的配置
• 连接器状态变化——比如从暂停变为恢复

Rebalance 的过程大致分三步：

1. 停止所有 task——worker 会暂停当前正在运行的任务
2. 重新分配——通过协调器（Group Coordinator）重新计算 task 分配
3. 启动新 task——每个 worker 启动分配给自己的 task

这个过程不是瞬间完成的。我曾经在生产环境中遇到过一个问题：一个连接器有 100 个 task，每次 Rebalance 要花 30 秒。如果集群频繁抖动，数据延迟就会飙升。

这里我画了一张 Rebalance 的流程图，帮你理清整个过程：

4.4 故障转移机制

故障转移，说白了就是当某个 worker 挂了，它的 task 怎么被其他 worker 接管。Connect 的故障转移是自动的，不需要人工干预。

具体流程是这样的：

• Kafka 的 Group Coordinator 会检测到 worker 心跳超时（默认 10 秒）
• Coordinator 触发 Rebalance，把挂掉的 worker 上的 task 重新分配
• 其他 worker 从 offset topic 读取上次提交的偏移量，继续消费

这里有个关键点：偏移量提交频率。如果 worker 挂了，但偏移量还没来得及提交，重启后就会重复消费一部分数据。我遇到过最极端的情况：一个 worker 在处理完 1000 条数据后挂了，但偏移量只提交到第 500 条。恢复后，那 500 条数据被重新处理了一遍。

4.5 集群部署的最佳实践

最后，分享几个我在项目中总结出来的经验：

• Worker 数量建议 3 个以上——太少的话，一个 worker 挂了影响面太大
• 每个 worker 的资源配置要一致——CPU、内存、磁盘，否则 Rebalance 后 task 分配不均匀
• 监控 worker 的 GC 情况——Full GC 会导致心跳超时，触发不必要的 Rebalance
• 使用 REST API 做健康检查——/connectors/{name}/status 可以查看每个连接器的运行状态

嗯，分布式模式的内容差不多就这些。你想想看，理解了 Rebalance 和故障转移，你就能在生产环境中游刃有余了。下次遇到 worker 挂了，你不会慌——你知道它会自动恢复，只是需要一点时间。