Kafka 多种跨 IDC 灾备方案调研对比.docx

《Kafka 多种跨 IDC 灾备方案调研对比.docx》由会员分享，可在线阅读，更多相关《Kafka 多种跨 IDC 灾备方案调研对比.docx（15页珍藏版）》请在优知文库上搜索。

1、1.前言为了尽量减少自然和人为灾难（如停电、灾难性软件故障和网络中断）对业务的影响,以及随着我行基于Kafka的实时业务不断增长，Kafka的更要性日益增长，在我行逐步优化跨IDC的Kafka连续性建设已经成为我们目前亟待解决的问题.本文就目前已有的灾备方案在元数据同步、数据宜制、消费位移同步、灾备模式等方面进行调研对比。2.现有灾备方案方案描述使用方MirrorMakerl（简称MMD摩理是启动消费者从源泉群进行消费然后发送到目标集群，功能较简单MirrorMaker2（筒称MM2）或基于MM2的改进基于KafkaConnect框架实现，由1.inkedIn工程师贡献，修复MMl的局限性,T

2、oPic和分区可自动感知，acl和配汉可白动同步，支持双活，提供OffSet转换功能360Conf1UentReplicatorCOnfIUent收费版,与MV2相比，双活模式更优雅,可支持单条消息的修改Confluent基于FoIlower的同步机制利用Kafka的副本同步机制!创建FetCher或程同步数据，需要在原生Kafka上进行二次开发字节、滴滴uRep1icator改进MMl,利用分布式的任务管理框架ApacheHelix控制Partition的分配,不需要全部rebalanceUberbrooklin改进MM1,实现思路和MM2类似,与URePHCator一样.为了减少rebal

3、ance.采用StickyAssignment控制Partition的分配,除了支持Kafka要群间的史制，还能作为AZUreEventHubs,SKineSiS流式服务之间的通道，另外还能作为CDC连接器Unkedln3.各方案的主要设计点对比分析3.1 元数据同步元数据同步主要是指Topic、Partition.Configuration,AC1.的同步，我们需要评估各方案在新塔Topic,分区扩容后、修改Configuration和AC1.后能否自动感知,以及评估方案中选择复制的TOPiC是否灵活（比如是否支持白名单、黑名单机制，是否支持正则）,目标集群中Topic名称是否发生改变（决定

4、是否支持双向兔制，是否会发生循环复制），MMl方案中，选择复制的Topic只支持白名单机制（-whitelist或者-include参数指定），且白名单支持正则写法，但是当源集群新增Topic后，目标集群的auto.Create.toics.enable设置为true时，才能自动在目标集群创建相同名称的ToPiC何以扩展messagehandler改名）,否则必须圭启MirrorMaker才能发现新增的Topic,关于目标集群上的Topic的分区数，MMl是按默认值num.partitionsiS行配置（其他方案均无该问题），无法和源集群上保持一致，AC1.也无法同步.相比MMl,MM2弥补了

5、上述不足，主要是依赖MirrorsourceConnector里的多个定时任务实现该功能，更新Topic/Partition.Configuration,AC1.的间隔时长分别由三个参数指定，非常灵活.在MM2中，目前截至3.0.0的版本，支持两种豆制策略，默认的DefaultReplicationPoIicy中目标集群中复制后Topic名称发生变化，前面会加一个源集群的前缀，为了兼容MMl,3.0.0中新增的IdentityRePIiCationPOliCy中目标集群中巨制后Topic名称不会发生变化。ConfluentReplicator,根据官网描述，也同样具备上述功能，原理和MM2类似

6、只是检测更新只由一个参数确定.Replicator可以定义夏制后T。PiC的名称，由参数topic.rename.format指定,默认值是保持Topic名称不变。基于Follower的同步机制的方案，由于网上资料不足，具体实现无法得知，但是原理估计和MM2类似,豆制后在目标集群中Topic名称保持不变.URepIicator的实现略有不同，豆制哪些Topic,由参数enableAUtoWhiteliSt和PatternTOEXdUdeTopics一起决定，当enableAUtoWhiteIiSt设置为true时,若源集群和目标集群中存在相同ToPiC,那么不需要其他设笆即可实现数据算制，若设

7、冒为false,需要将复制的Topic名称等信息提交给URepIicatorController,由该Controller来控制分区的分配,另外黑名单参数PatternToExcIudeTopics控制哪些Topic不用复制；分区扩容是否自动感知，是由参数enableAUtoToPiCEXPanSion控制的；关于COnfigUration和AC1.无法实现同步。brooklin选择复制的Topic只支持白名单机制，可支持正则，新增Topic和分区扩容后可自动感知，检测更新由参数PartitionFetchIntervaIMs确定，豆制后Topic名称前可加前缀，由参数DEsTlNATioNj

8、rOPIC-PFEFIX确定.总结如下：方案MMlMM2ConfluentReplicator基于Follower的同步机制URePIiCatorbrook1in复制后ToPiC名称变化不变,也可自定义可保持不变,也可以增加固定前例可保持不变,也可以自定义不变不变可保持不变,也可定义前煲方案MMlMM2CQn门UOntReplicaIor基于Follower的同步机制uReplicatorbrookIin自动检测和复制新Topic部分支持（取决于目标集群的自动创建Iopic是否开启）支持支持取决于二次开发的功能不支持支持自动检测和史制新分区不支持支持支持取决于二次开发的功能支持支持源集群和目标

9、集箱总ToPiC配置-Sl不支持支持支持支持支持支持配四和AC1.更新是否同步不支持支持支持取决于二次开发的功能不支持不支持选择更制Topic的灵活度：是否具有白名单、黑名单和正则表达式的主题部分支持支持支持取决于二次开发的功能部分支持部分支持3.2数据复制数据复制是灾备方案的最核心点之一，我们需要评估各方案中复制后消息offset能否对齐，复制期间数据的一致性能否保证即是否会丢失数据或者会出现里且数据.首先说明一下，由于复制会有延迟，因此所有这些灾备方案里RPO都不等于0.基于Foil。Wer的同步机制的方案可以保持OffSet对齐，由于副本同步存在延迟，当主机房异常时，备机房上仍有丢失部分

10、数据的可能性，offset可保持一致，不会出现重系数据的可能性.其他方案均不能保证offset对齐（除非是兔制时源Topic的offset从0开始），关于每个方案中消巡者从源集群消费,再写入到目标集群的逻辑，我们一一详细解释下：先从MMl开始，这是他的设计架构:HCAMMOiqoMn9fWf.mmmaUr一bo110VWUr*dmMg*MShuMown(MMbehvov)ecMtfthe9forandmoveonifbt8snd3setIoMe在KIP-3MirrorMakerEnhancement里，设计了上述架构，从以下几处保证不丢数：1 .关掉消费者的自动提交位移，提交位移之前会调用Pr

11、odUCer.flush。刷出缓存里数据2 .在producer端，通过设营这几个参数max.in.Hightiequests.per.ConneCtiOn=I侈个ConSUmer共享一个producer,这个PrOdUCer每次只给broker发一ZZbrequest）,retries=Int.MaxValue（返回是可重试异常,无限次重试直到缓冲区满），ack=-l（发给所有副本）3 .设皆abortOnSendFail,当producer端收到不可点试异常后（比如消息过大之类的异甫）,停止MirrorMaker进程，否则会丢失发送失败的部分数据另外为了避免在consumer发生rebal

12、ance的是时候出现更豆数据（rebalance时候有些数据位移没提交），定义了一个新的ConsumerRebaIance监听器，在发生PartitiOnReVOke的时候，先刷出ProdUCer缓存里数据,再提交位移.从上面设计来看，MMI是不丢数，但是还是存在数据重复的可能性，这是Kafka的非带等Producer决定的,另外MMl的设计还有很多缺陷，比如只有一个Producer,发送效率低，另外这个ProdUCer是轮询发送，消息发送到目的Topic上的分区和源Topic的分区不一定一致，由于是轮询，这个Producer和集群里每个broker会建立连接.对比URePlicator,同样

13、也是在flush之后再提交位移去避免丢数，在MMl的缺陷都得到了改迸,每个Workerinstance里有多个FetcherThread和多个ProducerThread,从源集群fetch数据后会放到一个队列里，ProducerThread从队列里取走数据井发到目标集群的Topic.每条消息发送到目的Topic上分区和源分区保持一致，可以保持语义上一致。也可保持语义上一致，比URePliCatOr更有优势的一处就是提供了flushless的生产者(也可提供flush的Producer),哪些消息发送成功，才会提交这些位移，因为调用ProdUCer.flush()可以将缓冲区的数据强制发送，但

14、是代价较商,在清空缓冲前会堵塞发送线程.在MirrorMaker2中，采用KafkaConneCt框架进行复制数据，从源端消费数据后，存到一个类型为IdentityHaShMaP的内存结构OUtStandingMeSSageS中，PrOdUCer发送到目的端成功后，会从该内存结构中删除该消息，另外会定时将从源端消费的进度保存到KafkaTopic中.这种实现机制不会丢失数据,但是Producer发送成功后,未将进度持久化前进程异常挂掉,那么会产生电豆消息.目前在KIP-656:MirrorMaker2Exactly-onceSemantics提出了一种可实现ExactlyOnlyOnce的方案

15、思路是将提交消费位移和发送消息放在一个事务里,但是相关PatchKAFKA-10339仍然没被合进主分支，最后更新停留在20年8月份。根据ConfluentRePliCator官网描述，复制不会丢数，但是可能会重且，因此和上述MM2、URepIicatorsbrooklin一样，提供的都是AtleastOnceDelivery消息传递语义。方案MMlMM2ConfluentReplicator矩于Follower的同步机制UReplicatorbrooklin制前后分区语义一致不支持支持支持支持支持支持offset对齐不能不支持不支持支持不支持不支持消息假递语义不丢数，可能重复AtleastOnce不丢数可能重竟AtleastOnce.未来会提供EoSie义不丢数，可能堂复AtleastOnce取决于二次开发的功能.从Kafka副本同步的原理看，在参数设置合理的情况下，在副本之间同步过程中数据可保持一致不丢数，可能山复lleastOnco不丢数，可能肃夏t