有一些最佳实践建议在目标集群上运行 Mirror Maker。 https://community.hortonworks.com/articles/79891/kafka-mirror-maker-best-practices.html
我想知道为什么存在此建议，因为最终所有数据都必须跨越集群之间的边界，无论它们是在目标处使用还是在源处产生。我可以想象的一个原因是 Mirror Maker 支持多个消费者，但只支持一个生产者 - 因此使用多个消费者可能会加速使用具有更大延迟的途中的数据。
如果多线程的性能很重要，那么使用多个生产者（每个消费者一个）来复制数据（使用自定义复制过程）是否有用？有谁知道为什么 Mirror Maker 在所有消费者中共享一个生产者？
我的用例是将数据从多个源集群（约 10 个）复制到单个目标集群。我宁愿在源集群上运行复制过程，以避免在目标集群上出现许多复制过程（每个用于一个源）。
非常欢迎有关此主题的提示和建议。
我还将问题放在 Apache Kafka 邮件列表中：
https ://lists.apache.org/thread.html/06a3c3ec10e4c44695ad0536240450919843824fab206ae3f390a7b8@%3Cusers.kafka.apache.org%3E
我想在这里引用一些合理的答案：
Franz，您可以在源或目标集群上或附近运行 MM，但它在目标附近更有效，因为这可以最大限度地减少生产者延迟。如果延迟很高，生产者将阻止等待 ACK 以获取正在进行的记录，这会降低吞吐量。
我建议在目标集群附近运行 MM，但不一定要在同一台机器上运行，因为 Kafka 节点通常相对昂贵，具有 SSD 阵列和巨大的 IO 带宽等，这对于 MM 来说不是必需的。
瑞安
和
嗨，弗兰兹！
我想，原因之一可能是网络分裂时的额外安全性。
即使使用好的软件，也存在一定的错误概率。因此，如果我们将 MM 放在源集群上并且网络将分裂，那么消费者可以（理论上）继续从源集群读取消息并提交它们，即使没有来自目标集群的询问（可能的错误之一）。这样，您将在网络修复后最终在生产者上丢失消息。
另一方面，如果我们将 MM 放置在目标集群上并且网络将分裂，则不会发生任何不好的事情。MM 将无法从源集群中 grep 数据，因此即使出现错误，您的数据也不会损坏。
托利亚