跨数据中心场景下,kafka集群部署模式

时间:2023-01-23 19:37:57

kafka在多数据中心场景下和单数据中心的场景部署是一样的吗?kafka的性能对分布式系统而言,非常重要。一旦延迟较大的情况下,应该如何部署。

一、为什么要跨数据中心部署?

大型的分布式软件,发展到一定阶段,一个数据中心满足不了需求,通常在一个城市会有多个数据中心,一个城市的多个数据中心通过专线连接,延迟比较小。

如果还是满足不了需求,例如你在世界各地都有用户,不可能让美国用户访问中国的服务,延迟非常严重。在一个城市无法做到容灾,例如,发生地震,整个城市都不可用了,这时候,你需要建立跨地域的数据中心。

一旦跨数据中心部署,如何让Kafka高可用?MirrorMaker就是为了解决这个问题而生。

挑战在什么地方?和其他跨数据中心部署的有状态的系统问题是一样的,消费者是有状态的,也就是offset,故障切换的过程中,如何保证一致性?


二、MirrorMaker

跨数据中心场景下,kafka集群部署模式

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


跨数据中心场景下,kafka集群部署模式


生产者只在活的数据中心生产数据,而备份的数据中心只能消费数据。通过MirrorMaker从DC1复制数据到DC2,活跃的数据中心出现故障时,生产者切换到备份的数据中心。

挑战:切换时,offset如何同步?

非常有学问的一个点。可以根据具体的业务场景来设置,比较简单的,从头开始,不会丢数据,如果满足幂等,但是有可能花费很长时间。从最大开始,会丢失一部分数据,当然如果这部分数据不是特别重要,并且又比较实时的话。或者根据时间设置,这个kafka已经支持。

B.active/active


跨数据中心场景下,kafka集群部署模式


本地有两个集群,一个是本地生产者,一个是集成本地和其他数据中心的集成者。这样是为了避免循环复制。这时候,如果有两个数据中心,实际上MirrorMaker会做四次复制,成本还是很高的。这种模式的好处是两个数据中心都是活跃的。资源利用率更高。因为平衡,故障恢复时,不需要重新配置MirrorMaker。

故障切换时,同样的问题是offset的同步。

C.变种


跨数据中心场景下,kafka集群部署模式


另一种变化是去除集成者,通过topic前缀避免循环复制。这样整个集群架构变的简单,并且节省资源。

同样的问题是offset的同步问题。



三、Uber方案

很早之前,uber就开始使用kafka作为消息中间件,特别是收集日志,

跨数据中心场景下,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集群。

跨数据中心场景下,kafka集群部署模式

B.使用samza进行复制。Samza也是linkedin贡献给Apache的开源项目,主要是对流的处理,可以和kafka很容易的集成。samza使用simple api。

优势:高度稳定、可靠;易维护;作业重启对复制流量影响非常小。

问题:仍然是静态的,需要重启添加或删除topic;需要重启添加更多worker;topic扩展需要明确处理。

C.使用基于Apache Helix的Kafka消费者。Helix也是linkedin开源的,最终,uber决定基于Helix构建

优点

- 添加和删除topic非常容易。

- 添加和删除节点到MirrorMaker集群非常容易。

- 我们从不需要为了操作原因重新启动集群(仅用于升级)。

- 它是高度可靠和稳定。

缺点

- 这引入了对Helix的依赖。

跨数据中心场景下,kafka集群部署模式

实际上,以前的MirrorMaker主要没有资源调度能力,而Helix的加入让整个方案具备了这个能力。由于zookeeper的参与,可以动态通知Helix Agent动态的完成相关添加、删除,不需要重启;uReplicator使用的是simple API,废除了消费端原有的负载均衡机制,而是通过添加、删除节点来完成工作。下图是使用uReplicator后的统计图。

跨数据中心场景下,kafka集群部署模式

四、参考文献

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