MQ简介：
MQ全称为Message Queue,消息队列（MQ）是一种应用程序的通信方法。应用程序通过写和检索出入列的针对应用程序的数据（消息）来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求.。
MQ特点：
MQ的消费-生产者模型的一个典型的代表，一端往消息队列中不断的写入消息，而另一端则可以读取或订阅列队中的消息。MQ和JMS类似，但不同的是JMS是SUN JAVA消息中间件服务的一个标准和API定义，而MQ则是遵循AMQP协议的具体实现和产品。
MQ产品的分类：
RabbitMQ
是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了一个经纪人(Broker)构架，这意味着消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。
Redis
是一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。
|
|
入队 |
出队 |
||||||
|
|
128B |
512B |
1K |
10K |
128B |
512B |
1K |
10K |
|
Redis |
16088 |
15961 |
17094 |
25 |
15955 |
20449 |
18098 |
9355 |
|
RabbitMQ |
10627 |
9916 |
9370 |
2366 |
3219 |
3174 |
2982 |
1588 |
ZeroMQ
号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演了这个服务角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。其中，Twitter的Storm中使用ZeroMQ作为数据流的传输。
ActiveMQ
是Apache下的一个子项目。 类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、Java、.Net,、Python、 Php、 Ruby等。
Jafka/Kafka
Kafka是Apache下的一个子项目，是一个高性能跨语言分布式Publish/Subscribe消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现复杂均衡；支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制来统一了在线和离线的消息处理，这一点也是本课题所研究系统所看重的。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。
其他一些队列列表HornetQ、Apache Qpid、Sparrow、Starling、Kestrel、Beanstalkd、Amazon SQS就不再一一分析。
使用场景：
JMS即java消费服务应用程序接口是一个java平台中关于面向消息中间件的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通讯。java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。
定义：
JMS是java平台上有关面向消息中间件的技术规范，它便于消息系统中的java应用程序进行消息交换，并且通过提供标准的产生，发送，接受消息的接口简化企业应用的开发。
简介：
JMS是一种与厂商无关的API，用来访问消息收发系统。它类似于JDBC：这里，JDBC是可以用来访问许多不同关系数据库的API，而JMS则提供同样与厂商无关的访问方法，以访问消息收发服务。许多厂商目前都支持JMS，包括IBM的MQSeries,BEA的Weblogic JMS service和Progress的SonicMQ。JMS能够通过消息收发服务从一个JMS客户机向另一个JMS客户机发送消息。消息是JMS中的一种类型对象，有两部分组成：报头和消息主体。报头由路由信息以及有关该消息的元数据组成。消息主体则携带着应用程序的数据或有效负载。根据有效负载的类型来划分，可以将消息分为几种类型，它们分别携带：简单文本（TextMessage），可序列化的对象（ObjectMessage），属性集合（MapMessage），字节流（BytesMessage），原始值流（StreamMessage），还有无有效负载的消息（Message）。
JMS和MQ的关系：
JMS是一个用于提供消息服务的技术规范，它制定了在整个消息服务提供过程中的所有数据结构个交互流程。而MQ则是消息队列服务，是面向消息中间件的最终实现，是真正的服务提供者；消息中间件的实现可以基于JMS，也可以基于其他规范或标准。
支持JMS的开源MQ：
ActiveMQ是Apache出品，最流行的，能力强劲的开源消息总线，ActiveMQ是一个完全支持JMS1.1和J2EE1.4规范的JMS Provider实现。
主要特点：
1.多种语言和协议编写客户端。语言：java，C，C++，C#，Ruby，Perl，Python，PHP；
2.完全支持JMS1.1和J2EE1.4规范（持久化，XA消息，事务）；
3.对spring的支持，ActiveMQ可以很容易内嵌到使用spring的系统里去，而且也支持spring2.0的特性；
4.通过了常见的J2EE服务器的测试，其中通过JCA1.5 resource adaptors的配置，可以让ActiveMQ可以自动部署到任何兼容J2EE1.4商业服务器上；
5.支持多种传送协议：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA；
6.支持通过JDBC和journal提供高速的消息持久化；
7.从设计上保证了高性能的集群，客户端-服务器，点对点；
8.支持ajax；
9.支持axis的整合；
10.可以很容易得调用内嵌JMS provider进行测试；
11.ActiveMQ速度非常快，一般要比JbossMQ快10倍；
优点：
是一个快速的开源消息组件，支持集群，自动检测，TCP，SSL，广播，持久化，XA和J2EE1.4容器无缝结合，并且支持轻量级容器和大多数跨语言客户端上的java虚拟机。消息异步接收，减少软件多系统集成的耦合度。消息可靠接收，确保消息在中间件可靠保存，多个消息也可以组成原子事务。
缺点：
ActiveMQ默认的配置性能偏低，需要优化配置，但是配置文件复杂，ActiveMQ本身不提供管理工具；实例代码少；主页上的文档看上去比较全面，但是缺乏一种有效的组织方式，文档只有片段，用户很难由浅入深进行了解。
ActiveMQ应用场景：
1.不同语言应用集成
ActiveMQ中间件用java语言编写，因此自然提供java客户端API。但是ActiveMQ也是为C/C++、.NET、Perl、PHP、Python、Ruby和一些其他语言提供客户端。在你考虑如何集成不同平台不同语言编写应用的时候，ActiveMQ拥有巨大的优势。多种客户端API通过ActiveMQ发送和接收消息成为可能，无论使用的是什么语言。此外，ActiveMQ还提供交叉语言功能，该功能整个这种功能，无需使用远程过程调用。因为消息协助应用解耦。
2.作为RPC的替代
使用RPC同步调用的应用十分普遍。使用同步请求的系统在规模上有较大的限制，因为请求会被阻塞，从而导致整个系统变慢。如果使用异步消息替代，可以很容易增加额外的消息接收者，使得消息能被并发消耗，从而加快了请求处理。
3.应用之间解耦
紧耦合架构可以导致很多问题，尤其是如果他们是分布的。松耦合架构，在另一方面，证实了更少的依赖性，能够更好地处理不可预见的改变，不仅可以在系统中改变组价而不影响整个系统，而且组件交互也相当简单。相比使用同步系统，异步系统能够给我们带来事件驱动架构
4.作为事件驱动架构的主干
解耦，异步架构的系统允许通过代理器自己配置更多的客户端，内存等来扩大系统，而不是增加更多的代理器。
5.提高系统扩展性
很多使用事件驱动设计的系统是为了获得高可扩展性。每一个服务完成一个功能并且只有一个功能。应用就通过服务组合起来，服务之间使用异步消息和最终一致性。这样的设计便可以引入一个复杂事件处理概念。使用CEP，部件之间的交互可以被记录追踪。在异步消息系统中，可以很容易在部件间增加一层处理。
ActiveMQ通讯方式：
1.点对点（P2P）
1.1 p2p模式图
1.2 概念
1.2.1 消息队列（Queue）
1.2.2 发送者（Sender）
1.2.3 接收者（Receiver）
1.2.4 每个消息都被发送到一个特定的队列中，接受者从队列中获取消息。队列保留着消息，直到它们被消费或超市；
1.3 特点
1.3.1 每个消息只有一个消费者；
1.3.2 发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后，不管接收者有没有正在运行，它不会影响消息被发送到队列；
1.3.3 接收者在成功接收消息之后需向队列应答成功
2.发布与订阅（Pub/Sub）
2.1 模式图
2.2 概念
2.2.1 主题（Topic）
2.2.2 发布者（Publisher）
2.2.3 订阅者（Subscriber）
2.2.4 客户端将消息发送到主题。多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者；
2.3 特点
2.3.1 每个消息可以有多个消费者；
2.3.2 发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息，而且为了消费消息，订阅者必须保持运行的状态；
2.3.3 为了缓和这样严格的时间相关性，JMS允许订阅者创建一个可持久化的订阅。这样，及时订阅者没有被激活（运行），它也能接收到发布者的消息；