ActiveMQ是一种开源的,实现了JMS1.1规范的,面向消息(MOM)的中间件,为应用程序提供高效的、可扩展的、稳定的和安全的企业级消息通讯。ActiveMQ使用Apache提供的受权,任何人均可以对其实现代码进行修改。html
ActiveMQ的设计目标是提供标准的,面向消息的,可以跨越多语言和多系统的应用集成消息通讯中间件。ActiveMQ实现了JMS标准并提供了不少附加的特性。这些附加的特性包括,JMX管理(java Management Extensions,即java管理扩展),主从管理(master/salve,这是集群模式的一种,主要体如今可靠性方面,当主中介(代理)出现故障,那么从代理会替代主代理的位置,不至于使消息系统瘫痪)、消息组通讯(同一组的消息,仅会提交给一个客户进行处理)、有序消息管理(确保消息可以按照发送的次序被接受者接收)。消息优先级(优先级高的消息先被投递和处理)、订阅消息的延迟接收(订阅消息在发布时,若是订阅者没有开启链接,那么当订阅者开启链接时,消息中介将会向其提交以前的,其未处理的消息)、接收者处理过慢(可使用动态负载平衡,将多数消息提交处处理快的接收者,这主要是对PTP消息所说)、虚拟接收者(下降与中介的链接数目)、成熟的消息持久化技术(部分消息须要持久化到数据库或文件系统中,当中介崩溃时,信息不会丢失)、支持游标操做(能够处理大消息)、支持消息的转换、经过使用Apache的Camel能够支持EIP、使用镜像队列的形式轻松的对消息队列进行监控等。java
客户端API:ActiveMQ提供了多种客户端可访问的API,包括Java、C/C++,.NET,Perl、PHP、Python、Ruby等。固然,ActiveMQ中介必须运行在Java虚拟机中,可是使用它的客户端可使用其余的语言来实现。数据库
中介集群:多个ActiveMQ中介能够一块儿协同工做,来完成某项复杂的工做,这被称为网络型中介(network of brokers),这种类型的中介将会支持多种拓扑类型。apache
在设计分布式应用程序时,应用程序间的耦合(或称集成)方式很重要。耦合意味着两个或者多个应用程序或系统的相互依赖关系。一种简单的方式是在全部的应用程序中从架构上设计他们与其余应用程序间的交叉实现。这样必然致使,一个应用程序的改变,直接致使另外一个应用程序的改变。按照这种方式集成的应用是一种紧耦合的应用。一个应用的改变不会影响到其余应用的集成方式被称为是松耦合的集成方式。简单的说,松耦合应用程序集成可以更容易的处理不可预见的应用变化。编程
像COM、CORBA、DCE和EJB等应用技术使用RPC(Remote Procedural Calls,即远程过程调用)属于紧耦合技术。使用RPC,一个应用程序调用另外一个应用程序,调用者必须阻塞,直到被调用者执行结束返回结果信息为止。下图给出了这种紧耦合技术的描述:安全
许多系统架构使用RPC,而且得到了巨大的成功,可是,紧耦合的架构有着天生的缺陷。首先,这种架构将会形成系统维护管理上的巨大消费,由于,即便是很小的改动,极可能会波及到整个系统。其次,因为调用者必须阻塞式的等待被调用者返回,若是被调用者处理过程复杂,将会严重影响调用者的执行效率和资源使用率。此外,若是调用失败,整个架构即失败。网络
下图给出一种松耦合的方式,进行架构设计:架构
应用程序1向消息中介(MOM)发送一条消息,极可能一段时间以后,应用程序2调用MOM来收取消息。任何一个应用程序都不知道对方是否存在也不须要阻塞等待。这种通讯方式大大缩减了维护开销,由于对于一个应用程序的修改,会对其余应用程序影响极小。异步
ActiveMQ就是采用了上面提到的松耦合方式,所以,咱们常常说应用程序发送消息仅仅是触发后忘却。应用程序将消息发送给ActiveMQ而并不关心什么时间以何种方式消息投递给接收者。一样的,消息接收者也不会关心消息来源于哪里和消息是怎样投递给ActiveMQ的。对于多语言编写的复杂应用环境中,容许客户端使用不一样的编程语言甚至不一样的消息包装协议。ActiveMQ做为消息的中间件,容许复杂的多语言应用程序以一种一步的方式集成和交互。因此说,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更轻松的传递消息。
1)点对点(队列)模型
Point to Point
在点对点或队列模型下,一个生产者向一个特定的队列发布消息,一个消费者从该队列中读取消息。这里,生产者知道消费者的队列,并直接将
消息发送到消费者的队列。这种模式被归纳为:
只有一个消费者将得到消息
生产者不须要在接收者消费该消息期间处于运行状态,接收者也一样不须要在消息发送时处于运行状态。
每个成功处理的消息都由接收者签收
2)发布/订阅模型
Publisher/Subscriber Model
发布者/订阅者模型支持向一个特定的消息主题发布消息。0或多个订阅者可能对接收来自特定消息主题的消息感兴趣。在这种模型下,发布者和
订阅者彼此不知道对方。这种模式比如是匿名公告板。这种模式被归纳为:
多个消费者能够得到消息
在发布者和订阅者之间存在时间依赖性。发布者须要创建一个订阅(subscription),以便客户可以购订阅。订阅者必须保持持续的活状态以接收消息,除非订阅者创建了持久的订阅。在那种状况下,在订阅者未链接时发布的消息将在订阅者从新链接时从新发布。
ActiveMQ官方网站:http://activemq.apache.org/
我选择的是apache-activemq-5.10.0-bin.tar.gz版本,放在/usr/local目录下
(2)解压
tar -xzvf apache-activemq-5.10.0-bin.tar.gz
(3)ActiveMQ全部的配置都在conf目录下
(4)进入bin目录启动
(1)ActiveMQ简介:http://www.cnblogs.com/kgdxpr/p/3381974.html
(2)ActiveMQ P2P版的HelloWorld:https://my.oschina.net/chaun/blog/404615