这些年开源氛围越来越好,各大IT公司都纷纷将一些自研代码开源出来。2012年,阿里巴巴开源其自研的第三代分布式消息中间件——RocketMQ。经过几年的技术打磨,阿里称基于RocketMQ技术,目前双十一当天消息容量可达到万亿级。
2016年11月,阿里将RocketMQ捐献给Apache软件基金会,正式成为孵化项目。阿里称会将其打造成顶级项目。这是阿里迈出的一大步,因为加入到开源软件基金会需要经过评审方的考核与观察。坦率而言,业界还对国人的代码开源参与度仍保持着刻板印象;而Apache基金会中的342个项目中,暂时还只有Kylin、CarbonData、Eagle 和 RocketMQ 共计四个中国技术人主导的项目。2017年2月20日,RocketMQ正式发布4.0版本,专家称新版本适用于电商领域,金融领域,大数据领域,兼有物联网领域的编程模型。
RocketMQ项目,究竟用怎样的技术内涵?缘何赢得了基金会的初步认可?入驻基金会可以给技术圈哪些启示?InfoQ带着这样的疑问对两位项目联合创始人进行了专访,内容整理如下。
谈起RocketMQ的亮点,那不得不先提一下阿里巴巴消息引擎的演进史。阿里中间件消息引擎发展到今日,前前后后经历了三代演进。
不难看出,RocketMQ其实是伴随着阿里巴巴整个生态的成长,逐渐衍生出来的高性能、低延迟能够同时满足电商领域和金融领域的极尽苛刻场景的消息中间件。
请配图同时对RocketMQ的架构进行说明;请对消息的产生、传输和消费流程进行说明,最好也可以配图。在我们看来,它最大的创新点在于能够通过精巧的横向、纵向扩展,不断满足与日俱增的海量消息在高吞吐、高可靠、低延迟方面的要求。目前RocketMQ主要由NameServer、Broker、Producer以及Consumer四部分构成,如下图所示。
所有的集群都具有水平扩展能力,无单点障碍。
在备战2016年双十一时,团队重点做了两件事情,优化慢请求与统一存储引擎。
这样下来,阿里巴巴内部的消息中间件就全面拥抱了RocketMQ的低延迟存储引擎。基于上述积极的技术准备,在16年双十一期间,阿里集团大约有1.2万亿级的消息流转总量,几乎是15年双十一大促的2倍。峰值期间,消息生产的吞吐在2000 w/s左右,消息消费的吞吐也近乎1500 w/s的量级。整个大促下来,用我们内部的话来说,如丝般顺滑。
请从技术构思、实践表现和适用场景三个大方向对RocketMQ、RabbitMQ、Kafka、ActiveMQ和ZeroMQ进行对比?除了技术上的较量,可否对这些中间件背后的社区运营、商业案例应用,进行对比呢?
1、是不是CS架构?
如果需要做同类产品之间的横向对比,我们优先拿下ZeroMQ,ZeroMQ正如其名0MQ,它更像是一个嵌入式的网络类库,一个专注于transports层的通讯组件,而不是传统意义上的CS架构的MQ。
2、实现的哪种规范 / 协议?
接下来我们来看看RabbitMQ、ActiveMQ、Kafka和RocketMQ之间的一些对比,从设计思路上来看,RabbitMQ是AMQP规范的参考实现,AMQP是一个线路层协议,面面俱到,很系统,也稍显复杂。目前RabbitMQ已经成为OpenStack Iaas平台首选的消息服务,其背后的支持力度不言而喻。
ActiveMQ最初是由红帽子捐赠给Apache的,是JMS规范的参考实现,也是Apache旗下的老牌消息服务引擎。JMS虽说是一个API级别的协议,但其内部还是定义了一些实现约束,不过缺少多语言支撑。ActiveMQ的生态堪称丰富多彩,在该Apache顶级项目下,拥有不少子项目,包括由HornetMQ演变而来的Artemis,基于Scala号称下一代AMQ的Apollo等。
3、适用何类场景?
而Kafka最初被设计用来做日志处理,是一个不折不扣的大数据通道,追求高吞吐,存在丢消息的可能。其背后的研发团队也围绕着Kafka进行了商业包装,目前在一些中小型公司被广泛使用,国内也有不少忠实的拥捧着。
RocketMQ天生为金融互联网领域而生,追求高可靠、高可用、高并发、低延迟,是一个阿里巴巴由内而外成功孕育的典范,除了阿里集团上千个应用外,根据我们不完全统计,国内至少有上百家单位、科研教育机构在使用。关于这几个MQ产品更详细的特性对比,可以参考我们官网上的说明[2]。
(一)消息的顺序
不可否认,顺序消息是RocketMQ功能特性上的一个卖点。目前我们做到了全局保序。需要重点说一下,这里的全局是有前提,针对某个唯一标识(能够被Hash成唯一标识),比方说大卖家账号,某类产品的订单等。其技术实现原理也相对比较简单,保证对通道的单一实例操作,如单进程、单线程写,单进程、线程读,像ActiveMQ的Exclusive Consumer也是类似的实现。
不难看出,这种实现方式实际是在吞吐上做出了一定牺牲。另外也带来了另外一个问题 - 热点。如双十一当天,如果使用简单的散列策略,像短期内就交易过亿的天猫商家的消息会发送到一个通道里面,造成单通道,甚至单机的热点问题在最新的RocketMQ版本里,我们将会改进目前的实现,借此改善因为顺序导致的单通道热点问题,这个特性预计今年中旬会发布。
(二)消息的去重
消息领域有一个对消息投递的QoS定义,大致可分为:最多一次(At most once),至少一次(At least once),仅一次( Exactly once)。
几乎所有的MQ产品都声称自己做到了At least once。既然是至少一次,那避免不了消息重复,尤其是在分布式网络环境下,而这个缺憾归根结底也可以看做是TCP协议的一部分,如失败重传。业务上往往对消息重复又很敏感,RocketMQ目前的版本是不支持去重的,我们通常建议用户通过外置全局存储自己做判重处理。在下一代的特性规划里,我们会内置解决方案。先说下业界通用做法,像Artemis,IronMQ等,通过在服务端全局存储判重。这是一个IO敏感的操作,为服务端带来一定的负载。而RocketMQ则希望通过采取二次判重策略,有效降低服务端IO。
(三)分布式的挑战
首先明确分布式系统这个概念:分布式系统是由一系列分散自治组件通过互联网并行并发协作,从而组成的一个coherent软件系统。它具备资源共享,并行并发,可靠容错,透明开放等特性。像CAP,BASE,Paxos,事务等一起构成了分布式基础理论。
来源: https://yq.aliyun.com/articles/70526