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

1.前言为r尽G减少自然和人为灾难（如停电、灾难性软件故障和网络中断）时业务的影响，以及随存我行培于Kafka的实时业务不断增长，Kafka的重要性口旅增长，在我行逐步优化蹈IDC的Kafka连续性建设已经成为我们目前亟待解决的问题.本文就目前已有的灾备方案在元数据同步、数据豆制、消费位移同步、灾备模式等方面进行谓研对比。2 .现有灾备方案方案描述使用方MirrorMakerl（简称MNI）原理是启动消费者从源泉群进行消费.然后发送到目标集群，功能较筒单Mirror-Maker2（简称MM2）或基干MU2的改进范于KafkaamneCt框架实现，由1.inkedln工程师贡帐，脩复MMl的网限性,T。PiC和分区可自动感知，acl和配置可自动I可步，支持双活，提供OffSet转换功他360ConfluentReplicatorConflUent收费版,与MM2相比,双活模式更优雅，可支持单条消息的修改Confluent基于FolIOWer的同步机制利用Kafka的副本同步机制创建Fetcher线程同步数据，需要在原生Kafka上进行二次开发字节、滴滴URePIiCator改进MMl,利用分布式的任务管理框架ApacheHelix控制ParIition的分配,不需要全部rebalanceUberbrklin改进MM1.实现思路和MM2类似，与URePliCaIOr一样,为了减少rebalance.采用StickyAssignment控制Partition的分配,除了支持Kafka集群间的更制，还能作为AZllreEventHubs,AWSKineSiS流式服务之间的通道,另外还能作为CDC连接器1.inkedIn3 .各方案的主要设计点对比分析3.1 元IR据同步元数据同步主饕是指TOPIc、PartitionXConfigurationAc1.的同步,我们需要评估各方案在新增Topic.分区扩容后.修改Configuration和AC1.后能否自动感知,以及评估方案中选择复制的T。PiC是否灵活（比如是否支持白名单、黑名单机制,是否支持正则）.目标集群中T。PiC名称是否发生改变（决定是否支持双向复制，是否会发生循环更制）.MMl方M中,选择纹制的TOPiC只支持白名单机制（FVhIteIist或者lndude蓼散指定）,且白名单支持正则写法，但是当源集群新增T。PiC后,目标集群的auto.create.topics.enable设置为true时,才能自动在目标集群创电相同名称的TOPia町以扩展messagehandler改名），否则必须重IMiITOrMaker才能发现新增的Topic,关于目标集群上的Topic的分区数，MMl是按默认值num.partitio11s进行配置（其他方案均无该间S）,无法和源集群上保持致，ACl也无法同步,相比MM1,MM2弥补了上述不足,主要是依赖MirrOrSOUrXeConnector里的多个定时任务实现该功能.更新Topic/Partition、Configuration,AC1.的阳隔时长分别由三个参数指定，非常灵活.在MM2中，目前截至3.0Q的版本，支持两种受制策略，默认的DefaultReplicationPoIicY中目标集群中比制后Topic名称发生变化，前面会加一个源集群的前缀,为了兼容MMl,3.0.0中新增的IdentityReplicationPoIicY中目标集群中复制后Topic名称不会发生变化.ConfluentReplicator.根据官网描述,也同样具备上述功能,原理和MM2类似.只是检测更新只由一个参数确定.Replicator可以定义史制后ToPiC的名称，由参数topic.rename.fOrmat指定，成认值是保持Topic名称不变。基FFoil。Wer的同步机制的方案，由于网上资料不足，具体实现无法得知，但是原理估计和MM2类似,发制后在目标集群中T。PiC名称保持不变。URepIiwtor的实现略有不同，或制哪些ToPiC,由参数enableAutoWhiteliSt和PatternToExcIudeTopics,起抉定，当enableAutoWhitelkt设置为true时,若源集群和目标柒群中存在相同Topic,那么不需要其他设置即可实现数据笈制，若设置为false,需要将红制的ToPiC名称等信息提交给URePliCatOrCOntrOIler.由该Controller来控制分区的分配,另外黑名单参数patternToExcludeTopics控制哪些Topic不用复制：分区扩容是否自动礴知,是由参数enableAutoTopicExpansion控制的：关于Configuration和AC1.无法实现同步.brooklin选杼发制的ToPiC只支持在名用机制，可支持正则，新增Topic和分区扩容后可自动感知检测更新山参数PartitiOnFetChlnterValMS确定,复制后ToPiC名称前Ur加酋级，由参数DESTINATlONJOPIC_PFEFIX确定”总结如下:方案MMlMM2ConfluentReplicator基于Follower的同步机制uReplicatorbrookIin及制后Topic名称变化不变，也可自定义可保持不变，也可以增加固定前皴可保持不变,也可以自定义不变不变可保持不变，也可定义前槌自动检测和复制新ToPiC部分支持（取决于目标集群的自动创建topic是否开启）支持支持取决于二次开发的功能不支持支持自动检测和发制新分区不支持支持支持取决于二次开发的功能支持支持源集群和目标集酢总TopicKK一致不支持支持支持支持支持支持配制和AC1.更新是否同步不支持支持支持取决于二次开发的功能不支持不支持选择我制ToPiC的灵活度：是否具有白名中、黑名单和正则表达式的主埋部分支持支持支持取决干二次开发的功能部分支持部分支持3.2数据复制数据复制是灾备方案的最核心点之一，我们需要评估各方案中史制后消息offset能否对齐，”制期间数据的一致性能否保证即是否会丢失数据或者会出现重发数据，首先说明一"由于笈制公有延迟,因此所有这些灾备方案里RPO都不等于0.届于FOlloWer的同步机制的方案可以保持offset对齐，由于副本同步存在延迟，当主机房异常时，备机房上仍有丢失部分数据的可能性，OffSet可保持一致，不会出现重攵数据的可能性。其他方案均不能保证offset对齐（除非是我制时海Topic的offset从。开始），关于每个方案中消费者从源集群消费,再写入到目标东群的逻辑，我们一一详细解择F：先从MMl开始.这是他的设计架构:国园同Consumer1messages.Consumer2offsetCOmmrtSConsumer3WcMcAgo(ome11or.mr*or*wbw*MiOrtlIZeuf!w*iE3”tMtfuMo三n(4HfcAMmt)BOXtJrrwrMXjCRM8TbOft8WAd"O5«在KIP-3MirrorMakerEnhancement里，设计上述架构，从以下几处保证不丢数：1.关掉消费者的自动提交位移提交位移之前公调用producer.flushf）刷出缓存里数据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的是时候出现垂复数据（rebalance时候有代数据位移没提交）,定义了一个新的ConsumerRebaIance监听器.在发生PartitionRevoke的时候，先刷出producer缓存里数据，再提交位移.从上面设计来看，MMl是不丢数，但是还是存在数据重发的可能性，这是Kafka的非格等PrOdUCer决定的，另外MMl的设计还有很多缺陷，比如只有一个PrOdUCer,发送效率低,另外这个ProdUCer是轮询发送.消息发送到目的Topic上的分区和源Topic的分区不一定一致，由于是轮询,这个Producer和集群里每个broker公建立连接.财比URepIicator,同样也是在flush之后再提交位移去避免丢数，在MMl的缺陷都斛到了改进，每个Workerinstance里有多个FetcherThread和多个PrOdUCerThread,从源集群fetch数据后会放到一个队列里,ProducerThread从队列里取走数据并发到目标集群的Topic.每条消息发送到目的Topic上分区和海分区保持一致.可以保持语义上一致。targetbrokerssourcebrokers在brklin中.科个BrooklinInstance中可以起多个ConsumerfUProducer,也可保持治义上致，比URepIicator更有优势的一处就是提供了flushless的生产者（也可提供flush的ProdUCer）,哪叫消息发送成功，才会提交这些位移，因为调用ProducerJIushO可以将缓冲区的数据强制发送，但是代价较高，在清空缓冲前会堵塞发送线程。roucer.rus11tJ->co11surr>er.co11rronsu11er在MirrorMaker2中,采用KafkaCOnneCt框架进行复制数据，从源端消费数据后，存到一个类型为IdentityHaShMaP的内存结构OutstandingMessages,.Producer发送到目的端成功后,公从该内存结构中删除该消息,另外全定时将从源端消费的进度保存到KafkaTopic,这种实现机制不会丢失数据,但是Producer发送成功后，未判进度持久化前进程异常挂掉,那么会产生就复消息,目前在KIP-656:MirrorMaker2Exactly-OnceSemantics提出了一种可实现ExactIyOnIyOnce的方案，思路是将提交消费位移和发送消息放在一个外务里，但是相关PatChKAFKA-IO339仍然没被合进主分支，助后更新停留在20年8月份.根据ConfluentReplicator官网描述，发制不会丢数,但是可能会垂发，因此和上述MM2、URepIicator.brooklin一样,提供的都是AtleastOnceDelivery消息传递语义。方案MMlMM2ConfluentReplicator基于Follower的同步机制UReplicatorbooklin复制前后分区语义一致不支持支持支持支持支持支持offset对齐不能不支持不支持支持不支持不支持消息传递语义不丢数，可能重复AtleastOnce不丢数，可能理发AtleastOncv.未来会提供EOS语义不丢数，可能重更AtleastOnce取决于二次开发的功俄，从Kafka副本同步的原理看，在参数设置合理的情况下，在副本之间同步过程中数据可保持一致不丢敷,可能重发AlleastOnce不丢数，可能重复AlleastOnce3.3消费位移同步灾备方案中除数据发制，消静位移的同步也非常关键.灾备切换后消费者是否能在新的集群中恢复消费.取决干consumeroffset是否能同步.在MMl设计中，若要同步消费位移，只能将_ConSUmeJoffSetS作为一个甘通的Topic进行同步，但是由于源集群和目标集群的。ffset可能存在不对齐的情况，因此无法进行offset转换在MM2设计中,解决了上述MMl问题.设计思路是会定期在目标集群的checkpointT。PiC中记录消费位移，包括源端和目标端的已提交位移，消息包括如下字段：consumergroupid(String)消费组topic(String)-includessourceclusterprefixtopic名称partition(int)分区名称upstreamoffset(int):latestcommittedoffsetinsourcecluster源集群的消费位移downstreamoffset(int):latestcommittedoffsettranslatedtotargetcluster目标集群的消为位移metadata(String)partition元数据timestamp另外，还设计了一个offsetsyncTopic用于记录源端和目的端offset的映射。同时,MM2还提供了MirrOraient接口做位移转换:在URePIiCatOr中，另外设计了个OffSetSynC的服务,跟MM2类似（可能是MM2参考了URePlicatOr的设计）,这个服务可以实时收集不同集种offset的映射关系，计算出从一个DC切换到另一个DC后需要从哪个OffSet进行读取，Duringruntime URepIicatorreportsoffsetmappingtooffsetsyncservice OffsetsyncSefMeeisall-actrvandtheoffsetinfoisreplicatedacrossdatacentersDuringfailover Consumersaskoffsetsyncserviceforoffsetstoresumeconsumptionbasedonitslastcommitoffsets Offsetsyncservicetranslatesoffsetsbetweenaggregateclustersftbrklin中,没有类似URepIicator里的offsetSync服务，需要自己实现ConfluentReplicator,用另外一种思路解袂该问时，不同DC的时间是一致的，在Kafka的消息里包含时间戳，5.0版引入了一项新功能，该功能使用时间戳自动转换偏移fit.以便消费者可以故障转移到不同的数据中心并开始在目标集群中消班他们在源集群中中断的数据.要使用此功能,需要在ConSUmer中设置ConSUmerTimeStamPSInterceptor的拦截器，该拦截器保留消费消息的元数拉;，包括： ConsumergroupID Topicname Partition Committedoffset Timestamp此消费者时间融信息保存在位于源集群中名为_consumer_timestamps的KafkaTOPiC中。然后RePIiCator通过以下步骤进行OffSet转换:从源集群中的ConSUmeJtImeStamPS主题中读取消费者偏移量和时间戳信息，以获取消费者组的进度将源数据中心中的已提交偏移敢转换为目标数据中心中的相应偏移量将转换后的偏移量写入目标集胖中的consumeJoffSetS主Sg那么消督者切换到目标中心的集群后,可继续进行消费.届于FOllOWer的同步机制方案，ToPiC完全-致，只要将_COnSUmeJOffSetS也同步，那么消费者故障转移后仍可继续消费。传消次位移同步方面，各方案总结如1下：方案MMlMM2ConfluentReplicator基于Follower的同步机制UReplicatorbrookIin复制消费位移部分支持支持支持支持部分支持部分支持offset转换不支持支持支持不得要支持不支持客户端切换客户端自定义SeekOffset通过接口获取目标集群的offset,再seek不需要做额外转换.启动叩可不需要做额外转换，启动即可通过synctopic服务杳看目标集群的。ffsct.再Seek客户端自定义SeekOffset3.4是否支持双活为了提升资源利用率，灾备模式的选取也是一个重要考地点。MMl是不支持双活模式的,两个集群无法配置为相互复制(-ctiveActive-),主要是因为如果在两个集群中若存在相同名称的Topic,无法解决ToPiC循环包制的问即,MMl这个可能循环笈制的问题在MM2中解决，解决思路是笈制后的Topic与原Topic名称不一致,会加上源集群的名称作为前缀,例如如下示例中,A%群中的Spicl在发制到B集群后,名称变更为Alopicl.但是MM2默认的DefaultReplicationPoIicy是义制后Topic名你改变,对客户端来说公增加切换代价,可以考虑改成IdentityReplicationPoIiCY,这种复制策略只能支持单向复制，主集群提供业务服务，即ACtiVe/Standy模式.ft：ConfluentReplicator5.0.1中,为了解免循环复制,利用了KIP82AddRecordHeaders的特性,在消息的header里加入了消息来源,如果目标集群的集群ID与header里的源集群ID匹配,并且目标ToPiC名称与header的TOPiC名称匹配，则Replicator不会将消息复制到目标集群.如下图所示：DC-I的ml及制后DC2消息的header!UjI标记,这条消息是从DC-I宏制过来的,那么Replicator不会把DC-2的ml再复制到DC-I,同理,DC-I的m2也不会纪制到DC2因此ConfluentReplicator是可以支持ActiveZActive模式的。在URePliCator中，通过数据的冗余提供Region级别的故期转移,在这种设计中，衽个区域除部署一套本地Kafka集群，还会部署一套聚合集群,这套聚合集群里存储了所有区域的数据，-1Figure2:Kafkareplicationtopologyintworegions当区域集群A和B中存在相同Topic,那么汇聚后，在区域A和B中的消息OffSet可能不一致,URePIiCator设计了一个。ffset管理服务.会记录这个对应关系，示例如卜.：Src-CkisierSrc-Offseidst<lustefdstoffM(Aregoral1Aaggregaie1Bregkxial1Baggregate1BrcgKXial1Aagyegate3A-regxal1B-aogreQate3Aregx)al3Aawegate5BrekXml3B-aggtegate5Breflkxial3Aaggrcgatc7A-regx)a3B-agg<e9ate7N回7一“Figure4:a.Ex9mpteofcrssregionmessagerep6'catonb.Thecheckpointsofthemessagerep*cafon这种设计中，可以支持消静者的ACtiVe/Active和AaiVe/Standy模式，前者是绿个区域起一个消费者消费聚合集群的的数据只有一个区域是主区域,只有主区域的数据可以更新数据到后端数据库中，当主区域故障后，指定新的主区域,新的主区域继续消费计算.在AetiVe/Stand模式中，所有区域中只有一个消费者，该区域故障后，在其他区域启动个消切拧，根据。件Set管理服务里记录的OffSet对应关原，从每个区域的区域集群中找到所有最新的checkpoints,然后根据该CheCkPOintS在Standy区域的限合集群杳找最小offset,从Standy区域的该OffSet开始消费，在brooklin中，也可以通过类似URepIicator的没计利用数据的冗余实现Active/Active灾备模式，BMMTopology花字节介绍的灾备方案中，Producer只能往主集群写（主备集群中的信息是存砧在配置中心里.的，客户端需要先从配跣中心杳询），Producer可以在双中心部署，但是通过配置中心路由到主集群，ConSUmer也可在双中心部署,若采用ACtiVe/Standy模式，各自消费本地机房的数据，但.是只有主集群里消费者的消费位移可以牛.效，在采用ACtiVe/Active模式卜,消费者只能从主集蟀进行消物，这两种模式卜,都是将双中心所有消费者的消费位移果用一个存砧统一存砧.在灾备模式方面，各方案总结如下:方案MMlMM2ConfluentReplicator基于Follower的同步机制uReplicatorbrook1in双集群是否可互相复制不支持支持支持不支持支持，依靠聚合集群支持，依施聚合集群Prcxlucerctive/Active不支持支持支持支持,但足其实只写入主集科支持支持Consumerctive/Standy不支持支持支持支持支持支持ConsumerActive/Active不支持支1.；支持支持支持支持4.各方案的主要设计点总结总结来说，这些方案里归结为三类:1 .Kafka社区的设计路线方案，从源集群消册，再写入到目标集群，包含MM1,MM2,URePIiCatOr'.brooklin这几种方案,MM2是参考了URepIicator的设汁,实现方案和brooklin类似那么在这四种方案中MM2可以作为优先考虑方案。2 .ConfluentReplicator的商业收黄方案，也是利用KafkaCOnneCtNg架进行消费写入，在避免Topic循环我制和消费位移转换方面做得非常出色，客户相切换的代价很低。3 .以字节、滴滴为代表的基于Foil。Wer同步机制的方案这种方案里处制后的T。PiC是源ToPiC的镜像,客户端不需要做。ffset转换,需要改造Kafka代码，考虑到后续和原生Kafka代码的版本融合，技术要求较高。目前来说，没有一个完美的解决方案，各公司可根据自身实际需求制定.