有一些最佳实践建议在目标集群上运行mirror maker。https://community.hortonworks.com/articles/79891/kafka-mirror-maker-best-practices.html
我想知道为什么会有这样的建议，因为最终所有的数据都必须跨越集群之间的边界，而不管它们是在目标位置消费的还是在源位置生成的。我可以想象的一个原因是，mirror maker支持多示例使用者，但只有一个生产者，因此使用多个使用者可能会加快在途中使用延迟更大的数据的速度。
如果多线程带来的性能是一个问题，那么使用多个生产者（每个消费者一个）来复制数据（使用自定义复制过程）会是一种错误吗？有人知道为什么镜子制造商在所有消费者中共用一个生产商吗？
我的用例是将数据从多个源集群（~10）复制到单个目标集群。我更愿意在源集群上运行复制进程，以避免在目标集群上有太多复制进程（每个进程对应一个源）。
关于这个主题的提示和建议是非常受欢迎的。
1条答案
按热度按时间ssgvzors1#
我还在Apache·Kafka的邮件列表中提出了这个问题：
https://lists.apache.org/thread.html/06a3c3ec10e4c44695ad0536240450919843824fab206ae3f390a7b8@%3cusers.kafka.apache.org%3e
我想在这里引用一些合理的答案：
franz，您可以在源集群或目标集群上或附近运行mm，但是在目标集群附近运行mm效率更高，因为这样可以最小化生产者延迟。如果延迟很高，poducers会阻止等待飞行记录的ack，这会降低吞吐量。
我建议在目标集群附近运行mm，但不一定要在同一台机器上运行，因为kafka节点通常比较昂贵，有ssd阵列和巨大的io带宽等，这对mm来说是不必要的。
瑞安
以及
嗨，弗兰兹！
我想，其中一个原因可能是额外的安全，以防网络分裂。
即使是好的软件也有可能出现错误。因此，如果我们将mm放在源集群上，网络将分裂，消费者（理论上）可以继续从源集群读取消息并提交它们，即使没有来自目标集群的请求（可能的错误之一）。这样，在网络修复之后，您将在producer上丢失消息。
另一方面，如果我们把mm放在目标集群上，网络就会分裂，就不会有什么不好的事情发生。mm将无法grep来自源集群的数据，所以即使出现bug，您的数据也不会损坏。
托利亚