责异步消费。  Push Consumer Consumer 的一种，应用通常吐 Consumer 对象注册一个 Listener 接口，一旦收到消息，Consumer 对象立 刻回调 Listener 接口方法。  Pull Consumer Consumer 的一种，应用通常主劢调用 Consumer 的拉消息方法从 Broker 拉消息，主劢权由应用控制。  com/alibaba/RocketMQ 7 4.8 At least Once 是挃每个消息必须投递一次 RocketMQ Consumer 兇 pull 消息到本地，消费完成后，才吐服务器迒回 ack，如果没有消费一定丌会 ack 消息， 所以 RocketMQ 可以很好的支持此特性。 4.9 Exactly Only Once (1). 収送消息阶段，丌允许収送重复的消息。 通常大小有限，如果 Buffer 满 了以后怎举办？ 下面是 CORBA Notification 规范中处理方式： (1). RejectNewEvents 拒绝新来的消息，吐 Producer 迒回 RejectNewEvents 错诨码。 (2). 挄照特定策略丢弃已有消息 a) AnyOrder - Any event may be discarded on overflow. This

1.2 生产环境中，autoCreateTopicEnable 为什么不能设置为 true 18 1.3 实战：RocketMQ 学习环境搭建指南篇 28 1.4 RocketMQ HA 核心工作机制 39 1.5 踩坑记：rocketmq-console 消费 TPS 为 0，但消息积压数却在降低是个什么 “鬼” 49 1.6 RocketMQ 一个新的消费组初次启动时从何处开始消费呢？ 64 有了新的称号，那就得更加努力，朝着优秀努力，在 2019 年我又陆续发表了 20 几篇 关于 RocketMQ 相关的文章，这些文章含金量极高，不仅及时跟进了 RocketMQ4.3.0 之后的新特性：消息轨迹、ACL、主从切换等机制，更是发表了数篇实战类文章，详细指 出在生产环境下一些使用误区，更是输出了几篇生产环境真实故障与解决方案。最终于 20 19 年 RocketMQ 官方社区授予我优秀布道师荣誉称号。 RocketMQ 的路由信息，持久化 Topic 路由信息 的地方是在 Broker 中，即${ ROCKETMQ_HOME}/store/config/topics.json。 在 RocketMQ4.5.0 版本后引入了多副本机制，即一个复制组（m-s）可以演变为基 于 raft 协议的复制组，复制组内部使用 raft 协议保证 broker 节点数据的强一致性，该部署 架构在金融行业用的比较多。 二、消息订阅模型 在

group）定时发送到， brokerAddrTable 集合中列出的 broker 上去 Producer 发送消息只发送到 master 的 broker 机器，在通过 broker 的主从复制机制拷贝到 broker 的 slave 上去 二：Producer 如何发送消息 Producer 轮询某 topic 下的所有队列的方式来实现发送方的负载均衡 commitLog 中消息偏移量。Prepared 状态消息不被消费 发送消息 ok，执行本地事物分支， 本地事物方法需要实现 rocketmq 的回调接口 2）2） 2) LocalTransactionExecuter ， 处 理 本 地 事 物 逻 辑 返 回 处 理 的 事 物 状 态 LocalTransactionState 3) 二阶段，处理完本地事物中业务得到事物状态， 根据 offset 2.2.4 事物回查 定时回查线程会定时扫描（默认每分钟）每个存储事务状态的表格文件， 遍历存储事 务状态的表格记录 如果是已经提交或者回滚的消息调过过， 如果是 prepared 状态的如果消息小于事务回查至少间隔时间（默认是一分钟）跳出终 止遍历 调 transactionCheckExecuter.gotocheck 方法向 producer 回查事物状态， 根据

先执⾏行行本地事务还是先发送消息？ 交易易型分布式事务的 RocketMQ使⽤用场景 分布式事务解决⽅方案 半消息 远程事务 特点： 1. 稳定，⽀支持⾼高并发 2. 回查机制可靠易易⽤用 3. 不不引⼊入额外的依赖 注意：回查⽅方法需要幂等 Broker 实现细节 Producer with PID TransactionListener executeLocalTransaction() Check Operation Topic: commit/rollback message Broker Producer with PID Broker到Producer的回查通信 Netty Remoting Server Netty Remoting Client TransactionListener executeLocalTransaction()

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 用户请求 交易 交易 不超过20ms 3. 每条消息发布平均响应时间 不超过3ms 1.4万亿 分布式慢请求带来的挑战 1.4万亿 消息中间件分布式慢请求解法 01 02 低延迟分布式存储系统 在线熔断机制，秒级隔离 03 容量保障，限流 1.4万亿 低延迟分布式存储系统 – RocketMQ存储 Java Heap Lock Page Cache Disk Request Request 写入数据平均响应时间不超过1ms 写入数据最大响应时间不超过20ms（Java GC暂停线程引起） 1.4万亿 双十一当天高可用要求 ~~ 100% 低延迟的分布式存储系统 在线熔断机制 完善的容量评估 SLA=99.999% 1.4万亿 在线熔断机制 ①消息服务器 ②消息服务器 ③消息服务器 ④消息服务器 应用 规则 1. 最多只能隔离 30%的机器。 2. 响应时间过长， 开始隔离1分钟 3

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 用户请求 交易 交易 不超过20ms 3. 每条消息发布平均响应时间 不超过3ms 1.4万亿 分布式慢请求带来的挑战 1.4万亿 消息中间件分布式慢请求解法 01 02 低延迟分布式存储系统 在线熔断机制，秒级隔离 03 容量保障，限流 1.4万亿 低延迟分布式存储系统 – RocketMQ存储 Java Heap Lock Page Cache Disk Request Request 写入数据平均响应时间不超过1ms 写入数据最大响应时间不超过20ms（Java GC暂停线程引起） 1.4万亿 双十一当天高可用要求 ~~ 100% 低延迟的分布式存储系统 在线熔断机制 完善的容量评估 SLA=99.999% 1.4万亿 在线熔断机制 ①消息服务器 ②消息服务器 ③消息服务器 ④消息服务器 应用 规则 1. 最多只能隔离 30%的机器。 2. 响应时间过长， 开始隔离1分钟 3

ameServer存有全量的路由信息，提 对等的读写服务，支持快速扩缩容。 Broker负责消息存储，以Topic为纬度支持轻量级的队列，单机可以支撑上万队列规模，支持消息推 模型，具备多副本容错机制（2副本或3副本）、强大的削峰填谷以及上亿级消息堆积能力，同时可严 保证消息的有序性。除此之外，Broker还提供了同城异地容灾能力，丰富的Metrics统计以及告警机 。这些都是传统消息系统无法比拟的。 Producer通过多种负载均衡模式发送到Broker集群，发送 延时，支持快速失败。 Consumer也由用户部署，支持PUSH和PULL两种消费模式，支持集群消费和广播消息，提供实时的 息订阅机制，满足大多数消费场景。 特点 ● RocketMQ支持异步实时刷盘，同步刷盘，同步复制，异步复制。具有高可靠性。不会因为操作系 的崩溃而导致数据丢失。 ● RocketMQ经过一系列的实践和优化，处理速度从最初的10

容量峰值具有随机性，弹性要求高 • 业务场景复杂、集成要求尽可能简单 • 运维及流量调拨要求高 极简架构 高性能 金融级高可靠 打造业务消息领域首选 零依赖 可扩展 低延迟 高吞吐 强同步刷盘 ACK 机制 普通消息 顺序消息 延迟消息 事务消息 重试消息 死信消息 设计思想： 1.消息不丢、高可靠是架构的基础 2.时延优先，兼顾吞吐 3.收敛业务共性问题，提供丰富的业务消息类型 4.注重可运维性、弹性扩缩、流量调拨能力建设