Kafka MirrorMaker是一种将Kafka主题从源镜像到目标代理的基本方法。不幸的是，它不足以满足我的要求，因为它具有足够的可配置性。
我的要求很简单：
根据this answer，有几种替代方法可以做到这一点：
此外，KIP-382的创建是为了使Mirror Maker更加灵活和可配置。
所以，我的问题是这些解决方案的杀手级功能（与其他解决方案相比）是什么，最后，根据提供的要求，有什么更好的解决方案？
答案 0 :(得分：2)
我看到您指的是my comment there...
关于子弹
解决方案应该是JVM应用程序
所有列出的都是基于Java的
如果目标主题不存在，请创建
这取决于支持AdminClient API的Kafka代理版本。否则，如MirrorMaker文档所述，您应该在镜像之前创建目标主题，否则，您将得到（1）由于自动主题创建被禁用而被拒绝生成（2）由于创建了默认配置的主题而无法看到“一致”数据。
也就是说，默认情况下，MirrorMaker不会自行“传播”主题配置。当我看时，MirrorTool同样没有。我没有仔细研究Mirus，但似乎只保留了分区数量
Confluent Replicator确实会复制配置，分区，并且它将使用AdminClient。
复制器，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
很难说会被接受。虽然它虽然写得很好，但我个人认为它的范围是合理的，但它在一定程度上违反了为Refluent提供Replicator的目的。大部分Kafka的承诺和支持都来自Confluent，这是利益冲突
使用了Replicator后，它具有一些额外的功能，可以在数据中心发生故障时允许用户进行故障转移，因此，在有人反向工程那些Kafka API调用其他解决方案之前，它仍然很有价值
MirrorTool也有一个KIP，但似乎在邮件列表中被拒绝，原因是“ Kafka Connect是可插拔的生态系统，任何人都可以继续安装此镜像扩展，但它不应该包含在其中。核心Kafka Connect项目”，或者至少这就是我的阅读方式。
“更好”是一个问题，还有其他选择（想到的是Apache Nifi或Streamsets）。 Even using kafkacat and netcat您可以一起攻克集群同步。
如果您要购买企业许可证（主要是用于支持），则最好使用Replicator。
我发现使用MirrorMaker可能需要指出的一件事是，如果您镜像的主题未使用DefaultPartitioner，则数据将被重新组合到{ {1}}，如果您没有将目标Kafka生产者配置为使用与源Kafka生产者相同的分区值或分区器类，则为目标群集上的{1}}。