版本补充文档 誓嘉 vintage.wang@gmail.com 2013/8/16 3 补充与规范区别 誓嘉 vintage.wang@gmail.com 2014/1/4 4 合并文档 誓嘉 vintage.wang@gmail.com 2014/11/17 5 6 7 项目开源主页：https://github.com/alibaba/RocketMQ 左史，丏删除文件时，磁盘 IO 压力极大，会导致 IO 写入超时。 文件系统局面需要做以下调优措施 文件系统 IO 调度算法需要调整为 deadline，因为 deadline 算法在随机读情冴下，可以合幵读请求为顺序跳跃 方式，从而提高读 IO 吞吏量。 Ext4 文件系统有以下 Bug，请注意 http://blog.donghao.org/2013/03/20/%E4%BF%AE%E5%A4 过滤迕程 2. Consumer 启劢后，会吐 FilterServer 上传一个过滤的 Java 类 3. Consumer 从 FilterServer 拉消息，FilterServer 将请求转収给 Broker，FilterServer 从 Broker 收到消息后，挄照 Consumer 上传的 Java 过滤程序做过滤，过滤完成后迒回给 Consumer。 总结：

....................................................................... 50 3. invokeOnewayImpl 单向请求 ................................................................................... 51 4 scanResponseTable ................................................................... 51 5 processRequestCommand 接收请求处理 .................................................................. 51 6 processResponseCommand 接收响应处理 Broker 根 据 producer 请 求 的 RequestCode.SEND_MESSAGE 选 择 对 应 的 处 理 器 SendMessageProcessor 根据请求消息内容构建消息内部结构 MessageExtBrokerInner 调 DefaultMessageStore 加消息写入 commitlog 2.2 分布式事物消息落地

cQueueNums 默认值为 4，故自动创建的主题，其队列数量默认 为 4。 Step3：发送消息 DefaultMQProducerImpl#sendKernelImpl 在消息发送时的请求报文中，设置默认 topic 名称，消息发送 topic 名称，使用的队列 数量为 DefaultMQProducer#defaultTopicQueueNums，即默认为 4。 Step4：Broker TopicConfigManager 根据 topic 查询路由信息，如果 Broker 端不存在该主题的路由配置(路由信息),此时如果 Broker 中存在默认主题的路由配 置信息，则根据消息发送请求中的队列数量，在 Broker 创建新 Topic 的路由信息。这样 Broker 服务端就会存在主题的路由信息。 在 Broker 端的 topic 配置管理器中存在的路由信息，一会向 Nameserver Master，建立 TCP 连接；  客户端以每隔 5s 的间隔时间向服务端拉取消息，如果是第一次拉取的话，先获取本地 commitlog 文件中最大的偏移量，以该偏移量向服务端拉取消息；  服务端解析请求，并返回一批数据给客户端； 本文来自『中间件兴趣圈』公众号，仅作技术交流，未授权任何商业行为。 1.4 RocketMQ HA 核心工作机制 < 40  客户端收到一批消息后，将消息写入本地

多副本高可用 10亿 百亿 千亿 5千亿+ 万亿+ 历年双11消息数量变化 2012双11 2013双11 2014双11 2015双11 2016双11 用户请求 交易 交易 易 用户请求 易 购物车 易 用户请求 红包火山 Notify+MetaQ Notify+MetaQ Notify+MetaQ 几十万条/秒 菜鸟蓄洪 天猫满返 交易买卖家 BCP 交易安全 消息中间件核心链路 1.4万亿 万亿洪峰下有哪些问题 机器假死 IO Util，Load飙高 磁盘响应慢 消息大量堆积 网卡故障，甚至流量跑满 磁盘损坏 零点之战：发布消息SLA要求100% 慢请求开始大量增加 分布式系统雪崩 容量不足，单机热点 问题的本质： 可用性无限接近100% 可靠性无限接近100% 可用性 > 可靠性 1.4万亿 双十一当天高可用要求 ~~ 100% 141 146 1. 每秒支撑千万级消息发布 2. 每条消息发布最大响应时间 不超过20ms 3. 每条消息发布平均响应时间 不超过3ms 1.4万亿 分布式慢请求带来的挑战 1.4万亿 消息中间件分布式慢请求解法 01 02 低延迟分布式存储系统 在线熔断机制，秒级隔离 03 容量保障，限流 1.4万亿 低延迟分布式存储系统 – RocketMQ存储 Java Heap

多副本高可用 10亿 百亿 千亿 5千亿+ 万亿+ 历年双11消息数量变化 2012双11 2013双11 2014双11 2015双11 2016双11 用户请求 交易 交易 易 用户请求 易 购物车 易 用户请求 红包火山 Notify+MetaQ Notify+MetaQ Notify+MetaQ 几十万条/秒 菜鸟蓄洪 天猫满返 交易买卖家 BCP 交易安全 消息中间件核心链路 1.4万亿 万亿洪峰下有哪些问题 机器假死 IO Util，Load飙高 磁盘响应慢 消息大量堆积 网卡故障，甚至流量跑满 磁盘损坏 零点之战：发布消息SLA要求100% 慢请求开始大量增加 分布式系统雪崩 容量不足，单机热点 问题的本质： 可用性无限接近100% 可靠性无限接近100% 可用性 > 可靠性 1.4万亿 双十一当天高可用要求 ~~ 100% 141 146 1. 每秒支撑千万级消息发布 2. 每条消息发布最大响应时间 不超过20ms 3. 每条消息发布平均响应时间 不超过3ms 1.4万亿 分布式慢请求带来的挑战 1.4万亿 消息中间件分布式慢请求解法 01 02 低延迟分布式存储系统 在线熔断机制，秒级隔离 03 容量保障，限流 1.4万亿 低延迟分布式存储系统 – RocketMQ存储 Java Heap

对弹性的要求开始从物理资源变为逻辑资源 • IaaS 的多样性对应用交付部署提出了更高要求 • 可运维性、可观测性带来了更大挑战 • 多租环境带来了更高的网络及安全隔离要求 • 无限资源 vs 有限成本 • 冗长的请求链路，膨胀的技术栈 ……. 面向失败 松散耦合 基础设施解耦 极致弹性 多场景适应 低成本 高 SLA X 客户价值： X 多场景 云原生时代的挑战 云原生四要素 云原生时代的 RocketMQ