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整体表现仍有差距，非持久化性能测试不理想。