未来展望 m w a l i b a b a - i n c . c o m ©2016 Alibaba Middleware Group n 历年双11消息数量变化 n 消息中间件核心链路 n 低延迟存储 n 容量保障 n 熔断机制 n 多副本高可用 10亿 百亿 千亿 5千亿+ 万亿+ 历年双11消息数量变化 2012双11 2013双11 2014双11 2015双11 2016双11 消息中间件分布式慢请求解法 01 02 低延迟分布式存储系统 在线熔断机制，秒级隔离 03 容量保障，限流 1.4万亿 低延迟分布式存储系统 – RocketMQ存储 Java Heap Lock Page Cache Disk Request Request Request Request Request Request 万级请求/秒/单机 1.4万亿 低延迟分布式存储系统 – 并发锁的开销 lReentrantLock/synchronized ØFair ØUnfair lLockSupport.unpark/park 1.4万亿 低延迟分布式存储系统 – PageCache真的那么快吗？ 1.4万亿 低延迟分布式存储系统 – PageCache的毛刺现象分析 1.4万亿 低延迟分布式存储系统 – PageCache的毛刺现象分析 lMemory access latency issues: ØDirect

未来展望 m w a l i b a b a - i n c . c o m ©2016 Alibaba Middleware Group n 历年双11消息数量变化 n 消息中间件核心链路 n 低延迟存储 n 容量保障 n 熔断机制 n 多副本高可用 10亿 百亿 千亿 5千亿+ 万亿+ 历年双11消息数量变化 2012双11 2013双11 2014双11 2015双11 2016双11 消息中间件分布式慢请求解法 01 02 低延迟分布式存储系统 在线熔断机制，秒级隔离 03 容量保障，限流 1.4万亿 低延迟分布式存储系统 – RocketMQ存储 Java Heap Lock Page Cache Disk Request Request Request Request Request Request 万级请求/秒/单机 1.4万亿 低延迟分布式存储系统 – 并发锁的开销 lReentrantLock/synchronized ØFair ØUnfair lLockSupport.unpark/park 1.4万亿 低延迟分布式存储系统 – PageCache真的那么快吗？ 1.4万亿 低延迟分布式存储系统 – PageCache的毛刺现象分析 1.4万亿 低延迟分布式存储系统 – PageCache的毛刺现象分析 lMemory access latency issues: ØDirect

来源网站：链滴 许可协议：署名-相同方式共享 4.0 国际 (CC BY-SA 4.0) Apache RocketMQ 介绍 概要 Apache RocketMQ是一个分布式消息传递和流媒体平台，具有低延迟，高性能和可靠性，万亿级容 和灵活的可伸缩性。它的一个重要特性是支持非日志类型的可靠消息传送，非常适合运用在金融和电 商务领域。目前他是Apache社区的顶级项目，在全球有超过100家公司在其业务中使用RocketMQ IO模块遇到了瓶颈，几经努力但改善成果不 。这时正值Kafka流行，于是引起了阿里巴巴开发团队的注意，对kafka的无限消息堆积，高效持久化 度等特性非常赞赏。但不幸的是，Kafka不能满足他们的要求，特别是在低延迟和高可靠性方面。在 种情况下，阿里巴巴决定发明一个新的消息传递引擎来处理更广泛的用例集，从传统的发布/订阅方 到大批量实时零损失容忍交易系统。 里程碑 2012年，阿里巴巴开始开发RocketMQ，经历了数次双11核心交易链路检验。 RocketMQ在社区各方面的努力下，茁壮发展，很多功能都得到了加强。 RocketMQ的技术概览 在我们看来，它最大的创新点在于能够通过精巧的横向、纵向扩展，不断满足与日俱增的海量消息在 吞吐、高可靠、低延迟方面的要求。 目前RocketMQ主要由NameServer、Broker、Producer以及Consumer四部分构成，如下图所示。 原文链接：Apache RocketMQ 介绍 Nam

目前并不支持任意精度的定时消息。所谓的定时消息就是将消 息发送到 Broker，但消费端不会立即消费，而是要到指定延迟时间后才能被消费端消费。 本文来自『中间件兴趣圈』公众号，仅作技术交流，未授权任何商业行为。 17 > 1.1 RocketMQ 核心概念扫盲篇 RocketMQ 目前支持指定级别的延迟，其延迟级别如下： 1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m ，两者之间的消息消费进度如何同步？ 从服务定时同步主服务器进度 如果 Broker 角色为从服务器，会通过定时任务调用 syncAll，从主服务器定时同步 topic 路由信息、消息消费进度、延迟队列处理进度、消费组订阅信息。 那问题来了，如果主服务器启动后，从服务器马上从主服务器同步消息消息进度，那岂 不是又要重新消费？ 其实在绝大部分情况下，就算从服务从主服务器同步了很久之前的消费进度，只要消息 发起查看消费组的 TPS 时，Broker 会 根据过去一分钟内采集的快照数据进行计算。快照信息的采集机制是 broker 端会每 10s 会记录一下消费组对应的拉取消息数量与拉取次数。 那既然消息延迟(堆积数量在不断减少)，说明消费端正在消费，按道理来说，通过上述 机制进行计算，TPS 不可能会是 0？那又是什么原因呢？如果 TPS 为 0，可以说明消费 端并没有向 broker 拉取消息，因为一旦从

容量峰值具有随机性，弹性要求高 • 业务场景复杂、集成要求尽可能简单 • 运维及流量调拨要求高 极简架构 高性能 金融级高可靠 打造业务消息领域首选 零依赖 可扩展 低延迟 高吞吐 强同步刷盘 ACK 机制 普通消息 顺序消息 延迟消息 事务消息 重试消息 死信消息 设计思想： 1.消息不丢、高可靠是架构的基础 2.时延优先，兼顾吞吐 3.收敛业务共性问题，提供丰富的业务消息类型 4 全新 POP 消费模型 服务端负载均衡  消除 Consumer 与 Queue 的 Binding 关 系，一个 Queue 可以由多个消费者消费  无 rebalance ，降低消费延迟概率  集群中某些消费端假死不影响整体消费进度  客户端更加轻量，多语言友好 流批一体  在Streaming场景下，单一消费者消费保证顺 序  在 batch 场景下，无需保证顺序，可以多个

properties & 3. 多 Master 多 Slave 模式，异步复制 每个 Master 配置一个 Slave，有多对 Master-Slave，HA 采用异步复制方式，主备有短暂消息延迟，毫秒级。 优点：即使磁盘损坏，消息丢失的非常少，丏消息实时性丌会叐影响，因为 Master 宕机后，消费者仍然可以 从 Slave 消费，此过程对应用透明。丌需要人工干预。性能同多 Master 每个 Master 配置一个 Slave，有多对 Master-Slave，HA 采用同步双写方式，主备都写成功，吐应用迒回成功。 优点：数据不服务都无单点，Master 宕机情冴下，消息无延迟，服务可用性不数据可用性都非常高 缺点：性能比异步复制模式略低，大约低 10%左史，収送单个消息的 RT 会略高。目前主宕机后，备机丌能自劢 切换为主机，后续会支持自劢切换功能。 ### 兇启劢

java 语言开发的开源的、分布式的消息投递与流数据平台。 最早于 2016 年由阿里巴巴捐献给了 Apache 基金会，2017 年成为 Apache 的 顶级项 目，RocketMQ 具有低延迟，金融级高可用以及厂商中立的特点，目前广泛使用于国内 外的互联网公司。针对 AMAZON WEB SERVICES 客户需要在 AMAZON WEB SERVICES 上 使用 RocketMQ

java 语言开发的开源的、分布式的消息投递与流数据平 台。最早于 2016 年由阿里巴巴捐献给了 Apache 基金会，2017 年成为 Apache 的 顶级项目，RocketMQ 具有低延迟，金融级高可用以及厂商中立的特点，目前广泛使 用于国内外的互联网公司。针对亚马逊云科技客户需要在亚马逊云科技上使用 RocketMQ 的需求，我们开发了一键部署的方案，帮助客户快速的在自己的账号部署

将消息提交到消费消息服务 ConsumeMessageService 流控处理， 如果 pullInterval 参数大于 0 （拉消息间隔，如果为了降低拉取速度， 可以设置大于 0 的值）， 延迟再执行拉消息， 如果 pullInterval 为 0 立刻在执行拉 消息动作 序列图 1. 向 broker 发送长轮询请求