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

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

1、1.前言为r尽G减少自然和人为灾难（如停电、灾难性软件故障和网络中断）时业务的影响，以及随存我行培于Kafka的实时业务不断增长，Kafka的重要性口旅增长，在我行逐步优化蹈IDC的Kafka连续性建设已经成为我们目前亟待解决的问题.本文就目前已有的灾备方案在元数据同步、数据豆制、消费位移同步、灾备模式等方面进行谓研对比。2 .现有灾备方案方案描述使用方MirrorMakerl（简称MNI）原理是启动消费者从源泉群进行消费.然后发送到目标集群，功能较筒单Mirror-Maker2（简称MM2）或基干MU2的改进范于KafkaamneCt框架实现，由1.inkedln工程师贡帐，脩复MMl的网限

2、性,T。PiC和分区可自动感知，acl和配置可自动I可步，支持双活，提供OffSet转换功他360ConfluentReplicatorConflUent收费版,与MM2相比,双活模式更优雅，可支持单条消息的修改Confluent基于FolIOWer的同步机制利用Kafka的副本同步机制创建Fetcher线程同步数据，需要在原生Kafka上进行二次开发字节、滴滴URePIiCator改进MMl,利用分布式的任务管理框架ApacheHelix控制ParIition的分配,不需要全部rebalanceUberbrklin改进MM1.实现思路和MM2类似，与URePliCaIOr一样,为了减少reb

3、alance.采用StickyAssignment控制Partition的分配,除了支持Kafka集群间的更制，还能作为AZllreEventHubs,AWSKineSiS流式服务之间的通道,另外还能作为CDC连接器1.inkedIn3 .各方案的主要设计点对比分析3.1 元IR据同步元数据同步主饕是指TOPIc、PartitionXConfigurationAc1.的同步,我们需要评估各方案在新增Topic.分区扩容后.修改Configuration和AC1.后能否自动感知,以及评估方案中选择复制的T。PiC是否灵活（比如是否支持白名单、黑名单机制,是否支持正则）.目标集群中T。PiC名称是

4、否发生改变（决定是否支持双向复制，是否会发生循环更制）.MMl方M中,选择纹制的TOPiC只支持白名单机制（FVhIteIist或者lndude蓼散指定）,且白名单支持正则写法，但是当源集群新增T。PiC后,目标集群的auto.create.topics.enable设置为true时,才能自动在目标集群创电相同名称的TOPia町以扩展messagehandler改名），否则必须重IMiITOrMaker才能发现新增的Topic,关于目标集群上的Topic的分区数，MMl是按默认值num.partitio11s进行配置（其他方案均无该间S）,无法和源集群上保持致，ACl也无法同步,相比MM1,M

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

6、M2类似.只是检测更新只由一个参数确定.Replicator可以定义史制后ToPiC的名称，由参数topic.rename.fOrmat指定，成认值是保持Topic名称不变。基FFoil。Wer的同步机制的方案，由于网上资料不足，具体实现无法得知，但是原理估计和MM2类似,发制后在目标集群中T。PiC名称保持不变。URepIiwtor的实现略有不同，或制哪些ToPiC,由参数enableAutoWhiteliSt和PatternToExcIudeTopics,起抉定，当enableAutoWhitelkt设置为true时,若源集群和目标柒群中存在相同Topic,那么不需要其他设置即可实现数据笈

7、制，若设置为false,需要将红制的ToPiC名称等信息提交给URePliCatOrCOntrOIler.由该Controller来控制分区的分配,另外黑名单参数patternToExcludeTopics控制哪些Topic不用复制：分区扩容是否自动礴知,是由参数enableAutoTopicExpansion控制的：关于Configuration和AC1.无法实现同步.brooklin选杼发制的ToPiC只支持在名用机制，可支持正则，新增Topic和分区扩容后可自动感知检测更新山参数PartitiOnFetChlnterValMS确定,复制后ToPiC名称前Ur加酋级，由参数DESTINAT

8、lONJOPIC_PFEFIX确定”总结如下:方案MMlMM2ConfluentReplicator基于Follower的同步机制uReplicatorbrookIin及制后Topic名称变化不变，也可自定义可保持不变，也可以增加固定前皴可保持不变,也可以自定义不变不变可保持不变，也可定义前槌自动检测和复制新ToPiC部分支持（取决于目标集群的自动创建topic是否开启）支持支持取决于二次开发的功能不支持支持自动检测和发制新分区不支持支持支持取决于二次开发的功能支持支持源集群和目标集酢总TopicKK一致不支持支持支持支持支持支持配制和AC1.更新是否同步不支持支持支持取决于二次开发的功能不支

9、持不支持选择我制ToPiC的灵活度：是否具有白名中、黑名单和正则表达式的主埋部分支持支持支持取决干二次开发的功能部分支持部分支持3.2数据复制数据复制是灾备方案的最核心点之一，我们需要评估各方案中史制后消息offset能否对齐，”制期间数据的一致性能否保证即是否会丢失数据或者会出现重发数据，首先说明一由于笈制公有延迟,因此所有这些灾备方案里RPO都不等于0.届于FOlloWer的同步机制的方案可以保持offset对齐，由于副本同步存在延迟，当主机房异常时，备机房上仍有丢失部分数据的可能性，OffSet可保持一致，不会出现重攵数据的可能性。其他方案均不能保证offset对齐（除非是我制时海Top

10、ic的offset从。开始），关于每个方案中消费者从源集群消费,再写入到目标东群的逻辑，我们一一详细解择F：先从MMl开始.这是他的设计架构:国园同Consumer1messages.Consumer2offsetCOmmrtSConsumer3WcMcAgo(ome11or.mr*or*wbw*MiOrtlIZeuf!w*iE3”tMtfuMo三n(4HfcAMmt)BOXtJrrwrMXjCRM8TbOft8WAdO5在KIP-3MirrorMakerEnhancement里，设计上述架构，从以下几处保证不丢数：1.关掉消费者的自动提交位移提交位移之前公调用producer.flushf）

11、刷出缓存里数据2 .在producer端，通过设置这几个参数max.in.flight.requests.per.ConneetiOn=I卜多个consumer共享个producer,这个producer每次只给broker发个request）,retries=lnt.MaxValue（返回是可重试异常，无限次重试直到馈冲区满），ack=l（发给所有副本）3 .设置abortOnSendFail,当producer端收到不可Jfc试异常后（比如消息过大之类的异常）.停止MinorMaker进程，否则会丢失发送失败的部分数据另外为了避免在consumer发生rebalance的是时候出现垂复数据

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

13、移去避免丢数，在MMl的缺陷都斛到了改进，每个Workerinstance里有多个FetcherThread和多个PrOdUCerThread,从源集群fetch数据后会放到一个队列里,ProducerThread从队列里取走数据并发到目标集群的Topic.每条消息发送到目的Topic上分区和海分区保持一致.可以保持语义上一致。targetbrokerssourcebrokers在brklin中.科个BrooklinInstance中可以起多个ConsumerfUProducer,也可保持治义上致，比URepIicator更有优势的一处就是提供了flushless的生产者（也可提供flush的

14、ProdUCer）,哪叫消息发送成功，才会提交这些位移，因为调用ProducerJIushO可以将缓冲区的数据强制发送，但是代价较高，在清空缓冲前会堵塞发送线程。roucer.rus11tJ-co11surrer.co11rronsu11er在MirrorMaker2中,采用KafkaCOnneCt框架进行复制数据，从源端消费数据后，存到一个类型为IdentityHaShMaP的内存结构OutstandingMessages,.Producer发送到目的端成功后,公从该内存结构中删除该消息,另外全定时将从源端消费的进度保存到KafkaTopic,这种实现机制不会丢失数据,但是Producer发

15、送成功后，未判进度持久化前进程异常挂掉,那么会产生就复消息,目前在KIP-656:MirrorMaker2Exactly-OnceSemantics提出了一种可实现ExactIyOnIyOnce的方案，思路是将提交消费位移和发送消息放在一个外务里，但是相关PatChKAFKA-IO339仍然没被合进主分支，助后更新停留在20年8月份.根据ConfluentReplicator官网描述，发制不会丢数,但是可能会垂发，因此和上述MM2、URepIicator.brooklin一样,提供的都是AtleastOnceDelivery消息传递语义。方案MMlMM2ConfluentReplicator基于Follower的同步机制UReplicatorbooklin复制前后分区语义一致不支持支持支持支持支持支持offset对齐不能不支持不支持支持不支持不支持消息传递语义不丢数，可能重复AtleastOnce不丢数，可能理发AtleastOncv.未来会提供EOS语义