Kafka多种跨IDC灾备方案分析.docx

《Kafka多种跨IDC灾备方案分析.docx》由会员分享，可在线阅读，更多相关《Kafka多种跨IDC灾备方案分析.docx（24页珍藏版）》请在第一文库网上搜索。

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

2、MM1的局限性,TOPiC和分区可自称MM2）或360动感知，ac1和配置可自动同步，支持双活，提基于MM2的改进供offset转换功能Conf1uentConf1Uent收费版，与MM2相比，双活模式更优Conf1uentRep1icator雅，可支持单条消息的修改基于FOI1oWer的利用Kafka的副本同步机制创建FetCher线程同字节、滴同步机制步数据，需要在原生Kafka上进行二次开发滴改进MM1,利用分布式的任务管理框架APaeheURep1icatorHeIiX控制Partitior1的分配，不需要全部Uberreba1ance改进MM1,实现思路和MM2类似,与URep1ic

3、ator一样，为了减少reba1ance,采用StiCkyASSigninent控制PartitiorI的分配,除了支持brook1in1inkedInKafka集群间的复制，还能作为AZUreEventHubs,AWSKineSiS流式服务之间的通道，另外还能作为CDC连接器3.各方案的主要设计点对比分析3.1元数据同步元数据同步主要是指ToPic、Partition.Configuration、AC1的同步,我们需要评估各方案在新增ToPic,分区扩容后、修改COnfigUratiOn和AC1后能否自动感知，以及评估方案中选择复制的ToPiC是否灵活（比如是否支持白名单、黑名单机制，是否支

4、持正则），目标集群中ToPiC名称是否发生改变（决定是否支持双向复制，是否会发生循环复制）。MM1方案中,选择复制的Topic只支持白名单机制（-white1ist或者-inc1ude参数指定），且白名单支持正则写法，但是当源集群新增ToPiC后，目标集群的auto,create,topics,enab1e设置为true时，才能自动在目标集群创建相同名称的TOPiC（可以扩展messagehand1er改名），否则必须重启MirrorMaker才能发现新增的Topic,关于目标集群上的ToPiC的分区数，MMI是按默认值num.partitions进行配置（其他方案均无该问题），无法和源集群上

5、保持一致，AC1也无法同步。相比MM1,MM2弥补了上述不足，主要是依赖MirrOrSoUrCeConneCtor里的多个定时任务实现该功能，更新TOPiC/Partition、ConfigurationAe1的间隔时长分别由三个参数指定，非常灵活。在MM2中，目前截至3.0.0的版本，支持两种复制策略，默认的DefaU1tReP1iCationPo1iCy中目标集群中复制后ToPiC名称发生变化，前面会加一个源集群的前缀，为了兼容MM1,3.0.0中新增的IdentityRep1icationPo1icy中目标集群中复制后Topic名称不会发生变化OConf1uentRep1icator,根

6、据官网描述，也同样具备上述功能，原理和MM2类似，只是检测更新只由一个参数确定。ReP1iCatOr可以定义复制后TOPiC的名称，由参数topic,rename,format指定，默认值是保持TOPiC名称不变。基于Fo11oWer的同步机制的方案，由于网上资料不足，具体实现无法得知，但是原理估计和MM2类似，复制后在目标集群中Topic名称保持不变。UReP1iCatOr的实现略有不同，复制哪些TOPic,由参数enab1eAutoWhite1ist和PatternToExc1udeTopics一起决定，当enabIeAutoWhiteIist设置为true时，若源集群和目标集群中存在相同

7、ToPic,那么不需要其他设置即可实现数据复制，若设置为fa1se,需要将复制的Topic名称等信息提交给URep1icatorContro11er,由该ContrOI1er来控制分区的分配，另外黑名单参数PatternToExc1udeTopics控制哪些Topic不用复制；分区扩容是否自动感知，是由参数enab1eAut0T0picExpansion控制的；关于Configuration和AC1无法实现同步。brook1in选择复制的TOPiC只支持白名单机制，可支持正则，新增TOPiC和分区扩容后可自动感知，检测更新由参数PartitiOnFetCh1nterVa1MS确定,复制后Top

8、ic名称前可加前缀，由参数DESTINATION_TOPIC_PFEFIX确定。总结如下：基于方案MM1Conf1uentFo11owerMM2URep1icatorbrook1inRep1icator的同步机制复制后ToPiC不变，也可保可保持不可保持不持不变，也可以不变不变变，也可名称变化可自定义变，自定义定义前缀基于方案MM1MM2Conf1uentFo11owerURep1icatorbrook1inRep1icator的同步机制也可以增加固定前缗部分支持农自动检测和复制新Topic（取决于目标集群的自动创建topic是否开启）支持支持取决于二次开发的不支持功能支持自动检测和复制新分区

9、源集群和目标不支持支持支持取决于二次开发的支持功能支持集群总Topic不支持支持支持支持支持支持配置一致基于方案配置和AC1更新是否同步MM1不支持MM2支持Conf1uentFo11owerURep1icatorbrook1inRep1icator的同步机支持制取决于二次开发的不支持功能不支持选择复制Topic的灵活度：是否具有取决于二白名单、黑名单和正则表达式的主题部分支持支持支持次开发的部分支持功能部分支持3.2数据复制数据复制是灾备方案的最核心点之一，我们需要评估各方案中复制后消息offset能否对齐，复制期间数据的一致性能否保证即是否会丢失数据或者会出现重复数据。首先说明一下，由于复

10、制会有延迟，因此所有这些灾备方案里RPO都不等于0。基于Fo11ower的同步机制的方案可以保持offset对齐，由于副本同步存在延迟，当主机房异常时，备机房上仍有丢失部分数据的可能性，OffSet可保持一致，不会出现重复数据的可能性。其他方案均不能保证OffSet对齐（除非是复制时源TOPiC的OffSet从O开始），关于每个方案中消费者从源集群消费，再写入到目标集群的逻辑，我们一一详细解释下：先从MMI开始，这是他的设计架构：在K1P-3MirrorMakerEnhanCenIent里，设计了上述架构，从以下几处保证不丢数：1 .关掉消费者的自动提交位移，提交位移之前会调用producer

11、,f1ush（）刷出缓存里数据2 .在ProdUCer端，通过设置这几个参数max.in.f1ight,requests.per.connection=1（多个consumer共享一个producer,这个producer每次只给broker发一个request）,retrieS=Int.MaxVa1ue（返回是可重试异常，无限次重试直到缓冲区满），ack=T（发给所有副本）3 .设置abortOnSendFai1,当producer端收到不可重试异常后（比如消息过大之类的异常），停止MirrorMaker进程，否则会丢失发送失败的部分数据另外为了避免在consumer发生reba1ance的

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

13、ush之后再提交位移去避免丢数，在MM1的缺陷都得到了改进，每个Workerinstance里有多个FetcherThread和多个ProducerThread,从源集群fetch数据后会放到一个队列里，PrOdUCerThread从队列里取走数据并发到目标集群的ToPic,每条消息发送到目的Topic上分区和源分区保持一致，可以保持语义上一致。在brook1in中，每个BrOOkIinInStanCe中可以起多个COnSUnIer和Producer,也可保持语义上一致，比URePIiCator更有优势的一处就是提供了f1ush1ess的生产者（也可提供f1ush的ProdUCer）,哪些消息

14、发送成功，才会提交这些位移，因为调用ProdUCer.f1ush。可以将缓冲区的数据强制发送，但是代价较高，在清空缓冲前会堵塞发送线程。OnSUmer.POII()-producer.Send(records)-producer.f1ush()consumer.优化为:consumer.PoII()-producer.SenCI(records)-consumer.COnInIiI(OffSe1S)在Mirrc)rMaker2中，采用KafkaCC)nnect框架进行复制数据，从源端消费数据后，存到一个类型为IdentityHaShMaP的内存结构OUtstandingMessages中，Pr

15、OdUCer发送到目的端成功后，会从该内存结构中删除该消息，另外会定时将从源端消费的进度保存到KafkaTOPiC中。这种实现机制不会丢失数据，但是PrOdUCer发送成功后，未将进度持久化前进程异常挂掉，那么会产生重复消息。目前在KIP-656：MirrOrMaker2ExactIy-OnCeSenIantiCS提出了一种可实现EXaCtIyOn1yOnCe的方案，思路是将提交消费位移和发送消息放在一个事务里，但是相关PatChKAFKATO339仍然没被合进主分支，最后更新停留在20年8月份。根据COnf1UentReP1iCatOr官网描述，复制不会丢数，但是可能会重复，因此和上述MM2、uRep1icatorsbrookIin一样,提供的都是At1eastOnceDe1ivery消息传递语义。Conf1uent基于Fo11ower的同方案M