市场上的消息中间件：
mom4j
mom4j是一个完全实现JMS1.1规范的消息中间件并且向下兼容JMS1.0与1.02.它提供了自己的消息处理存储使它独立于关系数据与语言,所以它的客户端可以用任何语言开发.
OpenJMS
OpenJMS是一个开源的Java Message Service API1.0.2规范的实现,它包含有以下特性：
*.它既支持点到点（point-to-point）（PTP）模型和发布/订阅（Pub/Sub）模型。
*.支持同步与异步消息发送
*.JDBC持久性管理使用数据库表来存储消息
*.可视化管理界面。
*.Applet支持。
*.能够与Jakarta Tomcat这样的Servlet容器结合。
*.支持RMI,TCP,HTTP与SSL协议。
*.客户端验证
*.提供可靠消息传输、事务和消息过滤
UberMQ
UberMQ完全实现了Java Message Service规范。UberMQ是因为现有的许多JMS提供商已经违背了分布式计算的核心原则：快速与简单而开发的。
Hermes JMS
利用它提供的Swing UI可以很好的实现监控JMS providers。
ActiveMQ
ActiveMQ是一个开放源码基于Apache2.0licenced发布并实现了JMS1.1。它能够与Geronimo，轻量级容器和任Java应用程序无缝的给合。
Somnifugi
Somnifugi使得工作在同一个java虚拟机中的线程能实现消息互发。
MantaRay
MantaRay基于peer-2-peer技术。它具有以下特性:
1.它既支持点对点(point-to-point)的域，又支持发布/订阅(publish/subscribe)类型的域。
2.并且提供对下列类型的支持：经认可的消息传递,事务型消息的传递，一致性消息和具有持久性的订阅者支持。
3.消息过滤体制。
4.能与WebLogic and WebSphere给合。
5.支持TCP,UDP与HTTP传输协。
Presumo
Presumo也是一个实现Java Message Service API的JMS消息中间件。
JORAM
JORAM一个类似于openJMS分布在ObjectWeb之下的JMS消息中间件。
JMS4Spread
JMS4Spread是一个消息系统.它部分地实现了Java消息服务(JMS)API.
Open Message Queue
Open Message Queue是Sun Java System Message Queue的一个开源版本。Open message queue是一个企业级，可升级，非常成熟的消息服务器。它为面向消息的系统集成提供一套完整的JMS（Java Message Service）实现。由于Open MQ源自Sun 的Java Message Queue，所以其具有Java System Message Queue拥有的所有特性，功能和性能。
FFMQ
FFMQ是一个轻量级，高性能，快速的Native JMS1.1开源实现。支持SSL远程连接，自动防故障的持久化机制，基于模板定义目的地（Destination），采用模式匹配自动创建目的地（Destination）。
MQSSave/MQSLoad
MQSSave是一个简单的Java程序，能够读取MQSeries队列的消息保存至文件中。而MQSLoad是一相反的Java程序，能够读取文件中的消息然后加载至MQSeries队列中。HornetQ
HornetQ是一个支持集群和多种协议，可嵌入、高性能的异步消息系统。HornetQ完全支持JMS，HornetQ不但支持JMS1.1API同时也定义属于自己的消息API，这可以最大限度的提升HornetQ的性能和灵活性。在不久的将来更多的协议将被HornetQ支持。
?HornetQ拥有超高的性能，HornetQ在持久化消息方面的性能可以轻易的超于其它常见的非持久化消息引擎的性能。当然，HornetQ的非持久化消息的性能会表现的更好！
?HornetQ完全使用POJO，纯POJO的设计让HornetQ可以尽可能少的以来第三方的包。从设计模式来说，HornetQ这样的设计入侵性也最小。HornetQ既可以独立运行，也可以与其它Java应用程序服务器集成使用。
?HornetQ拥有完善的错误处理机制，HornetQ提供服务器复制和故障自动转移功能，该功能可以消除消息丢失或多个重复信息导致服务器出错。
?HornetQ提供了灵活的集群功能，通过创建HornetQ集群，您可以享受到到消息的负载均衡带来的性能提升。您也可以通过集群，组成一个全球性的消息网络。您也可以灵活的配置消息路由。
?HornetQ拥有强大的管理功能。HornetQ提供了大量的管理API和监控服务器。它可以无缝的与应用程序服务器整合，并共同工作在一个HA环境中。
Apache Qpid
Apache Qpid是最新开放企业信息标准AMQP（Advanced Message Queuing Protocol）的一个开源实现。Java版实现完全支持JMS标准，可运行在任意Java平台上。此外Qpid 还提供AMQP Client APIs的各种语言实现包括：
?C++
?Java,fully conformant with JMS1.1
?C#.NET,0-10using WCF
?Ruby
?Python
Spring AMQP
Spring AMQP是一个用于替换原先Spring JMS支持的消息解决方案。提供收发消息的模板，还支持基于消息驱动的POJO。用法和配置与Spring中对JMS的支持一样。这个项目包含Java和.NET两个版本。
Kafka
Kafka是一个高吞吐量分布式消息系统。linkedin开源的kafka。Kafka就跟这个名字一样，设计非常独特。首先，kafka的开发者们认为不需要在内存里缓存什么数据，操作系统的文件缓存已经足够完善和强大，只要你不搞随机写，顺序读写的性能是非常高效的。kafka 的数据只会顺序append，数据的删除策略是累积到一定程度或者超过一定时间再删除。Kafka另一个独特的地方是将消费者信息保存在客户端而不是MQ服务器，这样服务器就不用记录消息的投递过程，每个客户端都自己知道自己下一次应该从什么地方什么位置读取消息，消息的投递过程也是采用客户端主动pull的模型，这样大大减轻了服务器的负担。Kafka还强调减少数据的序列化和拷贝开销，它会将一些消息组织成Message Set做批量存储和发送，并且客户端在pull数据的时候，尽量以zero-copy的方式传输，利用sendfile （对应java里的FileChannel.transferTo/transferFrom）这样的高级IO函数来减少拷贝开销。可见，kafka是一个精心设计，特定于某些应用的MQ系统，这种偏向特定领域的MQ系统我估计会越来越多，垂直化的产品策略值的考虑。
play-rabbitmq
用memcached的语言都可以良好的与它通信。FQueue为你提供一个不需要特别优化，高性能的一个消息系统。
特性
1.基于磁盘持久化存储。
2.支持memcached协议。
3.支持多队列，密码验证功能。
4.高性能，能达到数十万qps。
5.低内存消耗。100-300M内存即可工作得很好。
6.高效率IO读写算法，IO效率高。
7.纯JAVA代码。支持进程内JVM级别的直接调用。
8.在不需要强顺序的场景下，支持多机负载均衡。
不支持
1.不支持topic方式的订阅功能。
2.不支持主从复制。
主流消息中间件及选型推荐：
ActiveMQ:（还有升级版叫Apollo,由于转向Scala，原来的架构都要改掉。但是只支持storm 协议，不支持JMS），在网络上别人反映，消息量越来越大时，当出现消息堆积时，性能争骤下降，主要卡在磁盘写入，用了硬件加速，也还是不能忍受。
消息中间件的技术选型心得－RabbitMQ、ActiveMQ和ZeroMQ
作者：chszs，转载需注明。博客主页：https://www.doczj.com/doc/d04860556.html,/chszs
RabbitMQ、ActiveMQ和ZeroMQ都是极好的消息中间件，但是我们在项目中该选择哪个更适合呢？很多开发者面临这个烦恼。下面我会对这三个消息中间件做一个比较，看了后你们就心中有数了。
RabbitMQ是AMQP协议领先的一个实现，它实现了代理(Broker)架构，意味着消息在发送到客户端之前可以在中央节点上排队。此特性使得RabbitMQ易于使用和部署，适宜于很多场景如路由、负载均衡或消息持久化等，用消息队列只需几行代码即可搞定。但是，这使得它的可扩展性差，速度较慢，因为中央节点增加了延迟，消息封装后也比较大。
ZeroMQ是一个非常轻量级的消息系统，专门为高吞吐量/低延迟的场景开发，在金融界的应用中经常可以发现它。与RabbitMQ相比，ZeroMQ支持许多高级消息场景，但是你必须实现ZeroMQ框架中的各个块（比如Socket或Device等）。ZeroMQ非常灵活，但是你必须学习它的80页的手册（如果你要写一个分布式系统，一定要阅读它）。
ActiveMQ居于两者之间，类似于ZemoMQ，它可以部署于代理模式和P2P模式。类似于RabbitMQ，它易于实现高级场景，而且只需付出低消耗。它被誉为消息中间件的“瑞士军刀”。
要注意一点，ActiveMQ的下一代产品为Apollo。
最终，这三个产品：
1.都有客户端API且支持多种编程语言；
2.都有大量的文档；
3.都提供了积极的支持。
ActiveMQ RabbitMQ ZeroMQ
遵循规范JMS1.1及j2ee1.4AMPQ-----
架构模型消息代理架构Broker消息代理架构
c/s架构
Broker
实现语言Java Erlang c/c++
支持消息协议Stomp AMPQ、Stomp等--------
IMatix
主要推动力量Apache、Redhat Lshift、Vmware、
SpringSource
支持编程语言C、Java、Python C、Java、Python C、Java、Python
编程复杂度复杂简单中等
发送端缓存
持久化支持支持，不支持第三方
数据库
性能一般一般高
三个经典消息中间件的比较
对于消息中间件，绝大多数熟悉的是MQ(IBM公司出品)，这是目前使用最广泛的中间件产品。还有两个也比较流行，他们是JMS和RV。JMS即JAVA消息服务（Java Message Service）应用程序接口是一个JAVA平台中关于面向消息中间件的API，用于在两个应用程序之间，或
分布式系统中发送消息，进行异步通信，是一个与具体平台无关的API。TIBCO Rendezvous （或称为TIBCO RV）也是一种中间件，具有发布/订阅(Publish/Subscribe)、基于主题寻址(Subject-Based Addressing)和自定义数据信息(Self-Describing Data Messages)等专利技术功能，使不同应用平台上的信息在一个共享的虚拟总线Information Bus(TIB)上进行传输交换。
先总结一下消息中间件的功能，以上的三类中间件都实现了这些功能。
●实现消息的异步发送接收，发布订阅，使得两端的应用解耦（减少或解除应用程序
之间的耦合度）。
●实现消息持久化机制，保证消息可靠性传输。
●优化网络传输，支持断点续传。
１、区别之是否分布式
RV和MQ都是分布式结构的，和JMS消息中间件的星型结构不同。分布式消息中间件的Sever在应用环境里都会部署多个，彼此互联，没有主备之分。JMS消息中间件的应用部署一般都是主备两个Server，消息的发送和接收应用平时和主Server相连，有问题时切换到备Server，主备Server共用公共的存储设备来保存消息。
２、区别之是否接收端主动
MQ和JMS消息中间件都采用消息接收端主动接收消息的方式。消息从发送端发出后，首先会缓存到Server上，接收端应用发起一个接收消息的请求，Server把消息作为应答返回给接收端。接收端不执行接收动作，消息就会一直在Server上保存。RV和这两种消息中间件都不同，使用的是发送端主动的消息推送模式。消息从发送端发出后，并不在Server上缓存，Server只做路由把消息推送给消息接收端。消息接收端只要连接上Server，订阅要接收的消息，这些消息就会源源不断地从Server那里推送过来，消息先缓存到接收客户端的队列里，接收端应用再从队列里取消息。RV的最大特点就是把一个数据生产者的数据以最快的速度推送到多个数据消费者那里。RV从金融市场数据系统的需求中产生而来，正是这些特点使得它在证券系统得到最广泛的应用。
３、区别之是否便于一对多分布
MQ和JMS消息中间件在IP层都使用点对点的一对一传输方式，而RV在IP层使用的是广播或者组播的一对多方式。使用广播或者组播可以直接实现一对多的发布订阅形式，发布应用（发送端）发布消息到RV网络上，这些消息会广播到网络的每一个节点上，每一个订阅应用（接收端）都会收到这些消息。而MQ和JMS实现一对多发布订阅就要麻烦的很多，都是在Server按消息的Topic（主题）来缓存消息，为每一个订阅者拷贝每一条消息的引用。当所有订阅者都从Server上取走某条消息，这条消息才可在Server上删除。
４、区别之是否在传输层使用TCP
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万笔消息每秒，传输消息的性能非常好。
５、区别之是否用Subject做收发端的匹配
RV使用消息的Subject来做消息发送端和接收端的匹配。RV不在Server端缓存消息，也没有Server端的Queue和Topic。每个消息都有Subject，Subject格式是多个字符串的串
接，没有数目或者长度的限制。比如在市场数据系统里，行情数据消息的Subject里包含金融品种的名字，这样的Subject可以有上百万个。消息订阅端可以细到只接收某个市场的某个品种的行情数据，所以RV能使用细粒度的消息分类。MQ和JMS消息中间件在Server端按Queue和Topic来缓存消息，消息的发送端和接收端按Queue和Topic的名字来匹配。每个Server能创建的Queue和Topic是有限的，这也就限制了使用MQ和JMS消息中间件构建的应用，这些应用在做消息收发处理的时候只能使用粗粒度的消息分类。
６、区别之中间件结构
7、区别之典型应用场景实例
MQ已知的典型应用场景是商业银行向人民银行报送监管信息；JMS已知的典型应用场景是异步发送邮件；
RV已知的典型应用场景是金融市场数据提供商（如路透、彭博、道琼斯）向银行、大型企业提供证券、外汇等金融市场信息。
淘宝开源框架Metaq:
淘宝吸收其它消息中间件(Apache Kafka)而自己开发的一款消息中间件.原名（Metamorphosis）
MetaQ作为一个分布式的消息中间件，需要依赖zookeeper，对于一些规模不大、单机应用的场景，我个人并不是特别支持尝试用MetaQ，因为多一个依赖系统，其实就是多一份风险，在这些简单场景下，可能类似memcacheq、kestrel甚至redis等轻量级MQ就非常合适。而MetaQ一开始就是为大规模分布式系统设计的，如果不当使用，可能没有带来好处，反而多出一堆问题。开发者需要根据自己面对的场景，团队的技术能力，做出一个合适的选择。
MetaQ初探
博客分类：
?开源
MetaQ（全称Metamorphosis）是一个高性能、高可用、可扩展的分布式消息中间件，,MetaQ具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性，适用于大吞吐量、顺序消息、广播和日志数据传输等场景，METAQ在阿里巴巴各个子公司被广泛应用，每天转发250亿+条消息。主要应用于异步解耦，Mysql数据复制，收集日志等场景。
总体结构
主要特点
?生产者、服务器和消费者都可分布式
?消息存储顺序写
?性能极高,吞吐量大
?支持消息顺序
?支持本地和XA事务
?客户端pull，随机读,利用sendfile系统调用，zero-copy,批量拉数据
?支持消费端事务
?支持消息广播模式
?支持异步发送消息
?支持http协议
?支持消息重试和recover
?数据迁移、扩容对用户透明
?消费状态保存在客户端
?支持同步和异步复制两种HA
主要特性
数据完整性
消息生产者发送的消息，meta服务器收到后在做必要的校验和检查之后的第一件事就是写入磁盘，写入成功之后返回应答给生产者，生产者发送消息返回SendResult，如果isSuccess返回为true,则表示消息已经确认发送到服务器并被服务器接收存储。整个发送过程是一个同步的过程。保证消息送达服务器并返回结果。因此，可以确认每条发送结果为成功的消息服务器都是写入磁盘的。
写入磁盘，不意味着数据落到磁盘设备上，毕竟我们还隔着一层os，os对写有缓冲。Meta有两个特性来保证数据落到磁盘上:每1000条（可配置），即强制调用一次force来写入磁盘设备。每隔10秒（可配置），强制调用一次force来写入磁盘设备。因此,Meta通过配置可保证在异常情况下（如磁盘掉电）10秒内最多丢失1000条消息。当然通过参数调整你甚至可以在掉电情况下不丢失任何消息。
虽然消息在发送到broker之后立即写入磁盘才返回客户端告诉消息生产者消息发送成功，通过
没有永久损坏，消息总可以在重启后恢复并正常投递给消费者们。但是，如果遇到了磁盘永久损坏或者数据文件永久损坏的情况，那么该broker上的消息数据将可能永久丢失。为了防止这种情况的发生，一个可行的方案就是将消息数据复制到多台机器，类似mysql的主从复制功能（异步复制和同步功能）
数据可靠性
服务器通常组织为一个集群，一条从生产者过来的消息可能按照路由规则存储到集群中的某台机器。Meta 已经实现高可用的HA方案，类似mysql的同步和异步复制，将一台meta服务器的数据完整复制到另一台slave服务器，并且slave服务器还提供消费功能（同步复制不提供消费）。消息的消费者是一条接着一条地消费消息，只有在成功消费一条消息后才会接着消费下一条。如果在消费某条消息失败（如异常），则会尝试重试消费这条消息（默认最大5次），超过最大次数后仍然无法消费，则将消息存储在消费者的本地磁盘，由后台线程继续做重试。而主线程继续往后走，消费后续的消息。因此，只有在MessageListener确认成功消费一条消息后，meta的消费者才会继续消费另一条消息。由此来保证消息的可靠消费。
消费者的另一个可靠性的关键点是offset的存储，也就是拉取数据的偏移量。我们目前提供了以下几种存储方案zookeeper，默认存储在zoopkeeper上，zookeeper通过集群来保证数据的安全性。mysql，可以连接到您使用的mysql数据库，只要建立一张特定的表来存储。完全由数据库来保证数据的可靠性。file，文件存储，将offset信息存储在消费者的本地文件中。Offset会定期保存，并且在每次重新负载均衡前都会强制保存一次
下载、配置、运行
首先需要安装配置Zookeeper，如果不知道怎么配置的，看我的文章，有一章讲解过！
https://https://www.doczj.com/doc/d04860556.html,/p/meta-queue/downloads/list选择最新版本的服务器并下载到本地解压缩文件,bin 目录存放的脚本文件，日志在logs目录，而配置文件主要是conf目录下server.ini，lib存放所有的依赖jar 包。
进入JAVA_HOME,JMX等变量。
根据需要修改conf/server.ini文件(列出了所有的配置)：
zk.zkEnable=true是否注册到zk，默认为true
zk.zkConnect=localhost:2181zk的服务器列表
zk.zkSessionTimeoutMs=30000zk心跳超时，单位毫秒，默认30秒zk.zkSessionTimeoutMs=30000
zk.zkConnectionTimeoutMs=30000zk连接超时时间，单位毫秒，默认30秒
zk.zkSyncTimeMs=5000zk数据同步时间，单位毫秒，默认5秒
brokerId：服务器ID(必须是集群内唯一)
serverPort：服务器端口
hostName：默认将取本机IP(多机网卡，需要指明)
dataLogPath：日志数据文件路径，默认跟dataPath一样
dataPath:于指定默认的数据存储路径（慎重设置，默认在user.home/meta下）
numPartitions:默认topic的分区数目（慎重设置）
maxSegmentSize：单个文件的最大大小,实际会超过此值，默认1G
maxTransferSize：传输给客户端每次最大的缓冲区大小，默认1M
unflushThreshold：最大允许的未flush间隔时间，毫秒，默认10秒putProcessThreadCount：;处理put请求线程数，默认cpus*10
deletePolicy=delete,168(数据删除策略，默认超过7天即删除,这里的168是小时，10s表示10秒，10m表示10分钟，10h表示10小时，默认为小时)
deleteWhen:何时执行删除策略的cron表达式，默认是006,18**?，也就是每天的早晚6点执行处理策略。deleteWhen:删除策略的执行时间，cron表达式
maxCheckpoints:最大保存事务checkpoint数目，默认为3
checkpointInterval:事务checkpoint时间间隔，单位毫秒，默认1小时(3600000) maxTxTimeoutTimerCapacity=30000最大事务超时事件数，用于监控事务超时maxTxTimeoutInSeconds=60最大事务超时时间，单位秒
flushTxLogAtCommit=1事务日志的同步设置，0表示让操作系统决定，1表示每次commit都同步，2表示每隔1秒同步一次，此参数严重影响事务性能，可根据你需要的性能和可靠性之间权衡做出一个合理的选择。通常建议设置为2，表示每隔1秒刷盘一次，也就是最多丢失一秒内的运行时事务。这样的可靠级别对大多数服务是足够的。最安全的当然是设置为1，但是将严重影响事务性能。而0的安全级别最低。安全级别上1>=2>0，而性能则是0>=2>1。
diamondZKDataId=metamorphosis.zkConfig zk在diamond中配置存储的dataId
diamondZKGroup=DEFAULT_GROUP zk在diamond中配置存储的group
acceptPublish:是否接收消息，默认为true；如果为false，则不会注册发送信息到zookeeper上，客户端当然无法发送消息到该broker。本参数可以被后续的topic配置覆盖。
acceptSubscribe:与acceptPublish类似，默认也为true；如果为false，则不会注册消费信息到zookeeper上，消费者无法发现该broker，当然无法从该broker消费消息。本参数可以被后续的topic配置覆盖。unflushThreshold:每隔多少条消息做一次磁盘sync，强制将更改的数据刷入磁盘。默认为1000。也就是说在掉电情况下，最多允许丢失1000条消息。可设置为0，强制每次写入都sync。在设置为0的情况下，服务器会自动启用group commit技术，将多个消息合并成一次sync来提升IO性能。经过测试，group commit 情况下消息发送者的TPS没有受到太大影响，但是服务端的负载会上升很多。
unflushInterval:间隔多少毫秒定期做一次磁盘sync,默认是10秒。也就是说在服务器掉电情况下，最多丢失
10秒内发送过来的消息。不可设置为小于或者等于0
JAVA客户端代码
生产者：
Java代码
1.package com.metaq.product;
2.
3.import java.io.BufferedReader;
4.import java.io.InputStreamReader;
5.
6.import com.taobao.metamorphosis.Message;
7.import com.taobao.metamorphosis.client.MessageSessionFactory;
8.import com.taobao.metamorphosis.client.MetaClientConfig;
9.import com.taobao.metamorphosis.client.MetaMessageSessionFactory;
10.import com.taobao.metamorphosis.client.producer.MessageProducer;
11.import com.taobao.metamorphosis.client.producer.SendResult;
12.import com.taobao.metamorphosis.utils.ZkUtils.ZKConfig;
13.public class Products{
14.public static void main(String[]args)throws Exception{
15.final MetaClientConfig metaClientConfig=new MetaClientConfig();
16.final ZKConfig zkConfig=new ZKConfig();
17.zkConfig.zkConnect="192.168.2.11:2181";
18.metaClientConfig.setZkConfig(zkConfig);
19.//由这个工厂创建生产者或者消费者
20.//1.服务的查找和发现，通过diamond和zookeeper帮你查找日常的meta服
务器地址列表
21.//2.连接的创建和销毁，自动创建和销毁到meta服务器的连接，并做连接复
用，也就是到同一台meta的服务器在一个工厂内只维持一个连接。
22.//3.消息消费者的消息存储和恢复，后续我们会谈到这一点。
23.//4.协调和管理各种资源，包括创建的生产者和消费者的。
24.MessageSessionFactory sessionFactory=new MetaMessageSessionFactory(metaC
lientConfig);
25.//消息生产者的接口，MessageProducer是线程安全的,MessageProducer创建
的代价昂贵，每次都需要通过zk
26.//查找服务器并创建tcp长连接,通过它来发送消息，每个消息对象都是
Message类的实例，Message表示一个消息对象，它包含这么几个属性：
27.//id:Long型的消息id,消息的唯一id，系统自动产生，用户无法设置，在发送
成功后由服务器返回，发送失败则为0。
28.//topic:消息的主题，订阅者订阅该主题即可接收发送到该主题下的消息，生
产者通过指定发布的topic查找到需要连接的服务器地址，必须。
29.//data:消息的有效载荷，二进制数据，也就是消息内容，meta永远不会修改
消息内容，你发送出去是什么样子，接收到就是什么样子。
30.//消息内容通常限制在1M以内，我的建议是最好不要发送超过上百K的消息，
必须。数据是否压缩也完全取决于用户。
31.//attribute:消息属性，一个字符串，可选。发送者可设置消息属性来让消费者
过滤。
32.MessageProducer producer=sessionFactory.createProducer();
33.final String topic="test";
34.producer.publish(topic);
35.BufferedReader reader=new BufferedReader(new InputStreamReader(System.in))
;
36.String line="qiujinyong";
37.while((line=reader.readLine())!=null){
38.//send message
39.SendResult sendResult=producer.sendMessage(new Message(topic,line.getByt
es()));
40.//check result
41.if(!sendResult.isSuccess()){
42.System.err.println("Send message failed,error message:"+sendResult.getErro
rMessage());
43.}
44.else{
45.System.out.println("Send message successfully,sent to"+sendResult.getParti
tion());
46.}
47.}
48.}
49.}
消费者：
Java代码
1.package com.metaq.consum;
2.
3.import java.util.concurrent.Executor;
4.
5.import com.taobao.metamorphosis.Message;
6.import com.taobao.metamorphosis.client.MessageSessionFactory;
7.import com.taobao.metamorphosis.client.MetaClientConfig;
8.import com.taobao.metamorphosis.client.MetaMessageSessionFactory;
9.import com.taobao.metamorphosis.client.consumer.ConsumerConfig;
10.import com.taobao.metamorphosis.client.consumer.MessageConsumer;
11.import com.taobao.metamorphosis.client.consumer.MessageListener;
12.import com.taobao.metamorphosis.utils.ZkUtils.ZKConfig;
13.
14.public class AsyncConsum{
15.public static void main(String[]args)throws Exception{
16.final MetaClientConfig metaClientConfig=new MetaClientConfig();
17.final ZKConfig zkConfig=new ZKConfig();
18.zkConfig.zkConnect="192.168.2.11:2181";
19.metaClientConfig.setZkConfig(zkConfig);
20.MessageSessionFactory sessionFactory=new MetaMessageSessionFactory(metaClie
ntConfig);
21.final String topic="test";
22.final String group="meta-example";
23.//每个消息者都必须有一个ConsumerConfig配置对象,我们这里设置了group属
性，这是消费者的分组名称
24.//Meta的Producer、Consumer和Broker都可以为集群。消费者可以组成一个集
群共同消费同一个topic，
25.//发往这个topic的消息将按照一定的负载均衡规则发送给集群里的一台机器。
同一个消费者集群必须拥有同
26.//一个分组名称，也就是同一个group。我们这里将分组名称设置为
meta-example
27.MessageConsumer consumer=sessionFactory.createConsumer(new ConsumerConfi
g(group));
28.//topic，订阅的主题
29.//maxSize，因为meta是一个消费者主动拉取的模型，这个参数规定每次拉取的
最大数据量，单位为字节，这里设置为1M，默认最大为1M。
30.//MessageListener，消息监听器，负责消息消息。
31.consumer.subscribe(topic,1024*1024,new MessageListener(){
32.public void recieveMessages(Message message){
33.System.out.println("Receive message"+new String(message.getData()));
34.}
35.//消息的消费过程可以是一个并发处理的过程，getExecutor返回你想设置的线
程池，每次消费都会
36.//在这个线程池里进行。recieveMessage方法用于实际的消息消费处理，
message参数即为消费者收到的消息，它必不为null。
37.//我们这里简单地打印收到的消息内容就完成消费。如果在消费过程中抛出任
何异常，该条消息将会
38.//在一定间隔后重新尝试提交给MessageListener消费。在多次消费失败的情
况下，该消息将会存储到消费者应用的本次磁盘，
39.//并在后台自动恢复重试消费
40.public Executor getExecutor(){
41.return null;
42.}
43.});
44.//在调用subscribe之后，我们还调用了completeSubscribe方法来完成订阅过
程。请注意，
45.//subscribe仅是将订阅信息保存在本地，并没有实际跟meta服务器交互，要
使得订阅关系生效必须调用
46.//一次completeSubscribe，completeSubscribe仅能被调用一次，多次调用将抛
出异常。为什么需
47.//要completeSubscribe方法呢，原因有二：
48.//首先，subscribe方法可以被调用多次，也就是一个消费者可以消费多种topic
49.//其次，如果每次调用subscribe都跟zk和meta服务器交互一次，代价太高
50.//因此completeSubscribe一次性将所有订阅的topic生效，并处理跟zk和meta
服务器交互的所有过程。
51.//同样,MessageConsumer也是线程安全的，创建的代价不低，因此也应该尽
量复用
https://www.doczj.com/doc/d04860556.html,pleteSubscribe();
53.}
54.
55.}
启动：bin/metaServer.sh start（更多的命令直接help一下。）观察：日志方式（logs/metaServer.log），命令方式（bin/metaServer.sh stats）,telnet方式（telnet IP端口stats）
启动服务器后执行客户端的生产者和消费者的代码，运行结果如下（生产者随便在控制台输入消息后，进行回车，生产者消息如果成功发送到broker，会返回一条发送成功的消息，同时消费者会接收到该消息）：生产者
消费者
集群
启动metaQ后，它将启动一个内置的zookeeper，并将broker注册到该zookeeper。但MetaQ应该是作为一个分布式集群提供服务。MetaQ的集群管理是利用zookeeper实现的，使用zookeeper发布和订阅服务，并默认使用zookeeper存储消费者offset，你需要首先安装一个zookeeper到某台机器上，或者使用某个现有的zk集群，然后配置zookeeper（zk配置参见我blog《zookeeper初探》）
负载均衡
每个broker都可以配置一个topic可以有多少个分区，但是在生产者看来，一个topic在所有broker上的的所有分区组成一个分区列表来使用。在创建producer的时候，客户端会从zookeeper上获取publish的topic 对应的broker和分区列表，生产者在发送消息的时候必须选择一台broker上的一个分区来发送消息，默认
的策略是一个轮询的路由规则如果你想实现自己的负载均衡策略，可以实现上文提到过的PartitionSelector 接口，并在创建producer的时候传入即可对于消费者而言，合理地设置分区数目至关重要。如果分区数目太小，则有部分消费者可能闲置，如果分区数目太大，则对服务器的性能有影响。在某个消费者故障或者重启等情况下，其他消费者会感知到这一变化（通过zookeeper watch消费者列表），然后重新进行负载均
衡，保证所有的分区都有消费者进行消费。拷贝broker1的配置文件broker,假设为broker2。修改broker2的server.ini,只要修改brokerId为另一个不同于broker1的值即可，启动broker2，在这个过程中你不需要重启任何现有的服务，包括生产者、消费者和broker1，他们都将自动感知到新的broker2
主从复制
先配置负载均衡后（和上面配置一样），然后再配置从机的另一个文件(conf/async_slave.properties)
#slave编号,大于等于0表示作为slave启动,同一个master下的slave编号应该设不同值. slaveId=0
#作为slave启动时向master订阅消息的group,如果没配置则默认为meta-slave-group,不同的slaveId请使用不同的group
slaveGroup=meta-slave-group
#slave数据同步的最大延时,单位毫秒
slaveMaxDelayInMills=500
#是否自动从master同步server.ini,1.4.2新增选项#第一次仍然需要自己拷贝server.ini，后续可以通过设置此选项为true来自动同步
autoSyncMasterConfig=true
这样主从配置完成，其实metaQ环境搭建以及原理还是较为简单的，MetaQ作为一个分布式的消息中间件，主要依赖zookeeper，对于一些规模不大、单机应用的场景，并不是特别支持尝试用MetaQ，因为多一个依赖系统，其实就是多一份风险，在这些简单场景下，可能类似activeMQ、redis等轻量级MQ就非常合适。而MetaQ一开始就是为大规模分布式系统设计的，如果不当使用，可能没有带来好处，反而多出一堆问题。开发者需要根据自己面对的场景，团队的技术能力，做出一个合适的选择。
消息中间件概述 消息队列技术是分布式应用间交换信息的一种技术。消息队列可驻留在存或磁盘上,队列存储消息直到它们被应用程序读走。通过消息队列，应用程序可独立地执行--它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。 在分布式计算环境中，为了集成分布式应用，开发者需要对异构网络环境下的分布式应用提供有效的通信手段。为了管理需要共享的信息，对应用提供公共的信息交换机制是重要的。 设计分布式应用的方法主要有：远程过程调用(PRC)--分布式计算环境(DCE)的基础标准成分之一；对象事务监控(OTM)--基于CORBA的面向对象工业标准与事务处理(TP)监控技术的组合；消息队列(MessageQueue)--构造分布式应用的松耦合方法。 (a) 分布计算环境/远程过程调用(DCE/RPC) RPC是DCE的成分，是一个由开放软件基金会(OSF)发布的应用集成的软件标准。RPC模仿一个程序用函数引用来引用另一程序的传统程序设计方法，此引用是过程调用的形式，一旦被调用，程序的控制则转向被调用程序。 在RPC实现时，被调用过程可在本地或远地的另一系统中驻留并在执行。当被调用程序完成处理输入数据，结果放在过程调用的返回变量中返回到调用程序。RPC完成后程序控制则立即返回到调用程序。因此RPC模仿子程序的调用/返回结构，它仅提供了Client(调用程序)和Server(被调用过程)间的同步数据交换。 (b) 对象事务监控(OTM)
基于CORBA的面向对象工业标准与事务处理(TP)监控技术的组合，在CORBA 规中定义了：使用面向对象技术和方法的体系结构；公共的Client/Server程序设计接口；多平台间传输和翻译数据的指导方针；开发分布式应用接口的语言(IDL)等，并为构造分布的Client/Server应用提供了广泛及一致的模式。(c) 消息队列(Message Queue) 消息队列为构造以同步或异步方式实现的分布式应用提供了松耦合方法。消息队列的API调用被嵌入到新的或现存的应用中，通过消息发送到存或基于磁盘的队列或从它读出而提供信息交换。消息队列可用在应用中以执行多种功能，比如要求服务、交换信息或异步处理等。 中间件是一种独立的系统软件或服务程序，分布式应用系统借助这种软件在不同的技术之间共享资源，管理计算资源和网络通讯。它在计算机系统中是一个关键软件，它能实现应用的互连和互操作性，能保证系统的安全、可靠、高效的运行。中间件位于用户应用和操作系统及网络软件之间，它为应用提供了公用的通信手段，并且独立于网络和操作系统。中间件为开发者提供了公用于所有环境的应用程序接口，当应用程序中嵌入其函数调用，它便可利用其运行的特定操作系统和网络环境的功能，为应用执行通信功能。 如果没有消息中间件完成信息交换，应用开发者为了传输数据，必须要学会如何用网络和操作系统软件的功能，编写相应的应用程序来发送和接收信息，且交换信息没有标准方法，每个应用必须进行特定的编程从而和多平台、不同环境下的一个或多个应用通信。例如，为了实现网络上不同主机系统间的通信，将要求具备在网络上如何交换信息的知识（比如用TCP/IP的socket程序设计）；为了
C#下使用消息中间件ActiveMQ和https://www.doczj.com/doc/d04860556.html,框架开发示例 1. 消息中间件简介 1.1 消息中间件定义 中间件（middleware）是基础软件的一大类，属于可复用的软件范畴。中间件在操作系统软件，网络和数据库之上，应用软件之下，总的作用是为处于自己上层的应用软件提供运行于开发的环境，帮助用户灵活、高效的开发和集成复杂的应用软件。 中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件定位于客户机服务器的操作系统之上，管理计算机资源和网络通信。 因而中间件是指一类软件，是基于分布式处理的软件，最突出的特点是其网络通信功能。也可认为中间件是位于平台和应用之间的通用服务，这些服务具有标准的程序接口和协议。针对不同的操作系统和硬件平台，可以有符合接口和协议的多种实现。 中间件可分为六类： 1) 终端仿真/屏幕转换 2) 数据访问中间件（UDA） 3) 远程过程调用中间件（RPC） 4) 消息中间件（MOM） 5) 交易中间件（TPM） 6) 对象中间件 消息中间件是指利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。 消息中间件可以即支持同步方式，又支持异步方式。异步中间件比同步中间件具有更强的容错性，在系统故障时可以保证消息的正常传输。异步中间件技术又分为两类：广播方式和发布/订阅方式。由于发布/订阅方式可以指定哪种类型的用户可以接受哪种类型的消息，更加有针对性，事实上已成为异步中间件的非正式标准。 面向消息的中间件（Message Oriented Middleware，MOM），提供了以松散耦合的灵活方式集成应用程序的一种机制。它们提供了基于存储和转发的应用程序之间的异步数据发送，即应用程序彼此不直接通信，而是与作为中介的MOM通信。MOM提供了有保证的消息发送（至少是在尽可能地做到这一点），应用程序开发人员无需了解远程过程调用（PRC）和网络/通信协议的细节。 消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。
中间件知识 1，常见应用系统开发构架： 传统的两层结构：表示层（Presentation Layer）：用于处理人机交互。目前最主流的两种表示层是Windows桌面和IE浏览器方式。它主要责任是处理用户请求，例如鼠标点击、输入、HTTP请求等，实际部分业务逻辑。数据层（Data source Layer）：处理数据库、消息系统、事务系统。实际部分业务逻辑。 经典的三层结构：表示层（Presentation Layer）：用于处理人机交互。目前最主流的两种表示层是Windows桌面和IE浏览器方式。它主要的责任是处理用户请求，例如鼠标点击、输入、HTTP请求等。业务层（Business Layer）：模拟了企业中的实际活动，也可以认为是企业活动的模型。数据层（Data source Layer）：处理数据库、消息系统、事务系统。 通用的四层结构：表示层（Presentation Layer）：用于处理人机交互。目前最主流的两种表示层是Windows桌面和IE浏览器方式。它主要的责任是处理用户请求，例如鼠标点击、输入、HTTP请求等。业务层（Business Layer）：模拟了企业中的实际活动，也可以认为是企业活动的模型。数据层（Data source Layer）：处理数据库、消息系统、事务系统。安全层（Security Layer）：管理系统身份验证、授证、日志等。 主要产品：应用中间件、平台中间件、工作流中间件、数据传输中间件等。 2，什么是中间件 中间件（middleware）：是基础软件的一大类，属于可复用软件的范畴。顾名思义，中间件处于操作系统软件与用户的应用软件的中间。中间件在操作系统、网络和数据库之上，应用软件的下层，总的作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。 在众多关于中间件的定义中，比较普遍被接受的是IDC表述的：中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。 IDC对中间件的定义，中间件是一类软件，而非一种软件；中间件不仅仅实现互连，还要实现应用之间的互操作；中间件是基于分布式处理的软件，最突出的特点是其网络通信功能。3，为什么要中间件 Internet及WWW的出现，使计算机的应用范围更为广阔，许多应用程序需在网络环境的异构平台上运行。这一切都对新一代的软件开发提出了新的需求。在这种分布异构环境中，通常存在多种硬件系统平台(如PC，工作站，小型机等)，在这些硬件平台上又存在各种各样的系统软件(如不同的操作系统、数据库、语言编译器等)，以及多种风格各异的用户界面，这些硬件系统平台还可能采用不同的网络协议和网络体系结构连接。如何把这些系统集成起来并开发新的应用是一个非常现实而困难的问题。 4，中间件的主要作用 为解决分布异构问题，人们提出了中间件(middleware)的概念。中间件是位于平台(硬件和操作系统)和应用之间的通用服务，如图1所示，这些服务具有标准的程序接口和协议。针对不同的操作系统和硬件平台，它们可以有符合接口和协议规范的多种实现。 5，数据库中间件（DM，Database Middleware） 数据库中间件在所有的中间件中是应用最广泛，技术最成熟的一种。一个最典型的例子就是ODBC，ODBC是一种基于数据库的中间件标准，它允许应用程序和本地或者异地的数据库进行通信，并提供了一系列的应用程序接口API，当然，在多数情况下这些API都是隐藏在
消息中间件原理与实现 10748206桂勇哲 10748210 胡栋梁 10712059 穆斌 摘要： 现今，越来越多的企业面临着各种各样的数据集成和系统整合，CORBA、DCOM、RMI等RPC中间件技术也应运而生，但由于采用RPC同步处理技术，在性能、健壮性、可扩展性上都存在着诸多缺点。而基于消息的异步处理模型采用非阻塞的调用特性，发送者将消息发送给消息服务器，消息服务器在合适的时候再将消息转发给接收者；发送和接收是异步的，发送者无需等待，二者的生命周期也可以不必相同，而且发送者可以将消息间接传给多个接收者，大大提高了程序的性能、可扩展性及健壮性，这使得异步处理模型在分布式应用上比起同步处理模型更具有吸引力。 本文首先介绍了消息中间件的原理，然后实现消息中间件的一些最重要的功能，并说明了实现方法，以及相应功能的应用，最后介绍消息中间件还可以添加哪些重要性质，以更好的进行消息服务，保证消息的一致异步有效的技术。 关键字：消息中间件，实现，点对点，发布/订阅，持久消息 一、中间件简介 1.1 中间件的定义 中间件(middleware)是基础软件的一大类，属于可复用的软件范畴。中间件在操作系统软件，网络和数据库之上，应用软件之下，总的作用是为处于自己上层的应用软件提供运行于开发的环境，帮助用户灵活、高效的开发和集成复杂的应用软件。 中间件是位于平台(硬件和操作系统)和应用之间的通用服务，这些服务具有标准的程序接口和协议。针对不同的操作系统和硬件平台，它们可以有符合接口和协议规范的多种实现。 也许很难给中间件一个严格的定义，但中间件应具有如下的一些特点： 满足大量应用的需要 运行于多种硬件和OS平台 支持分布计算，提供跨网络、硬件和OS平台的透明性的应用或服务的交互 支持标准的协议 支持标准的接口
企业消息中间件技术规范
目录 1.消息中间件概述 (3) 1.1 支持的规范和技术 (3) 1.2 消息传输 (4) 1.3 应用管理 (8) 1.4 系统配置 (9) 1.5 安全与可靠性保障 (12)
1.消息中间件概述 消息中间件是一款标准、安全、高效、集成并具备丰富功能的医用级消息中间件，基于医用消息中间件，为省级人口健康信息平台、区域医疗数据中心、医院信息平台的建设提供了坚实的基础支撑。 消息中间件主要用于医疗领域在应用程序之间传递消息，使这些消息可以在不同的网络协议、不同的计算机系统和不同的应用软件之间传递。消息中间件通过内部的可靠队列传输机制，使数据可以快速、可靠地送达接送方，在传输期间能够应对网络故障、主机宕机等各种意外情况，做到断点续传，保证数据“一次传递、可靠达到”。 1.1 支持的规范和技术 ?支持国标消息中间件软件产品技术规范（GB/T 28168-2011）； ?具备良好的跨平台能力，应用编程接口（API）支持各种运行平台，如HP-UX、IBM AIX、SUN SOLARIS、WINDOWS 、Digital UNIX、 SGI、TRU UNIX、Linux等，支持64位操作系统，并且在各平台上的 API接口一致； ?支持多种通讯链路和网络环境，如以太网、SDH、DDN、X.25、帧中继FR、拨号网络、卫星网络等，能根据网络环境对传输效率提供优化； ?支持树形拓扑结构和网状拓扑结构的网络环境； ?持多种网络协议，如TCP/IP、NETBIOS、SNA等; ?支持C、C++、C#、JAVA开发语言，提供动态库、OCX、JAVA三种API模式；支持PB、VB、VC、Delphi等开发工具。
消息中间件在数据交换中的应用研究及其面临的挑战 摘要：简要介绍了消息中间件在数据交换数据交换中的应用，论述了消息中间件所面临的挑战及应对措施：传输消息大小不受限制；同时支持Windows 2000/nt/98/ME等多种操作系统，并能通过配置充分发挥不同操作系统的性能；实现消息队列操作的回滚与提交，使消息进行多级回执；以COM形式提供MQ Clinent API。关键词：数据交换消息中间件消息队列 COM 计算机技术的不断推陈出新，带来了信息化发展的新浪潮，人们感受到了计算机及网络技术所带来的好处，于是对电子化、信息化应用的需求也越来越迫切。信息技术以其强大的渗透力，深入到社会经济生活的各个方面。在商业金融等领域，电子数据交换作为一种新的商务手段正在被广泛使用。数据交换ＥＤＩ(Electronic Data Interchange)是一种计算机应用技术，根据事先达成的协议，将信息按照一定的标准进行格式化处理，并把这些格式化的数据，通过计算机通信网络在其计算机系统之间进行交换和自动处理。作为计算机通信技术的一部分，EDI可以应用于制造业、运输业、零售业以及卫生保健和政府部门等各种经济部门之中。消息队列中间件MOM(Message－Oriented Middleware)是一种特定的中间件，它利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。1 数据交换的研究与应用现状1.1 国际发展现状及趋势西方发达国家已普遍采用EDI。据统计，1992年底世界上使用EDI的企业超过10万家，95年达到40万家。美国早在60年代初期，就在公路、铁路、海运和空运中应用EDI，而且每年还以100%的速度增长；西欧各国已将EDI应用于汽车、化工、电子、运输、保险、分销零售业中；日本已在销售、贸易、运输、和制造业中广泛使用EDI；新加坡声称95%的贸易用EDI实现。据悉，美国政府及欧洲共同体大部分国家的海关宣布，从1992年起，采用EDI方式办理海关业务，如不采用EDI方式，其手续将被推迟办理，或不再选为贸易伙伴。1996年，亚洲六个国家和地区(中国、日本、印度、马来西亚、菲律宾和中国台湾省)达成协议，将共同开发EDI系统，以便使这些国家和地区在进出口过程中能够实时地采集进出口数据，有效对客户进行管理，减少报关错误。这无疑会加快亚洲国家的EDI建设进程。在欧洲，一些大公司，包括超市连锁公司，已经开始对不开通EDI的供应商实行制裁措施(价格、处理时间、付款方式上实行歧视政策)。新加坡贸易发展局宣布：从1999年1月1日起，所有进出口贸易都必须用EDI方式申报。香港地区从2000年开始全面关闭进出口报关柜台，所有的进出口报关必须通过EDI方式。EDI的发展趋势：(1)应用EDI的行业会增多；(2)EDI 与其他信息传送技术和系统的一体化；(3)EDI技术将受Internet的冲击。1.2 国内发展现状我国也早已经开始重视和普及EDI技术，“八五”抓基础、抓试点；“九五”建立起中国贸易网(China Trade Network)，尽快实现与国际贸易网的大联通，全面推行EDI。近几年来，国内方正、中软、启宏科技、南通等软件公司在数据交换平台方面都已经快速发展。方正数码公司2002年提出了面向信息资源整合的跨地域、跨部门应用技术框架，为横跨多个政府机构的服务、监管职能的业务实现和同一机构内多个部门不同业务系统之间的数据整合提供了进行有效转换和交流的安全信息交换平台——方正易畅InfoHub。方正易畅InfoHub安全信息交换平台在信息系统中为终端节点提供安全可靠的消息传输。它采用基于XML技术的消息结构进行信息的表达，存储及传输。而作为封装在消息结构中的消息内容可以是XML格式的信息，EDI格式的信息，或者是采用用户自己定义的格式的信息。由中软网络技术股份有限公司与河南省国家税务局联合开发出《行政管理与监控考核系统》填补了国家办公软件的空白。中软股份在此基础之上建立系统框架，并通过技术框架与功能框架完美结合，使功能不断扩充与完善，完成了《行政管理与监控考核系统》。该系统已经在驻马店市国税局得到了全面的推广与实施，为提升税务行业行政管理水平和质量做出了贡
中间件消息通信技术概要 一、中间件 中间件，就是介于应用系统与系统软件之间的一类软件，它使用系统软件所提供的基础功能，衔接于应用系统的不同部分，能够达到资源共享和功能共享的目的。 消息中间件，是中间件众多产品分类中一个重要部分。它能够适用于任何需要进行网络通信的系统，负责建立网络通信的通道，进行数据或文件发送。消息中间件的一个重要作用是可以实现跨平台操作，为不同操作系统上的应用软件集成提供服务。 二、几种通信技术的比较 1、CPI-C CPI-C是一种同步对话通信模式。参加通信的一方发起一次对话，同时控制信息流动。数据既可以由发送者传递到接受者，也可以反向流动。 参加通信的两个程序需要跟踪对话的状态，如果异常发生导致连接中断，则需要发送方重建并恢复这次通话。通信双方既可以处于主从地位，也可以处于对等地位。也就是说，CPI-C既支持客户端－服务器环境，也支持对等通信方式。 虽然CPI-C在一般情况下是一种同步通信类型，但是在一定环境中，如CIC S，可以通过“临时数据队列”实现一定程度的异步。 TCP/IP，SNA都支持CPI-C。 由于需要应用程序参与错误的检测与恢复，CPI-C的编程接口相当复杂。
2、RPC RPC，即远程过程调用，也是一种同步，对话方式的类型。一个调用程序向服务器提成申请，该调用被负责通信的转接器发往远端系统。调用者与被调用者关系是固定的，很难实现对等通信。 与CPI-C一样，通信错误需要应用程序自己维护。另外在申请服务得到响应之前，服务申请者被阻隔，这不仅是应用的瓶颈所在，更有可能遭受拒绝式服务攻击。 3、MQI(Message Queue Interface) 消息队列接口为程序提供了一种异步通信方式。一个程序以一个队列作为中转与另一个程序相互通信，这个队列向对于该程序而言既可以是本地，也可以是远程。当程序A与程序B进行通信时，A只需要将消息放入一条与B相通信的队列即可，至于消息何时，以何种协议，何种方式到达程序B与A没有关系。底层的通信细节被接口所覆盖，甚至通信错误的恢复也由队列管理器代劳了，应用程序自身感受不到通信的发生。 由于通信方式和使用的协议无关，因而可以使用各种标准协议，比如TCP/I P，SNA或者其他局域网协议。 当程序A向B发送消息的时候，程序B不需要处于运行状态，消息队列负责了消息的转达。而且一个程序可以通过不同的队列与多个程序进行通信。
一．选择 1.开放系统互操作面临的异构型不包括：（D） A.不同的数据库系统 B.不同的开发工具 C.不同的操作系统 D.不同的软件开发企业 2.以下哪个模块不属于X OPen DTP模型的基本组成部分（C） A.应用程序（AP） B.资源管理器（RM） C.命名服务器（NS） D.事务管理器（TM） 3.下列属于消息访问中间件的是（C） A.SOAP （Web Service 中使用的通信服务协议） B.ORB（对象中间件） C.JMS（Java消息服务） D.ODBC（数据库访问中间件） 4.Web Service 中使用的通信服务协议是（B） A.GIOP（通用ORB互通协议） B.SOAP C.WSDL（服务说明语言） D.IIOP（互联网ORB互通协议） 5.在window平台中，COM进程内组建的文件格式一般是（D） B.exe(外) D.dll（内） 6.ORB通过使用（B ）在网络环境中找到分布式对象 A.IP地址 B.IOR C.对象名称 D.GUID 7.windows平台下，COM组件发布时一般把组建相关信息写到（B） A.环境变量 B.注册表 C.同一个文件夹的配置文件 D.命名服务器 8.分布式事务的特征不包括（C） A.隔离性 B.原子性 C.传递性 D.持久性 9.CORBA平台一般使用（D）描述分布式对象的对外服务接口 A.WSDL B.HTML C.IOR D.IDL 10.在分布式对象访问的桩/框架结构中，负责替分布式对象完成底层通信相关工作的是（D） A.客户端桩 B.构建的接口 C.分布式对象自身 D.服务器端框架（Skeleton） 11.下列那种对象不支持分布式对象的实现（C） A.EJB B.CORBA C.JDBC D.DCOM 12.所有COM组件必须要实现的接口是（A） A.IUnknown B.IDispatch C.ClassFactory https://www.doczj.com/doc/d04860556.html,omCoClass 13.J2EE中，（D）接口用于网络中定位组件和其他资源 A.JMS B.JDBC C.JTA D.JNDI 14.OMA组织定义ORB之间的互通协议为（A ） A.GIOP/IIOP B.HTTP C.TCP D.IP 15.下列属于数据库访问中间件的是（C） A.ORB B.DCOM
消息中间件及WebSphere MQ入门 文档选项 打印本页 将此页作为电子邮件发送 级别：初级 娄丽军, 软件部售前工程师 2003 年 11 月 01 日 消息队列技术是分布式应用间交换信息的一种技术。消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用程序读走。通过消息队列，应用程序可独立地执行--它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。 消息中间件概述 消息队列技术是分布式应用间交换信息的一种技术。消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用程序读走。通过消息队列，应用程序可独立地执行--它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。 在分布式计算环境中，为了集成分布式应用，开发者需要对异构网络环境下的分布式应用提供有效的通信手段。为了管理需要共享的信息，对应用提供公共的信息交换机制是重要的。设计分布式应用的方法主要有：远程过程调用(PRC)--分布式计算环境(DCE)的基础标准成分之一；对象事务监控(OTM)--基于CORBA的面向对象工业标准与事务处理(TP)监控技术的组合；消息队列(MessageQueue)--构造分布式应用的松耦合方法。 (a) 分布计算环境/远程过程调用 (DCE/RPC) RPC是DCE的成分，是一个由开放软件基金会(OSF)发布的应用集成的软件标准。RPC模仿一个程序用函数引用来引用另一程序的传统程序设计方法，此引用是过程调用的形式，一旦被调用，程序的控制则转向被调用程序。 在RPC实现时，被调用过程可在本地或远地的另一系统中驻留并在执行。当被调用程序完成处理输入数据，结果放在过程调用的返回变量中返回到调用程序。RPC完成后程序控制则立即返回到调用程序。因此RPC模仿子程序的调用/返回结构，它仅提供了Client(调用程序)和Server(被调用过程)间的同步数据交换。 (b) 对象事务监控 (OTM) 基于CORBA的面向对象工业标准与事务处理(TP)监控技术的组合，在CORBA规范中定义了：使用面向对象技术和方法的体系结构；公共的Client/Server程序设计接口；多平台间传输和翻译数据的指导方针；开发分布式应用接口的语言(IDL)等，并为构造分布的Client/Server应用提供了广泛及一致的模式。 (c) 消息队列 (Message Queue) 消息队列为构造以同步或异步方式实现的分布式应用提供了松耦合方法。消息队列的API调用被嵌入到新的或现存的应用中，通过消息发送到内存或基于磁盘的队列或从它读出而提供信息交换。消息队列可用在应用中以执行多种功能，比如要求服务、交换信息或异步处理等。中间件是一种独立的系统软件或服务程序，分布式应用系统借助这种软件在不同的技术之间共享资源，管理计算资源和网络通讯。它在计算机系统中是一个关键软件，它能实现应用的
消息中间件DotNetMQ 原文出处： https://www.doczj.com/doc/d04860556.html,/Articles/193611/DotNetMQ-A-Complete-Message-Queue-System-f or-NET#WhyNewMessBroker 介绍 在这篇文章中,我将介绍一个新的、独立的开源消息队列系统,该系统是创建在c#和.NET framework 3.5。DotNetMQ message broker,有几个功能,包括保证交付,路由、负载平衡、服务器图……等等。我将首先解释消息的概念和message brokers。然后我将检查DotNetMQ 是什么以及如何使用它。 什么是消息 消息传递是一种异步通信方式在相同或不同的机器上运行的应用程序的可靠传递。项目通过发送数据包的数据消息传达给对方。 消息可以是一个字符串,一个字节数组,一个对象……等等。通常情况下,发送者(生产商)计划创建一个消息并将消息队列和接收机(消费者)计划从队列中获取消息和处理它 发送方和接收方的程序不需要同时运行,因为消息是一个异步的过程。这就是所谓的松散耦合的沟通。 另一方面,Web服务方法调用(远程方法调用)是一种紧耦合和同步通信(可用应用程序必须运行和有效期间完整的通讯;如果脱机或Web服务方法调用期间发生错误,客户端应用程序变得异常) 图- 1:简单的两个应用程序消息传递 在上面的图中,两个应用程序通过消息队列以松散耦合的方式进行通信。如果接收方使用消息慢于发送方生成它,消息的数量将会在队列里增加。同时,接收方可以离线当发送方还在发送消息。在这种情况下,接收方在线时会接收到消息(当它加入队列时) 消息队列通常提供消息代理。Message Broker是一个独立的应用程序(服务),其他应用程序
基于MOM-面向消息中间件的SOA系统集成技术探索 一、什么是MOM？ MOM是Message-Oriented Middleware（面向消息的中间件）的缩写，MOM 的作用就是利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成，通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信，并支持多通讯协议、语言、应用程序、硬件和软件平台。目前流行的MOM产品有IBM的WebSphere MQ和基于JMS标准的系列中间件等。 二、MOM特点 MOM是一个基础架构，在基于MOM的通信环境中，通常是异步地发送和接受消息，它将应用抽象地划分为发送者和接收者，它们之间无需彼此了解，MOM最重要的作用就是将消息转发到它们的目的地。下图就是MOM的简单模型图: 从上图可以看出，为了支持消息传递的异步模型，MOM位于客户端和服务器之间，使用消息队列临时存储调用，并允许客户端和服务器分别在不同的时候运行，消息的目标端也不需要立即处理消息，并且客户端和服务器的程序之间不需要彼此知道对方的存在，它们之间不需要考虑它们之间的网络通讯复杂性。 MOM不同于普通的通讯系统的地方在于，通讯的接收和发送两端必须同时运行，并且消息必须即时处理。 三、MOM原理 MOM要实现高效可靠的消息传递机制，必须实现以下三大功能： ●实现消息的异步发送和接收，实现发布/订阅模式 ●实现消息的持久化，保证消息可靠性传输 ●优化网络传输，支持断点续传
要实现以上三大功能，需要实现消息队列，消息队列为构造以同步或异步方式实现的分布式应用提供了松耦合的方式，队列是消息的安全存放的位置，队列存储消息直到它被应用程序处理，这样的工作机制，能够保证在各种网络环境下能够可靠的传递。 在消息队列的应用上，各个不同的MOM产品应用上有所不同，例如，JMS 标准的MOM和IBM Websphere MQ实现上就有所区别。 从上图，可以看出IBM WebSphere MQ的结构和JMS结构在队列的应用上略有不同，IBM WebSphere MQ在客户机上存在有传输队列，而JMS在客户机方面不存在任何队列，所以说JMS相对于MQ而言，只是规范了消息的存取，而没有规范消息数据的传输，因为JMS客户机并不拥有存放数据的队列，所以所有发送的操作都要由应用程序来控制，JMS服务器本身不代理传输，也不保证数据在远程队列间的传输可靠性。IBM MQ通过通道与传输队列和远程队列来保证队列间的传输可靠性，IBM MQ支持客户端的断网续传，而客户端的应用程序不用做任何工作，但是，这种方式需要客户端本地安装MQ的客户端。 四、MOM通讯模式 MOM主要存在3工作模式：点对点模式、发布/订阅模式以及消息队列模式，其中，点对点模式和发布/订阅模式统称为消息传递模式。 点对点模式（Point-to-Point） 点对点模式用于消息生产者和消息消费者之间点到点的通信，是一种程序到程序的直接通信模式。消息生产者将消息发送到由某个名字标识的特定消费者，点对点消息允许客户端通过队列这个虚拟通道来同步和异步发送、接收消息，传
学校代号10536 学号0810803550 分类号TP391 密级公开 硕士学位论文 AFC系统通信中间件的研究与设计 学位申请人姓名张良春 培养单位长沙理工大学 导师姓名及职称龙鹏飞教授 学科专业计算机应用技术 研究方向人工智能及应用 论文提交日期2011年3月
学校代号：10536 学号：0810803550 密级：公开 长沙理工大学硕士学位论文 AFC系统通信中间件的研究与设计 学位申请人姓名张良春 导师姓名及职称龙鹏飞教授 培养单位长沙理工大学 专业名称计算机应用技术 论文提交日期2011年3月 论文答辩日期2011年5月 答辩委员会主席车生兵教授
Research and Design of Communication Middleware on AFC System by Zhang Liangchun B.E.( Hunan City University) 2008 A thesis submitted in partial satisfaction of the Requirements for the degree of Master of Engineering in Computer Application Technology in Changsha University of Science & Technology Supervisor Professor Long Pengfei March, 2011
长沙理工大学 学位论文原创性声明 本人郑重声明：所呈交的论文是本人在导师的指导下独立进行研究所取得的研究成果。除了文中特别加以标注引用的内容外，本论文不包含任何其他个人或集体已经发表或撰写的成果作品。对本文的研究做出重要贡献的个人和集体，均已在文中以明确方式标明。本人完全意识到本声明的法律后果由本人承担。 作者签名：日期：年月日 学位论文版权使用授权书 本学位论文作者完全了解学校有关保留、使用学位论文的规定，同意学校保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅。本人授权长沙理工大学可以将本学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。 本学位论文属于 1、保密□，在______年解密后适用本授权书。 2 （请在以上相应方框内打“√”） 作者签名：日期：年月日 导师签名：日期：年月日
消息中间件在数据交换中的应用 计算机技术的不断推陈出新，带来了消息化发展的新浪潮，人们感受到了计算机及网络技术所带来的好处，于是对电子化、信息化应用的需求也越来越迫切。信息技术以其强大的渗透力，深入到社会经济生活的各个方面。在商业金融等领域，电子数据交换作为一种新的商务手段正在被广泛使用。 数据交换EDI（Electronic Data Interchange）是一种计算机应用技术，根据事先达成的协议，将信息按照一定的标准进行格式化处理，并把这些格式化的数据，通过计算机通信网络在其计算机系统之间进行交换和自动处理。作为计算机通信技术的一部分，EDI可以应用于制造业、运输业、零售业以及卫生保健和政府部门等各种经济部门之中。 消息队列中间件MOM（Message-Oriented Middleware）是一种特定的中间件，它利用高效可靠的消息传递机制进行平台无关的数据交换，并基于数据通信来进行分布式系统的集成。 1 数据交换的研究与应用现状 1．1 国际发展现状及趋势 西方发达国家已普遍采用EDI。据统计，1992年底世界上使用EDI的企业超过10万家，95年达到40万家。美国早在60年代初期，就在公路、铁路、海运和空运中应用EDI，而且每年还以100%的速度增长；西欧各国已将EDI应用于汽车、化工、电子、运输、保险、分销零售业中；日本已在销售、贸易、运输、和制造业中广泛使用EDI；新加坡声称95%的贸易用EDI实现。据悉，美国政府及欧洲共同体大部分国家的海关宣布，从1992年起，采用 EDI 方式输海关业务，如不采用EDI方式，其手续将被推迟办理，或不再选为贸易伙伴。 1996年，亚洲六个国家和地区（中国、日本、印度、马来西亚、菲律宾和中国台湾省）达成协议，将共同开发EDI系统，以便使这些国家和地区在进出口过程中能够实时采集进出口数据，有效对客户进行管理，减少报关错误。这无疑会加快亚洲国家的EDI建设进程。 在欧洲，一些大公司，包括超市连锁公司，已经开始对不开通EDI的供应商实行制裁措施（价格、处理时间、付款方式上实行岐视政策）。 新加坡贸易发展局宣布：从1999年1月1日起，所有进出口贸易都必须用EDI方式申报。 香港地区从2000年开始全面关闭进出口报关柜台，所有的进出口报关必须通过EDI方式。 EDI的发展趋势： （1）应用EDI的行业会增多； （2）EDI与其他信息传送技术和系统的一体化； （3）EDI技术将受Internet的冲击。 1.2 国内发展现状
三个经典消息中间件的比较 对于消息中间件，绝大多数熟悉的是MQ(IBM公司出品)，这是目前使用最广泛的中间件产品。还有两个也比较流行，他们是JMS和RV。JMS即JAVA消息服务（Java Message Service）应用程序接口是一个JAVA平台中关于面向消息中间件的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信，是一个与具体平台无关的API。TIBCO Rendezvous（或称为TIBCO RV）也是一种中间件，具有发布/订阅(Publish/Subscribe)、基于主题寻址(Subject-Based Addressing) 和自定义数据信息(Self-Describing Data Messages)等专利技术功能，使不同应用平台上的信息在一个共享的虚拟总线Information Bus(TIB)上进行传输交换。 先总结一下消息中间件的功能，以上的三类中间件都实现了这些功能。 ??实现消息的异步发送接收，发布订阅，使得两端的应用解耦（减少或解除应用程序之间的耦合度）。 ??实现消息持久化机制，保证消息可靠性传输。 ??优化网络传输，支持断点续传。 １、区别之是否分布式 RV 和 MQ 都是分布式结构的，和 JMS 消息中间件的星型结构不同。分布式消息中间件的Sever在应用环境里都会部署多个，彼此互联，没有主备之分。JMS消息中间件的应用部署一般都是主备两个Server，消息的发送和接收应用平时和主Server相连，有问题时切换到备 Server，主备Server共用公共的存储设备来保存消息。 ２、区别之是否接收端主动 MQ 和 JMS 消息中间件都采用消息接收端主动接收消息的方式。消息从发送端发出后，首先会缓存到Server上，接收端应用发起一个接收消息的请求，Server 把消息作为应答返回给接收端。接收端不执行接收动作，消息就会一直在Server 上保存。RV 和这两种消息中间件都不同，使用的是发送端主动的消息推送模式。消息从发送端发出后，并不在Server上缓存，Server只做路由把消息推送给消息接收端。消息接收端只要连接上Server，订阅要接收的消息，这些消息就会源源不断地从Server那里推送过来，消息先缓存到接收客户端的队列里，接收端应用再从队列里取消息。RV的最大特点就是把一个数据生产者的数据以最快的速度推送到多个数据消费者那里。RV从金融市场数据系统的需求中产生而来，正是这些特点使得它在证券系统得到最广泛的应用。 ３、区别之是否便于一对多分布
市场上的消息中间件： mom4j mom4j是一个完全实现JMS1.1规范的消息中间件并且向下兼容JMS1.0与1.02.它提供了自己的消息处理存储使它独立于关系数据与语言,所以它的客户端可以用任何语言开发. OpenJMS OpenJMS是一个开源的Java Message Service API 1.0.2 规范的实现,它包含有以下特性： *. 它既支持点到点（point-to-point）（PTP）模型和发布/订阅（Pub/Sub）模型。 *. 支持同步与异步消息发送 *. JDBC持久性管理使用数据库表来存储消息 *. 可视化管理界面。 *. Applet支持。 *. 能够与Jakarta Tomcat这样的Servlet容器结合。 *. 支持RMI, TCP, HTTP 与SSL协议。 *. 客户端验证 *. 提供可靠消息传输、事务和消息过滤 UberMQ UberMQ完全实现了Java Message Service 规范。UberMQ是因为现有的许多JMS提供商已经违背了分布式计算的核心原则：快速与简单而开发的。 Hermes JMS 利用它提供的Swing UI可以很好的实现监控JMS providers。 ActiveMQ ActiveMQ是一个开放源码基于Apache 2.0 licenced 发布并实现了JMS 1.1。它能够与Geronimo，轻量级容器和任Java应用程序无缝的给合。 Somnifugi Somnifugi使得工作在同一个java虚拟机中的线程能实现消息互发。 MantaRay MantaRay基于peer-2-peer 技术。它具有以下特性: 1.它既支持点对点(point-to-point)的域，又支持发布/订阅(publish/subscribe)类型的域。 2.并且提供对下列类型的支持：经认可的消息传递,事务型消息的传递，一致性消息和具有持久性的订阅者支持。 3.消息过滤体制。 4.能与WebLogic and WebSphere 给合。 5.支持TCP, UDP 与HTTP传输协。
1、事务具有__原子性_、一致性、隔离性和持久 性四个特性。 2、EJB规范中定义了两种实体bean的持久性模型，分别是自管理持久性和容器管理持久性。 3、EJB的必须实现Home 接口和Remote 接口。 4、CORBA中支持服务方的动态对象调用接口称为动态框架接口。 5、微软的COM组件对象模型的IDispatch接口定义了一个函数 Invoke ，该函数能根据一个称为调度ID的整数来决定调用哪个函数。 6、CORBA事件服务中定义了事件提供者、事件消费者和事件通道三种角色，并且定义了 push 和 pull 两种数据传送模型。 1、ORB Object Request Broker，是对象请求总线，它能使对象透明地向其他本地或者远程对象发出请求或获得响应。 2、SOAP Simple Object Access Protocol，是Web服务的通信协议，用来定义消息的XML格式。 3、UDDI Universal Description Discovery and Integration 即统一描述、发现和集成协议。 4、DCOM Distributed Component Object Model，分布式组件对象模型 1、简述中间件的概念、组成结构和作用。 定义：中间件是介于应用系统和系统软件之间的一类软件，是位于操作系统和应用软件之间的一个软件层，向各种应用软件提供服务，使不同的应用进程能在屏蔽掉平台差异的情况下，通过网络互通信息。 组成结构：(1)执行环境软件（2）应用开发工具 作用：使用系统软件所提供的基础服务（功能），衔接网络上应用系统的各个部分或不同的应用，能够达到资源共享、功能共享的目的。 2、中间件的特性 （1）易用性