淘宝消息中间件技术演变 张乐伟（韩彰） 2013-7-14
消息中间件技术演变 消息系统应用场景及现状 消息系统问题分析 的提出及存在的问题 的产生及相关功能介绍 功能特点
消息系统应用场景 •异步解耦 •排队模型 •流计算 •流控型 •重复消费 •事务消息 •顺序消息 •定时投递 •广播消息
消息系统应用场景 浏览器 http请求 消息 业务层 消息 服务层 消息 DB层
现状 •接入系统500多个 •每天消息量：30多亿接收，100多亿投递 •12年双11 ，消息量5倍 •13年双11 ？ •堆积常发生 •性能需要提升 •接收投递比很多（1:15）
消息系统概述 •基于pub-sub模型消息系统 路由模块 订阅关系subscriber 管理模块4 消息接5 producer 通收模块内部消息消息投 队列递模块 1 3 信2通 层6 信subscriber 层 7 Recover 模块 db存储
存在的问题 •堆积 •堆积的产生：发送方（上游）与接收方（下游）能力不匹配，或者接收方（下游）异常 •堆积对自身的影响：堆积将导致存储数据积压，整个集群性能严重下降。 •堆积对业务方的影响：由于某个或者某几个接收方堆积，将影响其他接收方消息的实时性。 •性能
堆积对业务方影响 •本质 •基于topic的模型，非queue模型，即整个系统共享一 个queue •基 于queue模型消息系统 订阅关系2 管理模块 内部消息 消息接queue2 消息投subscriber 5 收模块 sender 通内部消息递模块 1 34 信 queue1通 层信 6 层 Recover 模块 subscriber db存储
性能 •消息系统特点 •存储+推 送（拉取） •消息存 储时间短 •存储 •Insert •Delete •Update •Select •大部分情况下只是使用了数据库机器的内存 •Mysql是否适合做消息系统的存储？
Innodb特点 •存储模型：B+树 •随机写（分裂，合并） •随机读 •适合于读多，写少 •特别适合于范围查找 •存储类型 •Undolog •Data •数据 •索引 •Redolog •Insert，delete等 •Binlog(可以关闭）
消息系统存储 •顺序写 ？ •顺序读 ？ pro ducerconsumer Server文记录每个 件存储 consumer消息到的位置 •问题： •多个topic，consumer group如何处理 •一对多消息如何处理
存储模型 System A Tconopic1 分区sumer1 1 Topic1 分区2 producer System A consumer2 Topic1 分区3 Topic2 分区1 System B consumer1 Topic2 分区2
整体结构 •基于queue模型消息系统 zk 3 5 consumer1 4 Topic1 分区1 12 Topic1 分区2 producer通消息接 信收模块通 信层Topic2分区1 层 consumer2 Topic2 分区2
推拉模型区别 •推模型优势 •Consumer扩容方便，不受分区数限制 •支持复 杂的过滤（因为订阅关系在server端） •一个分区可以为多个consumer服务，分区数不会是瓶颈 •拉模型优势 •Consumer端控制方便，便于业务方根据自己需要去获取消息 •顺序消息支持方便 •允许长时间消费一条消息
Metaq 特点 •解决问题 •性能 •顺序消息 •不同consumer group互相影响问题 •堆积能力 •内存瓶颈：sendfile
zero-copy 技术 •Read, write User buffer 用户空间 CPU copy 内核空间 Kernel bufferCPU copy Socket buffer DMA copy DMA copy 硬盘驱动网卡引擎 •Sendfile 用户空间 内核空间 DMA copy Kernel buffer Socket buffer Append dscr DMA copy 硬盘驱动网卡引擎
zero-copy 技术 •Mmap, write 用户空间 shared User buffer Kernel buffer Soc内 核空间CPUket buffer opyDMA copy c DMA copy 硬盘驱动网卡引擎 •消息系统中使用优势 •减少上下文切换 •减少jvm内存使用（再也不怕投递比了） •缺点 •需要指定待传输消息在文件中的位置及长度等（即无法将消息反序列化到jvm中进行查找过滤）
存在的问题 •分区瓶颈 •分区数即 可支持消费方集群的规模，与consumer机器数对应 •不同 topic需要不同分区 •性能 •分区数增加（文件数）：顺序写，顺序读----随机写，随机读 •分区数超过30，性能直线下降 •Client复杂 •依赖zk，争抢分区，复杂，经常出各种问题，大量消费者场景无法支持，如forest，6000个消费者。 •过滤 •针对某个topic下的消息过滤比较困难，因为利用了sendfile，无法反序列化到JVM中过滤
存在的问题 •内存 •内存无法 完全利用 •无法获取落 后（等待）的消息数 •由于消息大小不确定，无法获取落后消息数（某些场景下需要）
Metaq •存储模型 System A producer Consumer1 index文件，存 Commitlog,存储消息在System A commitlog中的 Consumer2 储物理消息，所有topic共位置，消息长 享 度，及过滤信息的hashcode
目录结构 Topic A Index file1 分区 Commitlog Index file2 分区 Topic B Index file1 分区 Index file2 分区 •文件目录 •Commitlog，所有topic一个commitlog文件，一个文件1G分割文件 •Index文件，一个topic一个或多个index文件（分区数），不同topic不同index文件，且index文件数（分区数）大于等于consumer机器数
•刷盘模式 •Commitlog同步刷盘，groupcommit方式顺序刷盘 •Index file 异步循环刷盘 •内存模型 •利用m map，映射到pagecache，充分利用内存 •消息读取 •从index file中获取消息的位置，长度信息，然后从commitlog中读取，不需要再到JVM中 •分区数 •单机可以支持上万分区数 •消息过滤 •在index file中对过滤的消息比较hashcode，存在误差 •获取落后（等待）的消息数 •由于index file每条消息定长，所以能计算消息数，及落后消息数 •可以支持消息回溯，用于消费已经消费过的消息
Metaq 数据流动 •消息如何在JVM堆，内存，磁盘上流动 producer Consumer1 Consumer2 拉取消息落后， 1 消息已经不在内存中 JVM 堆 6 4 2 内存 page cache 虚拟内存 3 5 硬盘
metaq 整体结构 nameserver master 分发模块 存储模块 物理producer 通接收存储分区通信模块模块模块 consume 信r 层层 slave 主备存储模块 同步物理模块 存储分区模块模块 接收模块分发 模块
功能特点 •高性能 •支持大量分区 持消息过 •支滤 •支持消息堆积 •消息堆积下会有性能下降 •天然具有限流功能 •顺序消息支持 •Client简化 •分区根据一定的算法分配，同时考虑机房优先，不再依赖于zk的争抢
性能数据 以下表格场景基于这个前提： 1 、CP U 16C ore Intel(R) Xeon(R) CPU L5630 @ 2、Memory 24G 3 、Disk RAID SAS 15000 4、Linux ext4 磁盘类型 刷盘策略 分区数 消息大小 发送耗时 发送消息TPS 订阅消息TPS LOAD IOWAIT NETIN NETOUT RAID SAS 15000 异步 1024 128 万 万 14M 27M RAID SAS 15000 异步 1024 256 5 万 万 3 19M 28M RAID SAS 15000 异步 1024 2k 万 万 69M 75M RAID SAS 15000 异步 1024 4k 5 万 万 4 117M 122M RAID SAS 15000 异步 10240 512 万 万 18M 18M RAID SAS 15000 同步 1024 128 万 万 1 11M 11M RAID SAS 15000 同步 1024 256 3 万 万 3 1 16M 16M RAID SAS 15000 同步 1024 2k 万 万 3 58M 58M RAID SAS 15000 同步 1024 2k 万 万 3 58M 122M RAID SAS 15000 同步 1024 4k 万 万 3 91M 94M RAID SAS 15000 同步 1024 4k 万 万 3 91M 125M RAID SAS 15000 同步 10240 512 7 万 万 16M 16M RAID SAS 15000 同步 1024 4k 65 万 万 5M 7M •堆积压 测 •先堆积500G数据，确保1024个分区全部有consumer拉取，consumer起1024个线程拉取，且全部拉到磁盘上
linux IO调度 •CFQ，noop，deadline，anticipatory •CFQ qquueeuuee11 Cfq insert request RCfq dispatch request queue2 R . . . qquueeuuee1N Red black tree(sorted by sector) Read FIFO list(sorted by time) Write FIFO list(sorted by time) queue1
linux IO调度 •deadline Read RB tree(sorted by sector) Read FIFO list(sorted by time) deadline insert request deadline dispatch request write RB tree (sorted by sector) write FIFO list(sorted by time) •deadline R AID SAS 150 00 同步 1024 4k 万 1万 10 4 25M 45M
功能特点 •支持事务 •最终一致，client需要check接口 •消息实时 性 •推拉结合 •主备同步双写 •主备同时写，写完返回，主写存储，备写失败，用户自己选择。 •主备自动切换 •主不可用，自动切换到备 •定时延迟消息 •单队列并行消费 •消费失败延时重试
淘宝 中间件期待各路英雄加盟！ hanzhang@ 微博：@淘宝韩彰
