现有镜像 Kafka 主题方法的主要区别是什么

Question

Kafka MirrorMaker 是一种将 Kafka 主题从源代理镜像到目标代理的基本方法。不幸的是，它不符合我对可配置性的要求。

我的要求很简单：

• 解决方案应该是 JVM 应用程序
• 如果目标主题不存在，则创建它
• 解决方案应该能够为目标主题名称添加前缀/后缀
• 如果配置发生变化，它应该重新加载并即时应用配置

根据this answer，有几种替代解决方案可以做到这一点：

• MirrorTool-for-Kafka-Connect
• Salesforce Mirus（基于 Kafka Connect API）
• Confluent's Replicator
• 构建我自己的应用程序（基于 Kafka Streams 功能）

此外，KIP-382 的创建是为了使 Mirror Maker 更加灵活和可配置。

所以，我的问题是这些解决方案的杀手级功能是什么（与其他解决方案相比），最后根据提供的要求，什么是更好的解决方案。

Answer 1

我看到你指的是my comment there...

至于你的子弹

解决方案应该是JVM应用

所有列出的都是基于 Java 的

如果目标主题不存在，则创建它

这取决于支持 AdminClient API 的 Kafka 代理版本。否则，正如 MirrorMaker 文档所说，您应该在镜像之前创建目标主题，否则您要么（1）被拒绝生成，因为自动主题创建被禁用（2）因为创建了默认配置的主题而看到“一致”数据时出现问题。

话虽如此，默认情况下，MirrorMaker 不会自行“传播”主题配置。当我看的时候，MirrorTool 同样没有。我没有仔细研究 Mirus，但似乎只保留了分区数量

Confluent Replicator 会复制配置、分区，并且会使用 AdminClient。

Replicator、MirrorTool 和 Mirus 都基于 Kafka Connect API。 KIP-382 也是如此

构建我自己的应用程序（基于 Kafka Streams 功能

Kafka Streams 只能在一个单个集群中与from() 和to() 通信。

您不妨只使用 MirrorMaker，因为它已经是 Producer/Consumer 的包装器，并且支持一个集群到另一个集群。如果您需要自定义功能，这就是 MessageHandler 接口的用途。

在更高的层次上，Connect API 也是相当可配置的，而且我发现 MirrorTool 源代码非常容易理解。

解决方案应该能够为目标主题名称添加前缀/后缀

每个人都可以做到这一点，但 MirrorMaker 需要额外/自定义代码。 See example by @gwenshap

如果配置发生更改，请即时重新加载和应用配置

这是一个棘手的问题...通常，您只是反弹 Java 进程，因为大多数配置仅在启动时加载。例外是 whitelist 或 topics.regex 用于查找要使用的新主题。

KIP-382

很难说会被接受。虽然它写得很周到，而且我个人认为它的范围很合理，但它有点违背了 Replicator for Confluent 的目的。由于大部分 Kafka 提交和支持发生在 Confluent 之外，这是一个利益冲突

使用 Replicator 后，它具有一些额外的功能，允许在数据中心故障的情况下进行消费者故障转移，因此在有人将这些 Kafka API 调用反向工程到其他解决方案之前，它仍然很有价值

MirrorTool 也有一个 KIP，但它似乎在邮件列表中被拒绝，并解释说“Kafka Connect 是一个可插拔的生态系统，任何人都可以继续安装这个镜像扩展，但它不应该是core Kafka Connect 项目”，或者至少我是这么读的。

---

什么是“更好”是一个见仁见智的问题，还有其他选择（想到 Apache Nifi 或 Streamsets）。 Even using kafkacat and netcat 你可以一起破解集群同步。

如果您要为企业许可证付费，主要是为了获得支持，那么您不妨使用 Replicator。

我发现 MirrorMaker 可能需要指出一件重要的事情，如果您正在镜像一个不使用 DefaultPartitioner 的主题，那么数据将被重新洗牌到 DefaultPartitioner如果您没有将目标 Kafka 生产者配置为使用与源 Kafka 生产者相同的分区值或分区器类，则在目标集群上。