c o m ©2016 Alibaba Middleware Group 阿里消息中间件演变历史 2016 2007 2010 2011 2012 2015 Notify 五彩石项目 交易核心消息流转 Napoli ActiveMQ内核 B2B大规模使用 MetaQ v1.0 顺序消息 海量堆积能力 Aliware MQ v1.0 Notify v3.0 MetaQ RocketMQ Notify Aliware MQ 有序消息，Pull模式， 海量消息堆积能力 阿里云售卖的消息中间件， 支持公有云，金融云，私 有云，聚石塔 事务消息，Push模式， 交易核心消息分发 阿里消息中间件现状 CONTENTS 01 02 03 阿里消息中间件的演变历史 双11万亿级数据洪峰的挑战 Apache RocketMQ 未来展望 m w a l i 2012双11 2013双11 2014双11 2015双11 2016双11 用户请求 交易 交易 易 用户请求 易 购物车 易 用户请求 红包火山 Notify+MetaQ Notify+MetaQ Notify+MetaQ 几十万条/秒 菜鸟蓄洪 天猫满返 交易买卖家 BCP 交易安全 钉钉 淘客 航旅 发布消息峰值：数千万条/秒 订阅消息峰值：数千万条/秒

c o m ©2016 Alibaba Middleware Group 阿里消息中间件演变历史 2016 2007 2010 2011 2012 2015 Notify 五彩石项目 交易核心消息流转 Napoli ActiveMQ内核 B2B大规模使用 MetaQ v1.0 顺序消息 海量堆积能力 Aliware MQ v1.0 Notify v3.0 MetaQ RocketMQ Notify Aliware MQ 有序消息，Pull模式， 海量消息堆积能力 阿里云售卖的消息中间件， 支持公有云，金融云，私 有云，聚石塔 事务消息，Push模式， 交易核心消息分发 阿里消息中间件现状 CONTENTS 01 02 03 阿里消息中间件的演变历史 双11万亿级数据洪峰的挑战 Apache RocketMQ 未来展望 m w a l i 2012双11 2013双11 2014双11 2015双11 2016双11 用户请求 交易 交易 易 用户请求 易 购物车 易 用户请求 红包火山 Notify+MetaQ Notify+MetaQ Notify+MetaQ 几十万条/秒 菜鸟蓄洪 天猫满返 交易买卖家 BCP 交易安全 钉钉 淘客 航旅 发布消息峰值：数千万条/秒 订阅消息峰值：数千万条/秒

systems�� RocketMQ 5.0 Cloud-native, computing storage separating architecture� 典型应⽤用场景 ⾦金金融交易易 电⼦子商务 智能制造 分布式事务 异步解耦 IoT/IIoT 决策分析 实时计算 概念模型 Broker A Producer A Topic A Broker B Topic transaction first ? Member service Account service Send message Receive message 先执⾏行行本地事务还是先发送消息？ 交易易型分布式事务的 RocketMQ使⽤用场景 分布式事务解决⽅方案 半消息 远程事务 特点： 1. 稳定，⽀支持⾼高并发 2. 回查机制可靠易易⽤用 3. 不不引⼊入额外的依赖 注意：回查⽅方法需要幂等

要求，特别是在低延迟和高可靠性方面。在 种情况下，阿里巴巴决定发明一个新的消息传递引擎来处理更广泛的用例集，从传统的发布/订阅方 到大批量实时零损失容忍交易系统。 里程碑 2012年，阿里巴巴开始开发RocketMQ，经历了数次双11核心交易链路检验。 2016年11月11日，RocketMQ又一次在阿里巴巴全球购物节上处理了1.2万亿个并发在线消息传输， 后阿里巴巴将RocketMQ捐献给Apache

普通顺序消息 顺序消息的一种，正常情冴下可以保证完全的顺序消息，但是一旦収生通信异常，Broker 重启，由亍队列 总数収生发化，哈希叏模后定位的队列会发化，产生短暂的消息顺序丌一致。 如果业务能容忍在集群异常情冴（如某个 Broker 宕机戒者重启）下，消息短暂的乱序，使用普通顺序方 式比较合适。  严格顺序消息 顺序消息的一种，无论正常异常情冴都能保证顺序，但是牺牲了分布式 Kafka 的持丽化方式，充分利用 Linux 文件系统内存 cache 来提高性能。 4.6 Message Reliablity 影响消息可靠性的几种情冴： (1). Broker 正常关闭 (2). Broker 异常 Crash (3). OS Crash (4). 机器掉电，但是能立即恢复供电情冴。 (5). 机器无法开机（可能是 cpu、主板、内存等关键设备损坏） 统环 境下，丌可避免要产生巨大的开销。所以 RocketMQ 为了追求高性能，幵丌保证此特性，要求在业务上迕行去重， 也就是说消费消息要做到幂等性。RocketMQ 虽然丌能严格保证丌重复，但是正常情冴下很少会出现重复収送、消 费情冴，只有网络异常，Consumer 启停等异常情冴下会出现消息重复。 此问题的本质原因是网络调用存在丌确定性，即既丌成功也丌失败的第三种状态，所以才产生了消息重复性问

tranStateTable 事物状态表， 加载本地 tranStateTable 文件 recover: 正常恢复： 利用 tranRedoLog 文件的 recover 利用 tranStateTable 文件重建事物状态表 异常恢复： 先按照正常流程恢复 Tran Redo Log commitLog 异常恢复，commitLog 根据 checkpoint 尝试数据恢复 判断是否是正常恢复，系统启动的启动存储服务(DefaultMessageStore)的时候会创 建一个临时文件 abort, 当系统正常关闭的时候会把这个文件删掉 ，这个类似在 linux 下打开 vi 编辑器生成那个临时文件， 所有当这个 abort 文件存在，系统认为是异常恢 复 1） 先按照正常流程恢复 Consume Queue 为什么说先正常恢复， 那么异常恢复在哪呢？ 值， 值为 proccessOffset%mapedFileSize 2） 正常恢复 commitLog 文件 步骤跟流程恢复 Consume Queue 判断消息有效， 根据消息的存储格式读取消息到 DispatchRequest 对象， 获取 消息大小值 msgSize 大于 0 正常数据 等于-1 文件读取错误 恢复结束 等于 0 读到文件末尾

)，并且建议从从服务器读取，则 从消息消费组建议当消息消费缓慢时建议的拉取 brokerId，由订阅组配置属性 whichBrok erWhenConsumeSlowly 决定；如果消息消费速度正常，则使用订阅组建议的 brokerId 拉取消息进行消费，默认为主服务器。如果不允许从可读，则固定使用从主拉取。 温馨提示：请注意 broker 服务参数 slaveReadEnable，与订阅组配置信息：which 理内存的 40%，则消息读取则由从服务器来接管，实现消息的读写分离，避免主服务 IO 抖动严重。 那问题来了，主服务器宕机后，从服务器接管消息消费后，那消息消费进度存储在哪里？当 主服务器恢复正常后，消息是从主服务器拉取还是从从服务器拉取？主服务器如何得知最新 的消息消费进度呢？ RocketMQ 消息消费进度管理（集群模式）： 集群模式下消息消费进度存储文件位于服务端${ROCKET 既然集群模式下消息消费进度存储在 Broker 端，当主服务器正常时，消息消费进度文 件存储在主服务器，那提出如下两个问题： 1. 消息消费端在主服务器存活的情况下，会优先向主服务器反馈消息消费进度，那从服务 器是如何同步消息消费进度的。 2. 当主服务器宕机后则消息消费端会向从服务器反馈消息消费进度，此时消息消费进度如 何存储，当主服务器恢复正常后，主服务器如何得知最新的消息消费进度。 为了解开上述两个疑问，我们优先来看一下

客户端更加轻量，多语言友好 流批一体  在Streaming场景下，单一消费者消费保证顺 序  在 batch 场景下，无需保证顺序，可以多个 consumer 加快数据读取速度 你集群是正常的，但我消费就是出问题了，怎么办！？ 无损弹性扩缩 固定分区面临的挑战 • 无切换架构中，主节点宕机，备节点不可写，分区数量减少 • 容量不足，Kafka 分区迁移时，会导致网络风暴，耗时极长

（http://10.0.6.235:8080），你可以通过 EC2 Console 找到 Nameserver 对应的 instance 并查到对应的 ip 地址，如下图 10. 浏览器应该可以正常显⽰部署好的 RocketMQ 的集群，如下图： Page 17 of 18 如何登录 Apache RocketMQ 的 Nameserver 和 Broker

口（http://10.0.6.235:8080），你可以通过 EC2 Console 找到 Nameserver 对应的 instance 并查到对应的 ip 地址，如下图 10. 浏览器应该可以正常显示部署好的 RocketMQ 的集群，如下图： Page 20 of 21 如何登录 Apache RocketMQ 的 Nameserver 和 Broker