欢迎来到优知文库! | 帮助中心 分享价值,成长自我!
优知文库
全部分类
  • 幼儿/小学教育>
  • 中学教育>
  • 高等教育>
  • 研究生考试>
  • 外语学习>
  • 资格/认证考试>
  • 论文>
  • IT计算机>
  • 法律/法学>
  • 建筑/环境>
  • 通信/电子>
  • 医学/心理学>
  • ImageVerifierCode 换一换
    首页 优知文库 > 资源分类 > DOCX文档下载
    分享到微信 分享到微博 分享到QQ空间

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

    • 资源ID:1394823       资源大小:183.57KB        全文页数:13页
    • 资源格式: DOCX        下载积分:5金币
    快捷下载 游客一键下载
    账号登录下载
    微信登录下载
    三方登录下载: QQ登录
    二维码
    扫码关注公众号登录
    下载资源需要5金币
    邮箱/手机:
    温馨提示:
    快捷下载时,如果您不填写信息,系统将为您自动创建临时账号,适用于临时下载。
    如果您填写信息,用户名和密码都是您填写的【邮箱或者手机号】(系统自动生成),方便查询和重复下载。
    如填写123,账号就是123,密码也是123。
    支付方式: 支付宝    微信支付   
    验证码:   换一换

    加入VIP,免费下载
     
    账号:
    密码:
    验证码:   换一换
      忘记密码?
        
    友情提示
    2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
    3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
    4、本站资源下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。
    5、试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。

    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语义

    注意事项

    本文(Kafka 多种跨 IDC 灾备方案调研对比.docx)为本站会员(王**)主动上传,优知文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知优知文库(点击联系客服),我们立即给予删除!

    温馨提示:如果因为网速或其他原因下载失败请重新下载,重复下载不扣分。




    关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

    copyright@ 2008-2023 yzwku网站版权所有

    经营许可证编号:宁ICP备2022001189号-2

    本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。优知文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知优知文库网,我们立即给予删除!

    收起
    展开