环境准备与依赖组件:Kafka 集群部署、ZooKeeper 配置、Confluent Schema Registry 搭建、Kafka Connect 安装
好,咱们正式开始动手。这一章说白了就是搭地基——把 Debezium 依赖的那几个核心组件一个一个装好。我见过不少团队,CDC 链路出问题,最后查来查去,根源都在环境没配稳。所以这一章,咱们稳扎稳打。
本章核心依赖关系:Debezium 作为 Kafka Connect 的一个插件运行,Kafka Connect 依赖 Kafka 集群,Kafka 集群依赖 ZooKeeper(或 KRaft),而 Schema Registry 则为消息提供统一的序列化契约。缺一个,整个链路就跑不起来。
2.1 ZooKeeper 集群配置
虽然 Kafka 3.x 开始推 KRaft 模式,但生产上我目前看到的,ZooKeeper 还是主流。我个人习惯,ZooKeeper 至少 3 节点,奇数台,避免脑裂。
版本选择:ZooKeeper 3.6.x 或 3.7.x 都行,别用 3.5 以下的老版本,性能和安全都有坑。
配置要点不多,但每一条都关键。咱们直接看核心配置:
# zoo.cfg 核心配置
tickTime=2000
initLimit=10
syncLimit=5
dataDir=/data/zookeeper/data
clientPort=2181
# 集群节点列表
server.1=zk1.example.com:2888:3888
server.2=zk2.example.com:2888:3888
server.3=zk3.example.com:2888:3888
# 4lw 命令白名单,监控用
4lw.commands.whitelist=ruok,stat,mntr,conf
每个节点还需要在 dataDir 下创建一个 myid 文件,内容就是对应的 server ID。比如 server.1 的节点,myid 里写 1。
我曾经踩过的坑:initLimit 和 syncLimit 设得太小,网络抖动一下集群就崩了。生产环境建议 initLimit=20、syncLimit=10,给 Leader 选举和 Follower 同步留点余量。
启动命令很简单:
# 启动 ZooKeeper
zkServer.sh start
# 检查状态
zkServer.sh status
# 用 4lw 命令验证
echo ruok | nc localhost 2181
返回 imok 就对了。如果返回空,检查防火墙和 clientPort 配置。
2.2 Kafka 集群部署
Kafka 的部署,说白了就是配好 server.properties,然后启动。但生产环境和开发环境差别很大,我列几个关键参数:
| 参数 | 推荐值 | 说明 |
|---|---|---|
broker.id |
0, 1, 2 ... | 集群内唯一,建议从 0 开始递增 |
log.dirs |
/data/kafka/data | 建议挂载独立磁盘,SSD 优先 |
num.partitions |
3 | 默认分区数,Debezium 主题建议单独设置 |
default.replication.factor |
3 | 副本数,保证高可用 |
offsets.topic.replication.factor |
3 | 消费者偏移量主题副本数 |
transaction.state.log.replication.factor |
3 | 事务状态日志副本数 |
log.retention.hours |
168 | 7 天,根据磁盘容量调整 |
auto.create.topics.enable |
false | 生产环境必须关掉,避免意外创建主题 |
启动 Kafka 前,先确认 ZooKeeper 已经跑起来了:
# 启动 Kafka
bin/kafka-server-start.sh -daemon config/server.properties
# 验证集群状态
bin/kafka-broker-api-versions.sh --bootstrap-server localhost:9092
我建议:用 systemd 管理 Kafka 进程,方便开机自启和日志轮转。网上有现成的 unit 文件模板,改改路径就能用。
2.3 Confluent Schema Registry 搭建
Schema Registry 不是必须的,但如果你用 Avro 或 Protobuf 格式,它就是刚需。Debezium 默认输出 JSON,但生产上我强烈建议用 Avro——省带宽、强类型、兼容性好。
安装 Schema Registry 有两种方式:
- Confluent 官方包:包含所有组件,适合新项目
- 独立 JAR 包:从 Confluent 仓库下载,适合已有 Kafka 集群
核心配置 schema-registry.properties:
# Schema Registry 核心配置
listeners=http://0.0.0.0:8081
kafkastore.bootstrap.servers=PLAINTEXT://kafka1:9092,kafka2:9092,kafka3:9092
kafkastore.topic=_schemas
# 兼容性策略:BACKWARD(默认)、FORWARD、FULL、NONE
compatibility.level=BACKWARD
# 安全配置(如果启用)
# kafkastore.security.protocol=SASL_SSL
注意:kafkastore.topic 默认是 _schemas,副本数建议设为 3,保证 Schema 数据不丢。我见过有人用单副本,结果磁盘坏了 Schema 全丢,所有消费者都反序列化失败——那场面,惨不忍睹。
启动命令:
# 启动 Schema Registry
bin/schema-registry-start -daemon config/schema-registry.properties
# 验证
curl http://localhost:8081/subjects
返回 [] 就说明跑起来了。如果报错连不上 Kafka,检查 kafkastore.bootstrap.servers 配置。
2.4 Kafka Connect 安装
Kafka Connect 是 Debezium 的宿主。它有两种运行模式:
- Standalone 模式:单进程,适合开发测试
- Distributed 模式:多进程集群,生产环境必选
咱们直接上分布式模式。配置 connect-distributed.properties:
# Kafka Connect 分布式配置
bootstrap.servers=kafka1:9092,kafka2:9092,kafka3:9092
group.id=connect-cluster
# 内部主题,自动创建
offset.storage.topic=connect-offsets
offset.storage.replication.factor=3
config.storage.topic=connect-configs
config.storage.replication.factor=3
status.storage.topic=connect-status
status.storage.replication.factor=3
# 插件路径,Debezium 的 JAR 包放这里
plugin.path=/usr/share/java,/data/connect/plugins
# REST API 端口
rest.port=8083
rest.advertised.host.name=connect1.example.com
关键点:plugin.path 指向 Debezium 插件目录。把 Debezium 的 JAR 包解压到这个目录下,Connect 启动时会自动加载。我习惯按 Connector 分目录,比如 /data/connect/plugins/debezium-connector-mysql/,方便版本管理。
启动 Connect:
# 启动分布式 Connect
bin/connect-distributed.sh -daemon config/connect-distributed.properties
# 验证 REST API
curl http://localhost:8083/connectors
返回 [] 表示 Connect 集群已就绪,但还没有部署任何 Connector。别急,下一章咱们就部署 Debezium。
2.5 环境验证清单
所有组件装完后,我建议按这个清单过一遍:
| 组件 | 验证命令 | 预期结果 |
|---|---|---|
| ZooKeeper | echo ruok | nc localhost 2181 |
imok |
| Kafka | bin/kafka-broker-api-versions.sh --bootstrap-server localhost:9092 |
返回 Broker 版本信息 |
| Schema Registry | curl http://localhost:8081/subjects |
[] |
| Kafka Connect | curl http://localhost:8083/connectors |
[] |
小技巧:写一个简单的 shell 脚本,把这几个检查串起来,每天定时跑一遍。我之前的团队就是靠这个脚本,提前发现过 ZooKeeper 磁盘写满的问题。