kafka连接器性能压测本质是端到端压测kafka connect集群及特定connector实例，需区分链路类型、明确压测对象、构建闭环测试环境，并采集task状态、吞吐率、offset提交等核心指标。
连接器（Connector）不是 Kafka 本身的核心组件，而是 Confluent Platform 或 Kafka Connect 框架中用于对接外部系统（如数据库、对象存储、ES、HDFS 等）的插件化模块。它的性能瓶颈通常不在 Kafka Broker，而在于连接器自身的任务调度、数据转换、源/目标系统 I/O 和反压处理能力。因此，“Kafka 连接器性能压测”本质是压测 Kafka Connect 集群 + 特定 Connector 实例 的端到端吞吐与稳定性。
明确压测对象和边界
先区分清楚：你压的是“Kafka 生产/消费链路”，还是“Kafka Connect 数据管道”。前者用 kafka-producer-perf-test.sh 和 kafka-consumer-perf-test.sh；后者必须走 Connect API + 实际 Source/Sink 任务。常见误区是拿 Producer 工具去测 JDBC Source，结果毫无参考价值。
- Source Connector 压测重点：从上游系统（如 MySQL binlog、PostgreSQL WAL、文件目录）拉取数据的速度、CPU/内存占用、offset 提交延迟、失败重试行为
- Sink Connector 压测重点：写入下游（如 ES bulk、S3 multipart upload、JDBC batch insert）的并发控制、背压响应、事务一致性（如 exactly-once 支持）、失败后 offset 回滚精度
- 必须启用
tasks.max并横向扩展 Worker 节点，单 Worker + 多 task 容易成为瓶颈
构建可复现的基准测试环境
避免在生产库或共享测试库上直接压测。推荐搭建最小闭环：
Codex Sub Agents 1
下载
使用 OpenAI Codex CLI 处理编码任务。触发词：codex、code review、fix CI、refactor code、implement feature、coding agent、gpt-5-codex。Clawdbot 可将编码工作委托给 Codex CLI 作为子代理或直接工具。
- 用
docker-compose启一个 3 节点 Kafka 集群 + 2 个 Kafka Connect Worker（独立 JVM，堆内存 ≥4G） - Source 端：用 FileStreamSourceConnector 或 MockSourceConnector（如
kafka-connect-mock）生成可控速率/大小的消息，排除数据库侧干扰 - Sink 端：优先选 FileStreamSinkConnector 或 HttpSinkConnector（对接本地 mock server），避免 S3/ES 网络抖动影响指标
- 所有 Connector 配置统一关闭
errors.tolerance=all（初期）以便暴露真实问题，再逐步开启容错
关键指标采集与验证方式
Connect 自身暴露 JMX 和 REST API，不依赖第三方监控也能拿到核心指标：
-
task-status：调用
GET /connectors/{name}/tasks/{id}/status查看 RUNNING/PAUSED/FAILED 状态及最近错误堆栈 -
connector-metrics：通过 JMX 聚焦三个 MBean：
kafka.connect:type=connector-metrics,connector={name}中的status、pause-resume-count、offset-commit-failure-percentage - source-record-poll-rate 和 sink-record-send-rate：单位秒内处理记录数，对比 source→kafka→sink 全链路速率差值，识别卡点环节
- 日志中搜索
Commit of offsets行，确认 offset 提交间隔是否稳定（如设定offset.flush.interval.ms=60000，但实际每 5s 就 flush，说明有异常触发）
典型调优参数组合
不同 Connector 行为差异大，但以下参数具有普适性：
-
tasks.max：设为源系统并行度上限（如 MySQL binlog 只能单线程读，tasks.max=1；S3 列表可设 8–16） -
batch.size（Sink）：JDBC Sink 建议 1000–5000 条/批；ES Sink 推荐 100–500 条（避免 bulk timeout） -
max.buffered.records（Source）：防止内存溢出，尤其当上游突发大量变更时，建议 2000–10000 -
offset.flush.interval.ms和offset.flush.timeout.ms：调高 flush 间隔可提升吞吐，但增加故障恢复数据丢失风险；timeout 建议 ≥3×下游写入平均耗时 - Worker JVM 参数：添加
-XX:+UseG1GC -XX:MaxGCPauseMillis=200，避免 Full GC 导致 task 卡死
