【浅析】：常用消息中间件对比分析—TIBCO Rendezvous、IBM MQ与JMS

常用消息中间件对比分析

或称为“TIBCO RV”产品是一种中间件，它具有发布/订阅(Publish/Subscribe)、基于主题寻址(Subject-Based Addressing) 和自定义数据信息(Self-Describing Data Messages)等专利技术功能，使不同应用平台上的信息在一个共享的虚拟总线Information Bus(TIB)上进行传输交换。这些技术能有效地帮助企业从传统的请求/应答(Request/Reply)模式转到自动数据接受的事件驱动模式(Event-Driven，或称之为Push)。TIBCO RV 有助于在各种应用系统中获取信息和数据，能将异构平台有机地联结起来, 通过以即插即用(Plug &Play) 、位置无关（Location-Independent）和分布式服务（Distributed Services）的方式在WAN 和LAN 间配置系统。并且TIBCO RV 具有认证消息传递(Certified Message Delivery) 、容错(Fault Tolerance) 和分布式队列（Distributed Queue）功能。因为使用TIBCO RV 不用考虑网络的技术细节，而只需专注于企业应用的开发，所以能快速建立和配置一个可伸缩的分布式应用系统。

TIBCO Rendezvous 的优点：

1、 加快应用的开发，减少维护费用

2、 独立于硬件、操作系统、网络和协议平台供应商

3、 动态组件替换:进程可以随时加载、退出、替换，而不影响系统运行

4、 屏蔽网络细节

5、 应用伸缩性高

6、 地址无关，简化增加/改变组件

7、提高分布系统的生命期

 

 

JMS

    全程为：Java Message Service，即：Java消息服务。是一组Java应用程序接口(Java API)，它提供创建、发送、接收、读取消息的服务。由Sun公司和它的合作伙伴设计的JMS API定义了一组公共的应用程序接口和相应语法，使得Java程序能够和其他消息组件进行通信。

      JMS是一种与厂商无关的 API，用来访问消息收发系统。JMS 能够通过消息收发服务（有时称为消息中介程序或路由器）从一个 JMS 客户机向另一个 JML 客户机发送消息。消息是 JMS 中的一种类型对象，由两部分组成：报头和消息主体。报头由路由信息以及有关该消息的元数据组成。消息主体则携带着应用程序的数据或有效负载。根据有效负载的类型来划分，可以将消息分为几种类型，它们分别携带：简单文本 (TextMessage)、可序列化的对象 (ObjectMessage)、属性集合 (MapMessage)、字节流 (BytesMessage)、原始值流 (StreamMessage)，还有无有效负载的消息 (Message)。

      消息收发系统是异步的，也就是说，JMS 客户机可以发送消息而不必等待回应。比较可知，这完全不同于基于 RPC 的（基于远程过程的）系统，如 EJB 1.1、CORBA 和 Java RMI 的引用实现。在 RPC 中，客户机调用服务器上某个分布式对象的一个方法。在方法调用返回之前，该客户机被阻塞；该客户机在可以执行下一条指令之前，必须等待方法调用结束。在 JMS 中，客户机将消息发送给一个虚拟通道（主题或队列），而其它 JMS 客户机则预订或监听这个虚拟通道。当 JMS 客户机发送消息时，它并不等待回应。它执行发送操作，然后继续执行下一条指令。消息可能最终转发到一个或许多个客户机，这些客户机都不需要作出回应。

JMS的通用接口集合以异步方式发送或接收消息。异步方式接收消息显然是使用间断网络连接的客户机，另外， JMS采用一种宽松结合方式整合企业系统的方法，其主要的目的就是创建能够使用跨平台数据信息的、可移植的企业级应用程序。

JMS API体系结构：

 

 

IBM WebSphere MQ

WebSphere MQ建立了消息传输标准，同时支持那些快速增长的以Java Message Service进行通讯的商业应用所使用的语言。WebSphere MQ固有的灵活性让您放心的修改、新建和替换应用程序，使您的应用基础架构能够满足当前以及未来的要求。

IBM WebSphere MQ 使商业应用在不同平台上以消息作为数据交换的手段，来推动应用集成。这种方式支持数据的同步、异步处理以及面向服务的架构（SOA）。

WebSphere MQ能够：

                            1、保证信息到达并且只到达一次

处                          2、理通信协议

                            3、根据可用资源动态地分配工作负载

                            4、系统出现问题时执行恢复

                            5、使程序更便携，程序员能更好的处理关键业务需求，而不被拖累于底层网络的复杂性

WebSphere MQ作为消息中间件的价值是它有能力来解决IT相关的业务问题，并且提供可靠的消息提供机制。通过WebSphere MQ可以实现：

n 不受时间约束的消息传递——应用程序和Web服务能自如地交换信息，而无需顾虑应用或服务在通讯时是否有效。例如，您可以在白天输入订单并发送至订单执行系统以备处理，然而订单执行系统可以在夜间进行订单的批处理。当一个正在接收消息的应用程序暂时无效时尤为重要。

n 确保消息传递——一旦信息被创建，WebSphere MQ便具备了正确发送它的职责。

n 交易支持——通常情况下，在应用之间交换一条消息是远远不够的，经常是一组消息。例如，一个订单入口程序通常将订单中的每个条目都发布一条消息，而不是把订单发布成一条消息。如果在一组消息被完全处理之前(例如已处理10条消息中的前4条)，有一条消息发生错误，那么必须回滚这部分消息(第1条到第4条消息)，才可以保证在再次启动时重新发布一组完整消息。这种机制通常被归纳为支持工作单元。

n 信息传递的并行处理——由于许多后台应用对新用户也是有效的(例如客户通过Web进入订单系统)，这些应用不应该让客户感到失望。例如在订单处理过程中让客户长时间等待会使客户非常灰心。在以消息机制为通讯方式的环境下，这种延误会被减少，因为消息不是直接发送给应用而是被放到队列中。一旦消息被提交给WebSphere MQ，应用恢复与用户的交互。

n 安全的消息传递——有能力使用高层的安全性来转移高价值/高风险交易所固有的风险。WebSphere MQ支持工业标准SSL，并为高级安全特征要求提供了扩展的安全版本。

n 一致的编程接口——Java Messaging Service是包含在J2EE标准规范内的应有程序接口。我们推荐在部署新的信息应有程序时使用JMS接口，然而对于那些准备采用非java应用并且已经使用了大量非java应用的企业来说，可以使用MQ接口(MQI)。编程接口是跨多平台以及用户友好的接口。

n 应用独立于网络或者系统故障——应用程序使用任意一种程序接口（JMS或者MQI）通过WebSphere MQ来发送和接收消息。WebSphere MQ提供了处理消息传递的大部分复杂性功能，这意味着应有程序设计可以着重于处理商业问题而不是IT 基础架构和网络问题。

n 系统资源的有效利用——当不同平台的用户采用集群操作时，能够开发未充分利用的资源或者降低平台成本。

n 可扩展性——可以通过群集来完成横向或者纵向的扩展。可以通过增加额外的队列管理器（比如为每个处理器增加一个）或者在多平台上构架群集来提高在多处理器平台上的消息处理能力。既然可以在所有的通用平台上来部署WebSphere MQ，因此一个开始基于桌面平台的实现同样可以成长为基于主机平台的实现。

n 文件传输——通过WebSphere MQ信息，文件传输应有允许您以WebSphere MQ 消息的格式发送和接收任何格式和任何类型的文件。这些文件包括：图像、word处理的文档、电子数据表、报告、信函、备忘录、图表。

WebSphere MQ架构图：

            

 

 

相同点：

1、 实现消息的异步发送接收，发布订阅，使得两端的应用解耦。

2、实现消息持久化机制，保证消息可靠性传输。

3、优化网络传输，支持断点续传。

 

不同点：

1. 结构类型：

RV 和 MQ 都是分布式结构的， 分布式消息中间件的 Server 在应用环境里都会部署多个，彼此互联，没有主备之分。 

JMS 为星型结构，JMS 消息中间件的应用部署一般都是主备两个 Server ，消息的发送和接收应用平时和主 Server 相连，有问题时切换到备 Server ，主备 Server 共用公共的存储设备来保存消息。

 

2. 推送机制：

MQ 和 JMS 消息中间件都采用消息接收端“主动接收”消息的模式。

消息从发送端发出后，首先会缓存到 Server 上， 接收端应用发起一个接收消息的请求， Server 把消息作为应答返回给接收端。接收端不执行接收动作，消息就会一直在 Server 上保存。

RV 和这两种消息中间件都不同，使用的是消息“推送”的模式，即消息接收端“被动接收”模式。

消息从发送端发出后，并不在 Server 上缓存， Server 只做路由把消息推送给消息接收端。消息接收端只要连接上 Server ，订阅要接收的消息，这些消息就会源源不断地从 Server 那里推送过来，消息先缓存到接收客户端的队列里，接收端应用再从队列里取消息。

 

3. 缓存机制

    RV 是一个分布式结构，推送消息模式，客户端缓存的消息中间件。分布式结构适用于分布是应用系统，方便做扩展，推送加客户端缓存适用于高实时性消息的处理，消息需要在第一时间到达目的地，过时的消息的没有必要保存下来的，消息接收端应用需要做的事情就是不断地处理已经推送到的消息。

 

4.  传输方式

MQ 和 JMS 消息中间件在 IP 层都使用“点对点”的传输方式。

 MQ 和 JMS 实现发布订阅是在 Server 按消息的 Topic 来缓存消息，为每一个订阅者拷贝每一条消息的引用。当所有订阅者都从 Server 上取走某条消息，这条消息才在 Server 上删除。

RV 在 IP 层使用的是“广播”或者“组播”的方式。 

使用广播或者组播可以直接实现一对多的发布订阅形式，发布应用发布消息到 RV 网络上，这些消息会广播到网络的每一个节点上，每一个订阅应用都会收到这些消息。

 

5. 通讯协议 

MQ 和 JMS 消息中间件不论是 Server 和 Server 的通信，还是 Server 和 Client 的通信，在传输层都使用 TCP 协议，保证消息传输连接的可靠性。

而 RV 在 Server 和 Server 之间的通信使用了 UDP 协议，牺牲可靠性来达到高实时性的需求。 RV 有两种可靠性级别， RV Reliable 和 RVCM 。 RV Reliable 模式使用基于 UDP 增加了一定可靠机制的 TRDP 协议，在一定范围内具有消息包的检查和重传机制，保证了一定程度的消息可靠性，但不保证消息不丢失。 RVCM 在 RV Reliable 基础上更进一步，在消息级别具有消息确认和重传机制，可以保证消息绝对不丢失。对于长度在 1500 个字节以下的消息， RV Reliable 发布消息能达到 150 万笔消息每秒，接收也能达到 50 万笔消息每秒。传输消息的性能是非常好的。

 

6. 匹配 模式

MQ 和 JMS 消息中间件在 Server 端按“ Queue” 和“ Topic ”来缓存消息，消息的发送端和接收端按 Queue 和 Topic 的名字来匹配。每个 Server能创建的 Queue 和 Topic 是有限的，这也就限制了使用 MQ 和 JMS 消息中间件构建的应用，这些应用在做消息收发处理的时候只能使用粗粒度的消息分类。

RV 不在 Server 端缓存消息，也没有 Server 端的 Queue 和 Topic 。它是使用消息的“ Subject ”来做消息发送端和接收端的匹配的。每个消息都有 Subject ， Subject 格式是多个字符串的串接，没有数目或者长度的限制。比如在市场数据系统里，行情数据消息的 Subject 里包含金融品种的名字，这样的 Subject 可以有上百万个。消息订阅端可以细到只接收某个市场的某个品种的行情数据。

RV 使用优化的算法实现 Subject 的筛选。如果 RV 网络上有一万种消息，一个 RV Server 被一千个消息接收端连接，每个接收端订阅不同的 Subject 。那 RV Server 的工作就类似一个超级的邮件分检员，对每一个从 RV 网络上广播而来的消息做 Subject 的判断，判断是否在这一千个订阅的 Subject 的范围内，是则将消息推送到订阅此消息的接收端，否则将消息抛弃。当数据量很大时，这种筛选工作是需要很高效率的。