kafka在多数据中心场景下和单数据中心的场景部署是一样的吗？kafka的性能对分布式系统而言，非常重要。一旦延迟较大的情况下，应该如何部署。
一、为什么要跨数据中心部署？
大型的分布式软件，发展到一定阶段，一个数据中心满足不了需求，通常在一个城市会有多个数据中心，一个城市的多个数据中心通过专线连接，延迟比较小。
如果还是满足不了需求，例如你在世界各地都有用户，不可能让美国用户访问中国的服务，延迟非常严重。在一个城市无法做到容灾，例如，发生地震，整个城市都不可用了，这时候，你需要建立跨地域的数据中心。
一旦跨数据中心部署，如何让Kafka高可用？MirrorMaker就是为了解决这个问题而生。
挑战在什么地方？和其他跨数据中心部署的有状态的系统问题是一样的，消费者是有状态的，也就是offset，故障切换的过程中，如何保证一致性？
MirrorMaker是apache开源的kafka跨数据中心部署时的镜像工具，使用非常简单，
bin/kafka-run-class.sh kafka.tools.MirrorMaker --consumer.configsourceCluster1Consumer.config --consumer.config sourceCluster2Consumer.config--num.streams 2 --producer.configtargetClusterProducer.config --whitelist=".*"
基于MirrorMaker的常用模式：
A．active/passive
生产者只在活的数据中心生产数据，而备份的数据中心只能消费数据。通过MirrorMaker从DC1复制数据到DC2，活跃的数据中心出现故障时，生产者切换到备份的数据中心。
挑战：切换时，offset如何同步？
非常有学问的一个点。可以根据具体的业务场景来设置，比较简单的，从头开始，不会丢数据，如果满足幂等，但是有可能花费很长时间。从最大开始，会丢失一部分数据，当然如果这部分数据不是特别重要，并且又比较实时的话。或者根据时间设置，这个kafka已经支持。
B．active/active
本地有两个集群，一个是本地生产者，一个是集成本地和其他数据中心的集成者。这样是为了避免循环复制。这时候，如果有两个数据中心，实际上MirrorMaker会做四次复制，成本还是很高的。这种模式的好处是两个数据中心都是活跃的。资源利用率更高。因为平衡，故障恢复时，不需要重新配置MirrorMaker。
故障切换时，同样的问题是offset的同步。
C．变种
另一种变化是去除集成者，通过topic前缀避免循环复制。这样整个集群架构变的简单，并且节省资源。
同样的问题是offset的同步问题。
很早之前，uber就开始使用kafka作为消息中间件，特别是收集日志，
uReplicator是uber内部的解决方案，扩展了MirrorMaker，追求可靠性、零数据丢失和易用性，已开源。
在uber，因为数据量大，可能会导致比较大的延迟。他们认为MirrorMaker不能满足uber的原因是：
昂贵的rebalancing。在rebalancing的过程中，uber说他们遇到过大概5-10分钟才能完成。并且，消费者在rebalancing 32次尝试之后放弃，导致永远阻塞。每次rebalancing都如下图所示。当kafka进行rebalancing的时候，MirrorMaker就不动了。这不仅在恢复时增加了压力，也导致延迟较大。
添加topic比较麻烦。因为MirrorMaker的白名单是完全静态的，所以添加topic时必须重启MirrorMaker。重启是非常昂贵的，这使得消费者rebalancing。这简直是一个噩梦。
可能的数据丢失。旧版本MirrorMaker中的AutoCommit可能会导致数据丢失。
元数据同步问题。还是在白名单添加或删除topic时，有时候配置无法在一个节点上更新。
Uber为什么要开发uReplicator？
A．切分成多个MirrorMaker集群。实际上，就是减小MirrorMaker的压力，让一个MirrorMaker针对一个topic的几个分区进行复制。
优势：添加新topic只需要创建新的MirrorMaker；MirrorMaker集群重启比较快。
问题：要维护很多MirrorMaker集群。
B．使用samza进行复制。Samza也是linkedin贡献给Apache的开源项目，主要是对流的处理，可以和kafka很容易的集成。samza使用simple api。
优势：高度稳定、可靠；易维护；作业重启对复制流量影响非常小。
问题：仍然是静态的，需要重启添加或删除topic；需要重启添加更多worker；topic扩展需要明确处理。
C．使用基于Apache Helix的Kafka消费者。Helix也是linkedin开源的，最终，uber决定基于Helix构建
优点：
- 添加和删除topic非常容易。
- 添加和删除节点到MirrorMaker集群非常容易。
- 我们从不需要为了操作原因重新启动集群（仅用于升级）。
- 它是高度可靠和稳定。
缺点：
- 这引入了对Helix的依赖。
实际上，以前的MirrorMaker主要没有资源调度能力，而Helix的加入让整个方案具备了这个能力。由于zookeeper的参与，可以动态通知Helix Agent动态的完成相关添加、删除，不需要重启；uReplicator使用的是simple API，废除了消费端原有的负载均衡机制，而是通过添加、删除节点来完成工作。下图是使用uReplicator后的统计图。
https://eng.uber.com/ureplicator/
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=27846330
Building Large-Scale Stream InfrastructuresAcross Multiple Data Centers with Apache Kafka --Jun Rao Confluent, Inc