技术编程|开源 VS 商业，消息中间件你不知道的那些事
新炬网络中间件技术专家刘拓老师在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整体表现一般 ， 读写混合性能测试表现较好 。
【技术编程|开源 VS 商业，消息中间件你不知道的那些事】RabbitMQ整体表现仍有差距 ， 非持久化性能测试不理想 。
推荐阅读
- 科学探索|新技术能快速将海水变成饮用水
- 美将38家华为子公司列入实体清单|美将38家华为子公司列入实体清单，限制它们获得某些“敏感技术”
- 现代迎来技术“爆发”解读第十代索纳塔动力系统
- 栽培技术|发展林下树下黑木耳栽培技术，促进林业生产发展，增加经济收入
- 隐身能力太差，俄军仍采购76架苏57战机，新技术加持或超越F35
- 法制|未成年小伙网上学偷车技术 第一次作案就被抓了
- 美国发射的帕克太阳探测器，为什么不怕热？技术实在太牛
- 小米科技|官方评判小米，始终没有掌握核心技术，依旧是组装公司
- 郓城县召开纺织行业技术交流大会
- 鼎盛网军事|单发命中率达到90%，我国引进法国技术生产一导弹，高原实战逞威