阿里分布式消息中间件RocketMQ深入解析Word文档格式.docx

阿里分布式消息中间件RocketMQ深入解析Word文档格式.docx

《阿里分布式消息中间件RocketMQ深入解析Word文档格式.docx》由会员分享，可在线阅读，更多相关《阿里分布式消息中间件RocketMQ深入解析Word文档格式.docx（7页珍藏版）》请在冰豆网上搜索。

入驻基金会可以给技术圈哪些启示？

InfoQ带着这样的疑问对两位项目联合创始人进行了专访，内容整理如下。

RocketMQ的由来

谈起RocketMQ的亮点，那不得不先提一下阿里巴巴消息引擎的演进史。

阿里中间件消息引擎发展到今日，前前后后经历了三代演进。

第一代，推模式，数据存储采用关系型数据库。

在这种模式下，消息具有很低的延迟特性，并且很容易支持分布式事务。

尤其在阿里淘宝这种高频交易场景中，具有非常广泛地应用。

典型代表包括Notify、Napoli。

第二代，拉模式，自研的专有消息存储。

在日志处理方面能够媲美Kafka的吞吐性能，但考虑到淘宝的应用场景，尤其是其交易链路的高可靠需求，消息引擎并没有一味的追求吞吐，而是将稳定可靠放在首位。

因为采用了长连接拉模式，在消息的实时方面丝毫不逊推模式。

典型代表MetaQ。

第三代，以拉模式为主，兼有推模式的高性能、低延迟消息引擎RocketMQ，在二代功能特性的基础上，为电商金融领域添加了可靠重试、基于文件存储的分布式事务等特性，并做了大量优化。

从2012年开始，经历了历次双11核心交易链路检验。

目前已经捐赠给Apache基金会。

时至今日，RocketMQ很好的服务了阿里集团大大小小上千个应用，在双11当天，更有不可思议的万亿级消息流转，为集团大中台的稳定发挥了举足轻重的作用。

不难看出，RocketMQ其实是伴随着阿里巴巴整个生态的成长，逐渐衍生出来的高性能、低延迟能够同时满足电商领域和金融领域的极尽苛刻场景的消息中间件。

经历双11洗礼的英雄

2016年双十一，阿里巴巴内部的消息中间件全面拥抱RocketMQ的低延迟存储引擎。

在备战期间，团队重点做了两件事情，优化慢请求与统一存储引擎；

∙优化慢请求：

这里主要是解决在海量高并发场景下降低慢请求对整个集群带来的抖动，毛刺问题。

这是一个极具挑战的技术活，团队同学经过长达1个多月的跟进调优，从双十一的复盘情况来看，99.996%的延迟落在了10ms以内，而99.6%的延迟在1ms以内。

优化主要集中在RocketMQ存储层算法优化、JVM与操作系统调优。

更多的细节大家可以参考我们之前写的电子书章节《万亿级数据洪峰下的分布式消息引擎》[1]。

∙统一存储引擎：

主要解决的消息引擎的高可用，成本问题。

在多代消息引擎共存的前提下，我们对Notify的存储模块进行了全面移植与替换。

基于上述积极的技术准备，在16年双十一期间，阿里集团大约有1.2万亿级的消息流转总量，几乎是15年双十一大促的2倍。

峰值期间，消息生产的吞吐在2000w/s左右，消息消费的吞吐也近乎1500w/s的量级。

整个大促下来，用我们内部的话来说，如丝般顺滑。

RocketMQ的技术概览

在我们看来，它最大的创新点在于能够通过精巧的横向、纵向扩展，不断满足与日俱增的海量消息在高吞吐、高可靠、低延迟方面的要求。

目前RocketMQ主要由NameServer、Broker、Producer以及Consumer四部分构成，如下图所示。

所有的集群都具有水平扩展能力，无单点障碍。

NameServer以轻量级的方式提供服务发现和路由功能，每个NameServer存有全量的路由信息，提供对等的读写服务，支持快速扩缩容。

Broker负责消息存储，以Topic为纬度支持轻量级的队列，单机可以支撑上万队列规模，支持消息推拉模型，具备多副本容错机制（2副本或3副本）、强大的削峰填谷以及上亿级消息堆积能力，同时可严格保证消息的有序性。

除此之外，Broker还提供了同城异地容灾能力，丰富的Metrics统计以及告警机制。

这些都是传统消息系统无法比拟的。

Producer由用户进行分布式部署，消息由Producer通过多种负载均衡模式发送到Broker集群，发送低延时，支持快速失败。

Consumer也由用户部署，支持PUSH和PULL两种消费模式，支持集群消费和广播消息，提供实时的消息订阅机制，满足大多数消费场景。

与其他消息中间件的对比

1、是不是CS架构？

如果需要做同类产品之间的横向对比，我们优先拿下ZeroMQ，ZeroMQ正如其名0MQ，它更像是一个嵌入式的网络类库，一个专注于transports层的通讯组件，而不是传统意义上的CS架构的MQ。

2、实现的哪种规范/协议？

接下来我们来看看RabbitMQ、ActiveMQ、Kafka和RocketMQ之间的一些对比，从设计思路上来看，RabbitMQ是AMQP规范的参考实现，AMQP是一个线路层协议，面面俱到，很系统，也稍显复杂。

目前RabbitMQ已经成为OpenStackIaas平台首选的消息服务，其背后的支持力度不言而喻。

ActiveMQ最初是由红帽子捐赠给Apache的，是JMS规范的参考实现，也是Apache旗下的老牌消息服务引擎。

JMS虽说是一个API级别的协议，但其内部还是定义了一些实现约束，不过缺少多语言支撑。

ActiveMQ的生态堪称丰富多彩，在该Apache顶级项目下，拥有不少子项目，包括由HornetMQ演变而来的Artemis，基于Scala号称下一代AMQ的Apollo等。

3、适用何类场景？

而Kafka最初被设计用来做日志处理，是一个不折不扣的大数据通道，追求高吞吐，存在丢消息的可能。

其背后的研发团队也围绕着Kafka进行了商业包装，目前在一些中小型公司被广泛使用，国内也有不少忠实的拥捧着。

RocketMQ天生为金融互联网领域而生，追求高可靠、高可用、高并发、低延迟，是一个阿里巴巴由内而外成功孕育的典范，除了阿里集团上千个应用外，根据我们不完全统计，国内至少有上百家单位、科研教育机构在使用。

关于这几个MQ产品更详细的特性对比，可以参考我们官网上的说明[2]。

三项技术发力点

（一）消息的顺序

不可否认，顺序消息是RocketMQ功能特性上的一个卖点。

目前我们做到了全局保序。

需要重点说一下，这里的全局是有前提，针对某个唯一标识（能够被Hash成唯一标识），比方说大卖家账号，某类产品的订单等。

其技术实现原理也相对比较简单，保证对通道的单一实例操作，如单进程、单线程写，单进程、线程读，像ActiveMQ的ExclusiveConsumer也是类似的实现。

不难看出，这种实现方式实际是在吞吐上做出了一定牺牲。

另外也带来了另外一个问题-热点。

如双十一当天，如果使用简单的散列策略，像短期内就交易过亿的天猫商家的消息会发送到一个通道里面，造成单通道，甚至单机的热点问题在最新的RocketMQ版本里，我们将会改进目前的实现，借此改善因为顺序导致的单通道热点问题，这个特性预计今年中旬会发布。

（二）消息的去重

消息领域有一个对消息投递的QoS定义，分为：

最多一次（Atmostonce），至少一次（Atleastonce），仅一次（Exactlyonce）。

几乎所有的MQ产品都声称自己做到了Atleastonce。

既然是至少一次，那避免不了消息重复，尤其是在分布式网络环境下，而这个缺憾归根结底也可以看做是TCP协议的一部分，如失败重传。

业务上往往对消息重复又很敏感，RocketMQ目前的版本是不支持去重的，我们通常建议用户通过外置全局存储自己做判重处理。

在下一代的特性规划里，我们会内置解决方案。

先说下业界通用做法，像Artemis，IronMQ等，通过在服务端全局存储判重。

这是一个IO敏感的操作，为服务端带来一定的负载。

而RocketMQ则希望通过采取二次判重策略，有效降低服务端IO。

（三）分布式的攻坚战

首先明确分布式系统这个概念：

分布式系统是由一系列分散自治组件通过互联网并行并发协作，从而组成的一个coherent软件系统。

它具备资源共享，并行并发，可靠容错，透明开放等特性。

像CAP，BASE，Paxos，事务等一起构成了分布式基础理论。

这里我们再来重温下CAP理论：

CAP分别代表一致性（Consistency），可用性（Availability），分区容忍性（Partitiontolerance）。

一致性，EricBrewer（CAP理论提出者）用一个服务要么被执行，要么不被执行来定义（原文：

Aservicethatisconsistentoperatesfullyornotatall）。

请注意，这里的一致性是有别于数据库ACID属性中的C，数据库层面的C指的是数据的操作不能破坏数据之间的完整性约束，如外键约束。

在分布式环境中，可以把C简单理解为多节点看到的是数据单一或者同一副本。

可用性，意味着服务是可用的（原文：

theserviceisavailable（tooperatefullyornotasabove））。

可用性又可以细分为写可用和读可用。

在分布式环境中，往往指的是系统在确定时间内可返回读写操作结果，也即读写均可用。

分区容忍性，除了整个网络故障外（如光纤被掘断），其它故障（如丢包、乱序、抖动、甚至是网络分区节点crash）都不能导致整个系统无法正确响应（原文：

Nosetoffailureslessthantotalnetworkfailureisallowedtocausethesystemtorespondincorrectly）。

CAP理论可以看做是探索适合不同应用的一致性与可用性平衡问题。

∙没有分区的情况：

可以同时满足C与A，以及完整的ACID事务支持。

可以选择牺牲一定的C，获得更好的性能与扩展性。

∙分区的情况：

选择A（集中关注分区的恢复），需要有分区开始前、进行中、恢复后的处理策略，应用合适的补偿处理机制。

像RocketMQ这样的分布式消息引擎，更多的追求AP。

再强的系统也一定有容量底线，足够的容量是可用性的有效前提。

通常情况下，会通过降级、限流、熔断机制来保障洪峰下的可用性。

具体的技术细节可以参看电子书章节[1]

另外，考虑到在金融高频交易典型场景，我们也为RocketMQ设计了CP机制，在满足分布式系统的分区容错性的前提下，牺牲系统可用性来保证数据的一致性。

而技术实现上，则基于Zab一致性协议，利用分布式锁和通知机制，以此来保障多副本数据的一致性。

开源捐赠和社区运营

目前国内外有很多公司会把一些通用问题的解决方案，尤其是那些久经考验、愈久弥坚的产品开源出来，以期望在品牌宣传、人才引进方面有所建树。

把RocketMQ开源出来，甚至捐赠给Apache，内部也是经过了深思熟虑，层层审批与讨论，期望能够在生态化、规范化、国际化、商业化方面深耕细作。

开源捐赠的想法实际上始于2014年。

当时，我们甄选了几位Apache社区权威人士，遗憾的是反复沟通不断修改草案之后突然间失去了联系。

2015年，我们有幸结识了KylinPrincipalArchitect蒋旭和VPLuke以及ReadhatPrincipalSoftwareEngineer姜宁，请教了一些Apache禁忌事项，重新活跃起来了捐赠进程。

接下来，最重要的是征集champion候选人，很开心的是ActiveMQVPBruce爽快地接收了我们的邀请，经过前前后后接近100封邮件来往，我们终于正式开启了Apache之旅。

捐赠投票是在双十一当天，我们准备充分很好地回答了评委会的犀利问题。

不过，面对“中国开发者不喜欢邮件沟通”的突然刁难，还要感谢社区华人的防御性声明回应。

经过很多磨难，投票结果总算出来了：

还不算坏，10票赞同，带binding（IPMC成员的有效投票）的+1，无反对票，正式进入孵化期。

孵化成功后有望成为国内首个互联网中间件在Apache上的顶级项目，成为全球继ActiveMQ，Kafka之后，分布式消息引擎家族中的重要成员。

接下来，我们想强调下知识产权这个对大多数工程师来说陌生的领域，尤其是专利权、著作权、商标权。

在国外，每年因为这些问题导致的侵权官司不在少数。

而我们在开源之初，对这块的选择、保护也是极其谨慎，包括开源许可协议的选择、授权方面，代码署名权等，这些都是很好的智力保护，也是我们产品的核心竞争力之一。

尊重知识，尊重产权，才能构建一个和谐积极向上的开源氛围，打造真正的自主知识产权品牌产品。

在Alibaba，我们基于开源引擎的RocketMQ，为云上用户提供了商业化版本的AliwareMQ。

两个产品都是由阿里中间件消息团队出品。

商业版AliwareMQ在支持TCP、HTTP和MQTT协议接入，功能方面增强了运维管控方面，生态集成的能力（包括可视化的消息轨迹、资源报表统计以及监控报警、Kafka集成等）。

它在公有云上本身具备多机房部署同城高可用容灾特性，目的是满足企业级要求。

关于社区的运营，我们采取了和Apache顶级项目基本相似的策略。

首先，必须立足于高质量产品本身，从版本规划开始，我们建立了里程碑讨论，Features设计，编码自测，结对Review，集成测试，Release讨论，Release公告等等一系列规范且高效的软件研发流程。

其次，在社区运营层面，则有一系列与社区互动的活动，如线下meetup、workshop、ApacheCon、不定期的编程马拉松等，吸纳新的Contributor和Committer进来。

新一代RocketMQ，蓄势待发

最近，团队也在着手构建下一代RocketMQ，期望构建一套厂商无关的集线路层、API层于一体的规范，这也是第四代消息引擎最大的亮点。

目前，我们联系了Twitter、Yahoo等公司相关技术负责人，共同起草完善这一规范，而RocketMQ将会是第一批率先成为参考实现的产品。

我们非常期望国内的MQ厂商亦或是分布式爱好者能够参与进来，积极在国际开源社区代表国人发声呐喊。