September 28, 2025
本文中使用的 Kafka 版本为 v3.3.2
引言
#
Kafka MirrorMaker2 是 Kafka 官方提供的跨集群数据复制工具, 它是基于 Kafka Connect 框架构建的。MirrorMaker2 支持多种部署模式, 包括 Dedicated 模式和 Connect 集群模式，还有 standalone 模式。
其中, Dedicated 模式有一个启动脚本 kafka-mirror-maker.sh, 该脚本会启动一个独立的 MirrorMaker2 实例, 而不需要依赖 Kafka Connect 集群。Dedicated 模式适合小规模的复制任务, 但在大规模部署中, 它缺乏可扩展性和高可用性。
相比之下, Connect 集群模式则是先搭建出一个 Kafka Connect 集群, 再提交 MirrorMaker2 的 MirrorSourceConnector 任务。这种模式下, 可以通过增加或减少 Connect 工作节点来动态调整复制任务的资源, 具备更好的弹性和容错能力。
当然配置上也会更复杂一些, 需要管理 Connect 集群的配置和任务。
那么, 如果我们已经在使用 Dedicated 模式部署了 MirrorMaker2, 但现在需要切换到 Connect 集群模式, 应该如何操作呢? 本文将介绍从 Dedicated 模式迁移到 Connect 集群模式时，怎么处理已经同步的 offset 进度, 以确保数据的一致性和连续性。
...
April 24, 2025
Kafka 和 MongoDB 是目前使用比较广泛的消息队列和数据库，在之前的很长时间里对这两个软件系统的理解都停留在概念和使用上，直到最近遇到一个“诡异”的问题，已有的经验和调试方法无法定位时，最终尝试了下抓包分析才最终定位到问题的根源。
问题描述：
使用 sarama 编写了一个 kafka 消费者组，这里不同寻常的地方在于：手动提交 + 批量消费。遇到的问题：某些分区消费进度无法成功提交，但是消息是消费成功的。出现这种情况的分区没有规律，触发 rebalance 后 “故障分区” 有概率会发生变化。
分析/定位：这里很明显的问题在于手动提交 offset 为什么不成功？从实现来说，提交 offset 的逻辑跟分区没有关系是一致，那这种不确定性故障时从哪儿来的？而且还和 rebalance 相关。
梳理下 kafka 客户端消费提交涉及到的操作：Fetch, OffsetCommit, 但是消费是正常的，那么只需要抓包分析 OffsetCommit 就可以知道 offset 提交存在什么问题。
结果：
通过抓包一切都明朗了：出现问题的分区同时有多个 OffsetCommit 请求，且其中有的请求提交的 offset 一致停留在一个 “旧的” 位置，不会更新，这样就缩小了范围：程序提交 offset 逻辑异常。
KAFKA 协议
#
Kafka 协议是基于 TCP/IP 协议的二进制协议。其结构组成如下：
struct RequestOrResponse {
RequestResponseHeader requestResponseHeader; // uint32 messageLength;
SpecificRequestOrResponseHeader body; // 格式取决于具体的请求和响应，比如：RequestV1Header
}
struct RequestV1Header {
int16 apiKey;
int16 apiVersion;
int32 correlationId;
string clientId;
}
协议结构
#
https://kafka.apache.org/protocol.html#protocol_messages
...