1. ActiveMQ简介

　　ActiveMQ是一种开源的，实现了JMS1.1规范的，面向消息(MOM)的中间件，为应用程序提供高效的、可扩展的、稳定的和安全的企业级消息通信。ActiveMQ使用Apache提供的授权，任何人都可以对其实现代码进行修改。

　　ActiveMQ的设计目标是提供标准的，面向消息的，能够跨越多语言和多系统的应用集成消息通信中间件。ActiveMQ实现了JMS标准并提供了很多附加的特性。这些附加的特性包括，JMX管理（java Management Extensions，即java管理扩展），主从管理（master/salve，这是集群模式的一种，主要体现在可靠性方面，当主中介（代理）出现故障，那么从代理会替代主代理的位置，不至于使消息系统瘫痪）、消息组通信（同一组的消息，仅会提交给一个客户进行处理）、有序消息管理（确保消息能够按照发送的次序被接受者接收）。消息优先级（优先级高的消息先被投递和处理）、订阅消息的延迟接收（订阅消息在发布时，如果订阅者没有开启连接，那么当订阅者开启连接时，消息中介将会向其提交之前的，其未处理的消息）、接收者处理过慢（可以使用动态负载平衡，将多数消息提交到处理快的接收者，这主要是对PTP消息所说）、虚拟接收者（降低与中介的连接数目）、成熟的消息持久化技术（部分消息需要持久化到数据库或文件系统中，当中介崩溃时，信息不会丢失）、支持游标操作（可以处理大消息）、支持消息的转换、通过使用Apache的Camel可以支持EIP、使用镜像队列的形式轻松的对消息队列进行监控等。

　　客户端API：ActiveMQ提供了多种客户端可访问的API，包括Java、C/C++，.NET，Perl、PHP、Python、Ruby等。当然，ActiveMQ中介必须运行在Java虚拟机中，但是使用它的客户端可以使用其他的语言来实现。

　　中介集群：多个ActiveMQ中介可以一起协同工作，来完成某项复杂的工作，这被称为网络型中介（network of brokers），这种类型的中介将会支持多种拓扑类型。

2. 为什么使用ActiveMQ　

　　在设计分布式应用程序时，应用程序间的耦合（或称集成）方式很重要。耦合意味着两个或者多个应用程序或系统的相互依赖关系。一种简单的方式是在所有的应用程序中从架构上设计他们与其他应用程序间的交叉实现。这样必然导致，一个应用程序的改变，直接导致另一个应用程序的改变。按照这种方式集成的应用是一种紧耦合的应用。一个应用的改变不会影响到其他应用的集成方式被称为是松耦合的集成方式。简单的说，松耦合应用程序集成能够更容易的处理不可预见的应用变化。

　　像COM、CORBA、DCE和EJB等应用技术使用RPC（Remote Procedural Calls，即远程过程调用）属于紧耦合技术。使用RPC，一个应用程序调用另一个应用程序，调用者必须阻塞，直到被调用者执行结束返回结果信息为止。下图给出了这种紧耦合技术的描述：

ActiveMQ简介与安装

　　许多系统架构使用RPC，并且获得了巨大的成功，但是，紧耦合的架构有着天生的缺陷。首先，这种架构将会造成系统维护管理上的巨大消费，因为，即使是很小的改动，很可能会波及到整个系统。其次，由于调用者必须阻塞式的等待被调用者返回，如果被调用者处理过程复杂，将会严重影响调用者的执行效率和资源使用率。此外，如果调用失败，整个架构即失败。

　　下图给出一种松耦合的方式，进行架构设计：

ActiveMQ简介与安装

　　应用程序1向消息中介（MOM）发送一条消息，很可能一段时间之后，应用程序2调用MOM来收取消息。任何一个应用程序都不知道对方是否存在也不需要阻塞等待。这种通信方式大大缩减了维护开销，因为对于一个应用程序的修改，会对其他应用程序影响极小。

　　ActiveMQ就是采用了上面提到的松耦合方式，因此，我们经常说应用程序发送消息仅仅是触发后忘却。应用程序将消息发送给ActiveMQ而并不关心什么时间以何种方式消息投递给接收者。同样的，消息接收者也不会关心消息来源于哪里和消息是怎样投递给ActiveMQ的。对于多语言编写的复杂应用环境中，允许客户端使用不同的编程语言甚至不同的消息包装协议。ActiveMQ作为消息的中间件，允许复杂的多语言应用程序以一种一步的方式集成和交互。所以说，ActiveMQ是一种好的，提供松散耦合的，能够为多语言交叉应用提供集成的中间件。

3. 什么情况下使用ActiveMQ

　　正如前面提到的，紧耦合应用系统存在许多问题，但是，要将紧耦合系统重构成松耦合系统是一件值得但比较繁琐的事情。使用松耦合的主要优势体现在将同步改为异步。使用异步通信，应用程序将从接收者反馈的等待中解放出来，其他的任务可以得到执行，这样提高了应用程序的效率。

　　只要是两个应用程序间需要通信的情况，都可以考虑使用JMS，不论这种通信是在本地的（就是通信的两个应用程序在同一台主机上），还是分布在不同机器上。尽管是在同一个主机上的两个应用程序需要通信也可以使用ActiveMQ。ActiveMQ可以确保消息投递成功并采用异步方式通信。

　　多个需要通信的应用程序在同一个机器上的情况下，您可以考虑在执行机上独立运行ActiveMQ或者将ActiveMQ嵌入到Java应用服务中。无论采用哪种方式，都可以确保应用程序能够发送和接收消息。您可以选择订阅模式（pub/sub）或者采用PTP（point to point）模式，这两种模式都无需等待执行反馈信息。每一个应用程序都可以简单的将消息发送给ActiveMQ，然后继续做其他的工作；应用程序无需阻塞式等待消息的返回。

　　对于分布在多台主机上的应用程序来说，可以使用多种布置策略。主要包括单一ActiveMQ实例和多ActiveMQ实例。单一ActiveMQ实例是一个简单解决方案。所有的应用程序都向同一个ActiveMQ中介发送和接收消息，这与上面提到的单机多服务雷同。单一的ActiveMQ可以布置到一台单独的主机上，也可以和其中的一些服务布置在一起。重要的是，所有的应用必须能够直接与ActiveMQ中介进行交互，所以，你必须考虑到你的网络设计。

　　第二种情况比较复杂，但是有ActiveMQ来负责远程通信，而不是应用程序自身。在这种场景下，每一个应用程序都会实例化一个ActiveMQ（无论是嵌入式的还是独立式的），应用程序从其本地的ActiveMQ发送和接收消息。之后这些ActiveMQ实例将会以一种联合的方式协同工作。消息将会基于每一个应用的要求在多个ActiveMQ中介间传递到远程的处理者。在ActiveMQ中，这种模式被称为netWork of brokers。采用这种模式对于处理大量的ActiveMQ消息是可行的，但是，我们往往需要减轻网络拓扑的复杂性，这样直接将消息投递到远程接收者的ActiveMQ是不可行的。在后一种情况下，不同的协议使用可以使ActiveMQ更轻松的传递消息。

4. ActiveMQ模型

1）点对点(队列)模型

Point to Point

在点对点或队列模型下，一个生产者向一个特定的队列发布消息，一个消费者从该队列中读取消息。这里，生产者知道消费者的队列，并直接将

消息发送到消费者的队列。这种模式被概括为：

只有一个消费者将获得消息

生产者不需要在接收者消费该消息期间处于运行状态，接收者也同样不需要在消息发送时处于运行状态。

每一个成功处理的消息都由接收者签收

2）发布/订阅模型

Publisher/Subscriber Model

发布者／订阅者模型支持向一个特定的消息主题发布消息。0或多个订阅者可能对接收来自特定消息主题的消息感兴趣。在这种模型下，发布者和

订阅者彼此不知道对方。这种模式好比是匿名公告板。这种模式被概括为：

多个消费者可以获得消息

在发布者和订阅者之间存在时间依赖性。发布者需要建立一个订阅（subscription），以便客户能够购订阅。订阅者必须保持持续的活状态以接收消息，除非订阅者建立了持久的订阅。在那种情况下，在订阅者未连接时发布的消息将在订阅者重新连接时重新发布。