开源 VS 商业,消息中间件你不知道的那些事

11月23日,新炬网络中间件技术专家刘拓老师在DBA+社群中间件用户组进行了一次主题为“开源 VS 商业,消息中间件你不知道的那些事”的线上分享。小编特别整理出其中精华内容,供大家学习交流。

 

 

嘉宾简介  

 

  • 新炬网络中间件技术专家

  • 曾任职于IBM华南GTS 4年,IBM WebSphere、MQ、CICS产品线技术专家

  • 5年移动运营商(广东移动、浙江移动)运维经验,3年JAVA开发及售后经验

 

演讲实录  

 

随着云计算的兴起,Docker、微服务的流行,分布式消息队列技术成为云计算平台中不可或缺的组件。今天由我来给大家分享下目前市场上主流的商业、开源消息中间件之间的区别。

 

什么是消息中间件MOM(Message Oriented Middleware)利用高效可靠的消息传递机制进行平台无关的数据交流,并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型,它可以在分布式环境下扩展进程间的通信。

 

 

  • 异步:基于存储转发机制的异步通信方式,发送者将消息发送给消息服务器,消息服务器将消息存放在若干队列中,在合适的时候再将消息转发给接收者。

 

  • 松耦合:客户和服务对象的生命周期松耦合,由MOM来保障消息队列及服务,二者的生命周期无需相同,即发送消息的时候接收者不一定运行,接收消息的时候发送者也不一定运行。

 

  • 可靠性:由MOM来保障消息不会因网络连接异常断开、进程异常重启等各种原因导致消息丢失。

 

消息传递模式分为PTP和Pub/Sub两种模式。

 

 

PTP(Point–to-Point)

  • 每条消息只有一个消费者。

  • 发送者和接收者没有时间依赖(no timing dependencies)。

  • 接受者成功接收答复机制。

 

 

Pub/Sub(Publish/Subscribe)

  • 每条消息可以有多个订阅者。

  • 发送者和接受者之间必须同步,客户端只有订阅后才能收到消息。

 

消息中间件有着异步通知、数据复制、日志同步、延迟队列、广播通知五大适用业务场景。

 

  • 异步通知:为面向服务架构(SOA)提供分布式事务支持;保证全局数据一致性。比如订单处理调度通知,订单拆解后发送开通、计费、账处等到期提醒,办理告知短信,订单状态,二次确认等。

  • 数据复制:利用消息中间件将数据从源头复制到多个目的地;满足搜索、离线分析和分表规则变化等需求。如系统间TF数据同步多系统,局数据增量发布等。

  • 日志同步:应用通过可靠异步方式将日志同步到消息中间件;可以对日志做实时或离线分析。如统一日志平台中心日志入库等。

  • 延迟队列:把消息中间件当做可靠的延迟队列;分布式环境下的定时器。如受理订单入库,系统日志入库等高频率DB写入场景。

  • 广播通知:可靠的集群内广播通知;用于通知缓存失效等事件。如产品缓存刷新等。

 

消息协议JMS VS AMQP

 

 

JMS提供了两种消息模型,peer-2-peer(点对点)以及publish-subscribe(发布订阅)模型。在JMS中,消息路由非常简单,由producer和consumer链接到同一个queue(p2p)或者topic(pub/sub)来实现消息的路由。JMSconsumer同时支持message selector(消息选择器,通过消息选择器,consumer可以只消费那些通过了selector筛选的消息。

 

 

AMQP是一种协议,更准确的说是一种binary wire-level protocol(链接协议)。这是其和JMS的本质差别。AMQP不从API层进行限定,而是直接定义网络交换的数据格式。这使得实现了AMQP的provider天然性就是跨平台的。

 

在AMQP中,消息路由(messagerouting)和JMS存在一些差别,在AMQP中增加了Exchange和binding的角色。producer将消息发送给Exchange,binding决定Exchange的消息应该发送到那个queue,而consumer直接从queue中消费消息。queue和exchang的bind有consumer来决定。

 

市场上目前主流的消息中间件有IBM MQ、WebLogic JMS、ActiveMQ、Rabbit MQ、Rocket MQ、Apollo等。

 

  • IBM  MQ:WebSphere MQ是IBM业务集成基础性产品,以其独特的安全机制、简便快速的编程风格、高稳定性、可扩展性和跨平台性,以及强大的事务处理能力和消息通讯能力,成为业界市场占有率最高的消息中间件产品。

  • WebLogic JMS:WebLogic JMS是Oracle公司一个高性能、集群的Messaging Server,基于WebLogic产品,支持数据库和文件持久化,完全支持XA事务。

  • RocketMQ:RocketMQ是阿里开源的分布式、队列模型的消息中间件,支持严格的消息顺序;支持Topic与Queue两种模式;亿级消息堆积能力;比较友好的分布式特性;同时支持Push与Pull方式消费消息。

  • ActiveMQ:ActiveMQ是目前市场上非常流行的开源消息传递和集成服务器。它的消息传递速度非常快,支持多种跨平台的客户端和协议,非常容易构建企业级的集成模式,同时支持JMS1.1和J2EE1.4规范。ActiveMQ基于Apache2.0许可。

  • Apollo:Apollo是以ActiveMQ原型为基础,是一个更快、更可靠、更易于维护的消息代理工具,Apache称Apollo为最快、最强健的STOMP(Streaming Text Orientated Message Protocol,流文本定向消息协议)服务器。

  • RabbitMQ:RabbitMQ是AQMP协议用Erlang实现的消息队列产品,它实现了代理(Broker)架构,消息在发送到客户端之前可以在中央节点上排队。此特性使得RabbitMQ易于使用和部署,适宜于很多场景如路由、负载均衡或消息持久化等。

 

 

这是某团队各产品功能和性能对比的最终结果,从结果来看:

 

ActiveMQ各功能模块相对完善,不支持集群控制台管理,在订阅模式性能测试(10K及以下消息大小)领先其他产品。

 

IBM WMQ有最完善的功能点实现,在点对点模式读写混合性能测试中领先其他产品。

 

Oracle JMS是Weblogic的组件,非独立产品,各功能模块相对完善,在点对点模式纯读取性能测试中领先其他产品,不支持AMQP消息协议。

 

RabbitMQ有独特的镜像队列功能,能支持分布式内存复制实现持久化,在分布式扩展方面相对有优势,控制台实现性能监控非常丰富。

 

RocketMQ功能模块支持较差,实现的消息协议是自定义的文本传输协议,在1M消息大小的性能测试中领先其他产品。

 

Apollo产品成熟度不够,不支持集群模式(消息路由)。

 

 

商业产品中IBM WMQ产品成熟度高,实现功能完整,应用广泛,兼容性强,跨平台和跨语言支持较好;Oracle JMS是基于WebLogic的一个组件,仅支持JMS和WebLogic T3消息协议,不支持AMQP协议,跨平台支持有待完善。开源产品中ActiveMQ最成熟、功能最完善。

 

基本功能专题分析

 

  • 总体来看,各产品在C/C++语言客户端API、消息优先级实现相对较好。

  • RocketMQ不支持用户名和密码认证、死信机制、消息有效期功能。

 

 

基本功能——语言和协议支持

 

 

基本功能——用户名密码认证:主要通过新建用户名和密码,使用JMS客户端进行连接尝试,实现用户名密码不一致的情况是否允许连接。

 

  • IBM WMQ由队列管理器、队列、通道各部分组成,可通过界面对每个组成部分都进行访问控制。

  • Oracle JMS消息队列基于AdminServer实例,可通过界面添加用户,指定JMS消息队列的访问控制。

  • RabbitMQ是根据业务划分不同的virtual hosts进行访问控制。

  • RocketMQ不支持用户名密码认证。

  • ActiveMQ / Apollo支持主题和队列两种模式的访问控制。

 

基本功能——死信机制:主要通过测试消息在传递失败或消息过期时是否可以标记为死信。

 

  • IBM WMQ、Oracle JMS、RabbitMQ、ActiveMQ均支持读取异常、消息过期两种死信机制。

  • RocketMQ不支持消息死信机制。

  • Apollo只支持消息过期模式,可设置redelivered参数,当超过maximumRedeliveries(缺省为6次)次数时,消息会放入死信队列。

 

基本功能——消息有效期:主要通过在JMS客户端设置消息生存时间,在生存时间结束后启动消费者,消息是否被丢弃或销毁。

 

  • 除RocketMQ之外的产品均支持消息有效期配置。

  • RabbiMQ消息有效期最长保留时间为2^32-1毫秒。

  • RocketMQ支持队列有效期设置,当磁盘空间不够时会删除创建时间最久的持久化文件。

 

基本功能——消息优先级:主要通过在JMS客户端发送一组消息,是否可配置消息的优先级,是否可按消息的优先级进行处理。

 

  • IBM WMQ、Oracle JMS、ActiveMQ、Apollo均支持消息优先级和队列优先级配置。

  • RabbitMQ、RocketMQ不支持消息优先级配置,只支持队列优先级配置,即配置一个优先级高的队列,和一个普通优先级的队列,将优先级不同的消息发往不同队列进行处理。

 

运维管理专题分析

 

  • 总体来看,各产品在运维管理模块实现都较为完善,没有明显短板。

  • 商业产品在管理工具和日志系统相对较为完善。

  • RabbitMQ监控系统的功能实现更为丰富。

 

 

运维管理——管理工具:在管理界面测试是否可以进行队列的创建、删除、启动等基本功能。

 

  • 商业产品在管理界面上支持较为完善,能通过管理界面进行队列的创建、删除及队列的启停等动作。

  • 开源产品在管理界面上只支持队列的创建、删除,不支持队列的启停等动作。

  • IBM WMQ、Oracle有完善的配置文件、命令行、接口支持。

  • RabbitMQ、RocketMQ管理界面不支持队列的启停,可通过命令行、接口实现,支持Rest API接口。

  • ActvieMQ / Apollo管理界面除不支持队列的启停外,不支持集中化管理,通过JMX配置文件实现,支持Rest API接口。

 

运维管理——日志系统:可以修改实例的日志级别,使其可以记录系统的重要事件,比如新的入站连接、新消息入站等。

 

  • 商业产品在日志系统上做得最为完善,日志配置也比较简单。

  • 开源产品在消息可见性、日志分割支持力度不够。

  • RabbitMQ基于AMQP协议,不支持第三方Log4j的日志打印实现。

  • RocketMQ不支持TRACE日志跟踪。

 

运维管理——监控系统:可监控消息中间件运行状态,可监控到集群内所有节点队列数、队列中消息数、出入队消息数、连接数等。

 

  • RabbitMQ在监控系统模块表现最为优秀,集群性能、队列性能、消息发送次数、持久化大小、TPS性能等均有丰富的实现。

  • RocketMQ不支持队列内存占用和持久化大小的实现。

  • IBM MQ、Oracle JMS不支持队列内存占用、持久化大小、TPS性能的实现。

  • ActiveMQ / Apollo仅支持单个队列的控制台实现,但对单个队列的监控实现较为丰富,不支持TPS性能的实现。

 

集群功能、事务支持、高可用、稳定性专题分析

 

  • 除Apollo外各产品均能较好的实现集群所需功能。

  • Apollo不支持集群功能(消息路由),能通过配置文件实现水平扩展,能通过failover协议实现负载均衡。

  • RabbitMQ需通过第三方软件HAProxy来实现负载均衡。

 

 

集群功能:通过配置集群实例,能实现队列的水平扩展、动态扩展,能实现消息的路由和负载均衡。

 

  • 除Apollo外各产品均能较好的实现集群所需功能。

  • Apollo不支持集群功能(消息路由),能通过配置文件实现水平扩展,能通过failover协议实现负载均衡。

  • RabbitMQ需通过第三方软件HAProxy来实现负载均衡。

 

事务支持:通过应用程序测试是否支持本地事务的commit、rollback等机制。

 

  • 所有产品均能较好的实现本地事务支持功能,包括事务提交、事务回滚等。

  • RabbitMQ需购买商业JMS客户端实现。

  • Rocket采用自定义文本协议实现事务提交、回滚等功能。

 

高可用:通过测试当队列服务器出现故障或者网络故障时,客户端可以自动连接到其他队列,保持业务的不间断。

 

  • 所有产品均能实现FAILOVER机制,RabbitMQ需通过HAProxy来实现FAILOVER。

  • 仅RabbitMQ能实现消息的无持久化内存复制。

  • IBM WMQ、RabbitMQ、RocketMQ、ActiveMQ能实现Master-Slave模式高可用。

 

稳定性:通过持续发送消息,主机CPU在60%以上压力下,消息中间件运行情况。

 

  • 各产品均表现出良好的稳定性,在连续12小时高并发测试情况下,均能保持100%的消息处理正确率。

 

 

扩展功能专题分析

 

  • 各产品在文件传输功能、事件消息机制、网络限流方面均能较好的实现。

  • RabbitMQ文件传输、大文件传输、交易一致性、延迟队列功能需购买JMS客户端实现。

  • RocketMQ不支持大文件传输。

  • Apollo不支持续传重传、延迟队列功能。

 

 

文件传输功能:通过测试服务器之间的文件传输,统计数据发送和接收正确率,检验是否有文件丢失或重复。

 

  • 所有产品均能实现文件传输功能。商业产品本身支持文件传输功能,开源产品需通过应用程序实现。

  • RabbitMQ文件传输功能需购买JMS客户端实现。

 

事件消息机制功能:通过在测试时,人为进行网络断连等异常事件,在出现异常事件后消息节点会收到异常事件信息。

 

  • 所有产品均能实现事件消息机制功能。

  • IBM WMQ支持各种事件的配置是否启用,如权限事件、禁止事件、本地事件等等。

 

网络限流功能:通过调整消息中间件的配置参数,测试允许使用的网络带宽,进行数据传输,检查限流功能。

 

  • IBM WMQ对网络限流支持较为全面,能通过消息大小限制、批次传输限制、消息总量限制、内存使用限制、磁盘使用限制等各种配置实现对网络限流功能。

  • Oracle JMS可通过消息大小限制、消息总量限制实现对网络限流功能。

  • RabbitMQ支持通过对内存使用限制、磁盘使用限制实现对网络限流功能。

  • RocketMQ支持通过消息大小限制实现网络限流功能。

  • ActiveMQ支持通过内存使用限制实现网络限流功能。

  • Apollo支持通过消息总量限制实现网络限流功能。

 

 

续传重传功能:通过人为断开网络来测试消息中间件的断点续传能力,统计数据发送和接收正确率,检查是否有数据丢失或重复。

 

  • 除Apollo之外的产品均支持续传重传功能。

  • Apollo不支持ConnectionControl command处理,不能实现自动重连,所以不支持重传功能。预计在Apollo1.8版本中实现该特性。

 

大文件传输效率:通过进行大文件传输测试消息中间件对大文件传输的支持程度。

 

  • IBM WMQ、Oracle JMS、ActiveMQ、Apollo支持大文件传输。

  • RabbitMQ需购买JMS客户端实现。

  • RocketMQ不支持大文件传输。

 

 

交易一致性:通过验证消息中间件是否支持交易最终一致性。

 

  • 除Rocket之外的产品均支持交易一致性功能。

  • RabbitMQ需购买JMS客户端实现。

  • 开源版RocketMQ不支持分布式事物,商业版ONS支持。

 

延迟队列:通过应用程序设置消息延时时间,在延时时间后消息是否被丢弃或销毁,无法被处理。

 

  • 除Apollo之外各产品均支持延迟队列功能。

  • RabbitMQ需购买JMS客户端实现。

 

总体性能测试结果

 

  • 各产品在水平扩展性能测试方面,均有优秀的表现。

  • 点对点性能测试方面,RabbitMQ、Oracle JMS表现尚可,ActiveMQ、IBM WMQ、RocketMQ略有不足,Apollo差距较大。

  • 订阅性能测试方面,ActiveMQ一枝独秀,表现优秀,RocketMQ、IBM WMQ表现尚可,Oracle JMS、Apollo仍有差距,RabbitMQ差距较大。

 

 

水平扩展专题分析:通过两节点、四节点配置进行消息大小1KB、持久化、读写混合的性能测试,得出水平扩展的数据。

 

  • 从各产品的水平扩展能力来看,RabbitMQ和Rocket的处理能力明显优于其他产品。2节点的处理能力,RabbiMQ和RocketMQ优势较为明显。

 

 

点对点性能测试专题分析:通过进行点对点模式,分1K、2K、10K、1M四种消息大小、对8个队列组成的集群进行性能测试。

 

  • IBM WMQ在读写混合性能测试中表现优秀,纯写入性能测试表现不理想。

  • Oracle JMS在纯读取性能测试中表现优秀,纯写入性能测试表现不理想。

  • RabbitMQ在持久化方面支持内存复制模式,在纯写入性能测试表现优秀,纯读取性能测试不理想。

  • RocketMQ不支持非持久化,纯读取性能测试表现优秀,纯写入性能测试不理想。

  • ActiveMQ在混合性能测试中表现优秀,纯写入性能测试表现良好,纯读取性能测试表现不理想。

  • Apollo整体表现较差,仅在非持久化纯写入和纯读取性能测试表现尚可。

 

 

订阅性能测试专题分析:通过进行订阅模式,分1K、2K、10K、1M四种消息大小、对8个队列组成的集群进行性能测试。

 

  • ActiveMQ整体表现非常优秀,无论是非持久化还是持久化。

  • RocketMQ不支持非持久化,持久化方面整体有着较好的表现。

  • IBM WMQ整体表现均衡,读写混合性能测试中表现稍好。

  • Oracle JMS整体表现均衡,在非持久化读写混合性能测试表现优秀。

  • Apollo整体表现一般,读写混合性能测试表现较好。

  • RabbitMQ整体表现仍有差距,非持久化性能测试不理想。

posted on 2016-04-27 17:35 舒润 阅读(...) 评论(...) 编辑 收藏

导航

统计