[2] 淘宝消息中间件技术演变

整理文档很辛苦,赏杯茶钱您下走!

免费阅读已结束,点击下载阅读编辑剩下 ...

阅读已结束,您可以下载文档离线阅读编辑

资源描述

淘宝消息中间件技术演变张乐伟(韩彰)2013-7-14消息中间件技术演变消息系统应用场景及现状消息系统问题分析Metaq1.0的提出及存在的问题Metaq2.0的产生及相关功能介绍Metaq3.0功能特点消息系统应用场景•异步解耦•排队模型•流计算•流控型•重复消费•事务消息•顺序消息•定时投递•广播消息消息系统应用场景浏览器业务层服务层DB层http请求消息消息消息现状•接入系统500多个•每天消息量:30多亿接收,100多亿投递•12年双11,消息量5倍•13年双11?•堆积常发生•性能需要提升•接收投递比很多(1:15)消息系统概述producersubscriber通信层消息接收模块消息投递模块内部消息队列通信层db存储Recover模块订阅关系管理模块123465路由模块subscriber•基于pub-sub模型消息系统7存在的问题•堆积•堆积的产生:发送方(上游)与接收方(下游)能力不匹配,或者接收方(下游)异常•堆积对自身的影响:堆积将导致存储数据积压,整个集群性能严重下降。•堆积对业务方的影响:由于某个或者某几个接收方堆积,将影响其他接收方消息的实时性。•性能堆积对业务方影响•本质•基于topic的模型,非queue模型,即整个系统共享一个queue•基于queue模型消息系统sendersubscriber通信层消息接收模块消息投递模块内部消息queue1通信层db存储Recover模块订阅关系管理模块123465subscriber内部消息queue2性能•消息系统特点•存储+推送(拉取)•消息存储时间短•存储•Insert•Delete•Update•Select•大部分情况下只是使用了数据库机器的内存•Mysql是否适合做消息系统的存储?Innodb特点•存储模型:B+树•随机写(分裂,合并)•随机读•适合于读多,写少•特别适合于范围查找•存储类型•Undolog•Data•数据•索引•Redolog•Insert,delete等•Binlog(可以关闭)消息系统存储•顺序写?•顺序读?•问题:•多个topic,consumergroup如何处理•一对多消息如何处理producerconsumerServer文件存储记录每个consumer消息到的位置Topic1分区1Topic1分区2Topic1分区3metaq1.0存储模型producerSystemAconsumer1SystemAconsumer2SystemBconsumer1Topic2分区1Topic2分区2metaq1.0整体结构producer通信层消息接收模块通信层123zk•基于queue模型消息系统consumer1consumer25Topic1分区1Topic1分区2Topic2分区1Topic2分区24推拉模型区别•推模型优势•Consumer扩容方便,不受分区数限制•支持复杂的过滤(因为订阅关系在server端)•一个分区可以为多个consumer服务,分区数不会是瓶颈•拉模型优势•Consumer端控制方便,便于业务方根据自己需要去获取消息•顺序消息支持方便•允许长时间消费一条消息Metaq1.0特点•解决问题•性能•顺序消息•不同consumergroup互相影响问题•堆积能力•内存瓶颈:sendfilezero-copy技术•Read,write•Sendfile硬盘驱动网卡引擎KernelbufferUserbufferSocketbufferDMAcopyDMAcopyCPUcopyCPUcopy用户空间内核空间硬盘驱动网卡引擎KernelbufferSocketbufferDMAcopyDMAcopyAppenddscr用户空间内核空间zero-copy技术•Mmap,write•消息系统中使用优势•减少上下文切换•减少jvm内存使用(再也不怕投递比了)•缺点•需要指定待传输消息在文件中的位置及长度等(即无法将消息反序列化到jvm中进行查找过滤)硬盘驱动网卡引擎KernelbufferUserbufferSocketbufferDMAcopyDMAcopyCPUcopyshared用户空间内核空间metaq1.0存在的问题•分区瓶颈•分区数即可支持消费方集群的规模,与consumer机器数对应•不同topic需要不同分区•性能•分区数增加(文件数):顺序写,顺序读----随机写,随机读•分区数超过30,性能直线下降•Client复杂•依赖zk,争抢分区,复杂,经常出各种问题,大量消费者场景无法支持,如forest,6000个消费者。•过滤•针对某个topic下的消息过滤比较困难,因为利用了sendfile,无法反序列化到JVM中过滤metaq1.0存在的问题•内存•内存无法完全利用•无法获取落后(等待)的消息数•由于消息大小不确定,无法获取落后消息数(某些场景下需要)Metaq2.0•存储模型producerSystemAConsumer1Commitlog,存储物理消息,所有topic共享index文件,存储消息在commitlog中的位置,消息长度,及过滤信息的hashcodeSystemAConsumer2Metaq2.0目录结构CommitlogTopicATopicBIndexfile1分区Indexfile2分区Indexfile1分区Indexfile2分区•文件目录•Commitlog,所有topic一个commitlog文件,一个文件1G分割文件•Index文件,一个topic一个或多个index文件(分区数),不同topic不同index文件,且index文件数(分区数)大于等于consumer机器数metaq2.0•刷盘模式•Commitlog同步刷盘,groupcommit方式顺序刷盘•Indexfile异步循环刷盘•内存模型•利用mmap,映射到pagecache,充分利用内存•消息读取•从indexfile中获取消息的位置,长度信息,然后从commitlog中读取,不需要再到JVM中•分区数•单机可以支持上万分区数•消息过滤•在indexfile中对过滤的消息比较hashcode,存在误差•获取落后(等待)的消息数•由于indexfile每条消息定长,所以能计算消息数,及落后消息数•可以支持消息回溯,用于消费已经消费过的消息Metaq2.0数据流动•消息如何在JVM堆,内存,磁盘上流动producerConsumer1拉取消息落后,消息已经不在内存中Consumer2JVM堆内存pagecache虚拟内存硬盘213456metaq2.0整体结构producerconsumer通信层通信层masterslave接收模块nameserver分区模块分发模块物理存储模块存储模块存储模块物理存储模块分区模块接收模块分发模块主备同步模块metaq2.0功能特点•高性能•支持大量分区•支持消息过滤•支持消息堆积•消息堆积下会有性能下降•天然具有限流功能•顺序消息支持•Client简化•分区根据一定的算法分配,同时考虑机房优先,不再依赖于zk的争抢metaq2.0性能数据以下表格场景基于这个前提:1、CPU16CoreIntel(R)Xeon(R)CPUL5630@2.13GHz2、Memory24G3、DiskRAIDSAS150001.4T4、Linux2.6.32ext4磁盘类型刷盘策略分区数消息大小发送耗时发送消息TPS订阅消息TPSLOADIOWAITNETINNETOUTRAIDSAS15000异步10241284.15.3万5.3万2.70.8314M27MRAIDSAS15000异步102425654.6万4.6万31.2319M28MRAIDSAS15000异步10242k3.663.3万3.3万3.41.5469M75MRAIDSAS15000异步10244k52.9万2.9万42.39117M122MRAIDSAS15000异步102405125.33.6万3.6万3.31.1418M18MRAIDSAS15000同步10241282.93.9万3.9万2.9111M11MRAIDSAS15000同步102425633.8万3.8万3116M16MRAIDSAS15000同步10242k4.312.7万2.7万31.558M58MRAIDSAS15000同步10242k4.312.7万5.8万31.558M122MRAIDSAS15000同步10244k7.52.2万2.2万31.8791M94MRAIDSAS15000同步10244k7.52.2万3.2万31.8791M125MRAIDSAS15000同步1024051272.8万2.8万3.83.416M16MRAIDSAS15000同步10244k650.1万0.15万7.757.45M7M•堆积压测•先堆积500G数据,确保1024个分区全部有consumer拉取,consumer起1024个线程拉取,且全部拉到磁盘上linuxIO调度•CFQ,noop,deadline,anticipatory•CFQqueue1CfqinsertrequestRRCfqdispatchrequestqueue1queue2queue1queueN...Redblacktree(sortedbysector)ReadFIFOlist(sortedbytime)queue1WriteFIFOlist(sortedbytime)linuxIO调度•deadline•deadlinedeadlineinsertrequestdeadlinedispatchrequestReadRBtree(sortedbysector)ReadFIFOlist(sortedbytime)writeRBtree(sortedbysector)writeFIFOlist(sortedbytime)RAIDSAS15000同步10244k5.30.8万1万10425M45Mmetaq3.0功能特点•支持事务•最终一致,client需要check接口•消息实时性•推拉结合•主备同步双写•主备同时写,写完返回,主写存储,备写失败,用户自己选择。•主备自动切换•主不可用,自动切换到备•定时延迟消息•单队列并行消费•消费失败延时重试淘宝中间件期待各路英雄加盟!hanzhang@taobao.com微博:@淘宝韩彰

1 / 30
下载文档,编辑使用

©2015-2020 m.777doc.com 三七文档.

备案号:鲁ICP备2024069028号-1 客服联系 QQ:2149211541

×
保存成功