将Kafka部署在单一数据中心是一种相对比较常见的架构，所有的broker，producer和consumer都在同一个数据中心内，一般来说，也都在同一个内网里。
但考虑这样一个问题，公司在北京，上海和深圳都有业务系统，其中上海和北京会生成一些数据或日志，并且这些信息都需要被三地的业务系统所使用。假如我们考虑用Kafka来作为消息系统，那么就不得不考虑多数据中心的部署问题。
上图是一个跨数据中心使用一个kafka集群的例子。我们不会搭建一个跨数据中心的集群，因为这会带来极高的复杂度。此外，kafka不能读replicas，因此即使集群做到跨数据中心，clients仍旧不能保证本地读。
但是很明显，这个架构的问题在于，如果kafka集群所在的数据中心挂掉了，那么所有的数据都丢了。
为了解决这些问题，我们可以在A和B两个主要的数据中心各搭建一个kafka集群。而对于像C这样的只需要consume而不需要produce的数据中心，我们通常把它作为一个后端的环境，来跑一些离线的应用。
在这个设计中，所有的producer都向本地发送数据，数据中心A和B的consumer从本地消费数据。如果A或者B挂掉了，另一个数据中心仍旧能工作。但这么也需要付出一定的代价，如果consumer需要获取所有的数据，就必须连接到所有的数据中心，并且需要处理跨数据中心的网络的连接和延迟问题。
为了把这个模型再优化一下，我们增加了聚合集群的概念，这个集群包含了所有其他集群聚合起来的数据。对于消费者来说，他们只需要在本地就能从聚合集群中拿到所需的数据。当然，我们仍然有跨数据中心的网络问题，但这其实是无法避免的，毕竟我们需要把数据从一个数据中心拷贝或移动到另一个数据中心。我们可以把这些事情都集中到一个应用中完成，这个应用叫做mirrormaker，然后我们可以对mirrormaker进行集中的监控以确保它正常工作。这样对于每个consumer来说，他们就不需要关心消费的网络和延迟问题了。
尽管这种架构更加复杂，但对于client来说，他们使用kafka会变得更简单。对于producer，他们只需要往本地集群中发数据，而不需要关心数据会存放到何处；对于consumer，只要选择一个聚合集群就能获取所有数据。而其他的所有问题，比如数据如何流转，如何传输，都将交给mirrormaker来处理。
