转自：https://www.cnblogs.com/Survivalist/p/8094069.html
ActiveMQ基本详解与总结
基本使用可以参考https://www.cnblogs.com/zhuxiaojie/p/5564187.html 和 https://blog.csdn.net/lifetragedy/article/details/51836557
- MQ简介：
MQ全称为Message Queue, 消息队列（MQ）是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的数据（消息）来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。其中较为成熟的MQ产品有IBMWEBSPHERE MQ。 - MQ特点：
MQ的消费-生产者模型的一个典型的代表，一端往消息队列中不断的写入消息，而另一端则可以读取或者订阅队列中的消息。MQ和JMS类似，但不同的是JMS是SUN JAVA消息中间件服务的一个标准和API定义，而MQ则是遵循了AMQP协议的具体实现和产品。 - 使用场景：
在项目中，将一些无需即时返回且耗时的操作提取出来，进行了异步处理，而这种异步处理的方式大大的节省了服务器的请求响应时间，从而提高了系统的吞吐量。 - JMS简介：
JMS即Java消息服务（Java Message Service）应用程序接口是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。Java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。 - 定义：
JMS（Java Messaging Service）是Java平台上有关面向消息中间件(MOM)的技术规范，它便于消息系统中的Java应用程序进行消息交换,并且通过提供标准的产生、发送、接收消息的接口简化企业应用的开发，翻译为Java消息服务。 - 简介：
JMS是一种与厂商无关的 API，用来访问消息收发系统消息。它类似于JDBC(Java DatabaseConnectivity)：这里，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则是消息队列服务，是面向消息中间件（MOM）的最终实现，是真正的服务提供者；MQ的实现可以基于JMS，也可以基于其他规范或标准。
支持JMS的开源MQ：
目前选择的最多的是ActiveMQ。 - ActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现,尽管JMS规范出台已经是很久的事情了,但是JMS在当今的J2EE应用中间仍然扮演着特殊的地位。
主要特点：- 多种语言和协议编写客户端。语言: Java, C, C++, C#, Ruby, Perl, Python, PHP。应用协议: OpenWire,Stomp REST,WSNotification,XMPP,AMQP
- 完全支持JMS1.1和J2EE 1.4规范 (持久化,XA消息,事务)
- 对Spring的支持,ActiveMQ可以很容易内嵌到使用Spring的系统里面去,而且也支持Spring2.0的特性
- 通过了常见J2EE服务器(如 Geronimo,JBoss 4, GlassFish,WebLogic)的测试,其中通过JCA 1.5 resource adaptors的配置,可以让ActiveMQ可以自动的部署到任何兼容J2EE 1.4 商业服务器上
- 支持多种传送协议:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
- 支持通过JDBC和journal提供高速的消息持久化
- 从设计上保证了高性能的集群,客户端-服务器,点对点
- 支持Ajax
- 支持与Axis的整合
- 可以很容易得调用内嵌JMS provider,进行测试
- ActiveMQ速度非常快；一般要比jbossMQ快10倍。
- 优点：
是一个快速的开源消息组件(框架)，支持集群，同等网络，自动检测，TCP，SSL，广播，持久化，XA，和J2EE1.4容器无缝结合，并且支持轻量级容器和大多数跨语言客户端上的Java虚拟机。消息异步接受，减少软件多系统集成的耦合度。消息可靠接收，确保消息在中间件可靠保存，多个消息也可以组成原子事务。 - 缺点：
ActiveMQ默认的配置性能偏低，需要优化配置，但是配置文件复杂，ActiveMQ本身不提供管理工具；示例代码少；主页上的文档看上去比较全面，但是缺乏一种有效的组织方式，文档只有片段，用户很难由浅入深进行了解，二、文档整体的专业性太强。在研究阶段可以通过查maillist、看Javadoc、分析源代码来了解。 - ActiveMQ应用场景：
1、 不同语言应用集成
ActiveMQ 中间件用Java语言编写，因此自然提供Java客户端 API。但是ActiveMQ 也为C/C++、.NET、Perl、PHP、Python、Ruby 和一些其它语言提供客户端。在你考虑如何集成不同平台不同语言编写应用的时候，ActiveMQ 拥有巨大优势。在这样的例子中，多种客户端API通过ActiveMQ 发送和接受消息成为可能，无论使用的是什么语言。此外，ActiveMQ 还提供交叉语言功能，该功能整合这种功能，无需使用远程过程调用（RPC）确实是个优势，因为消息协助应用解耦。
2、 作为RPC的替代
使用RPC同步调用的应用十分普遍。假设大多数客户端服务器应用使用RPC，包括ATM、大多数WEB应用、信用卡系统、销售点系统等等。尽管很多系统很成功，但是转换使用异步消息可以带来很多好处，而且也不会放弃响应保证。使用同步请求的系统在规模上有较大的限制，因为请求会被阻塞，从而导致整个系统变慢。如果使用异步消息替代，可以很容易增加额外的消息接收者，使得消息能被并发消耗，从而加快请求处理。当然，你的系统应用间应该是解耦的。
3、 应用之间解耦
正如之前讨论的，紧耦合架构可以导致很多问题，尤其是如果他们是分布的。松耦合架构，在另一方面，证实了更少的依赖性，能够更好地处理不可预见的改变。不仅可以在系统中改变组件而不影响整个系统，而且组件交互也相当的简单。相比使用同步的系统（调用者必须等待被调用者返回信息），异步系统（调用方发送消息后就不管，即fire-and-forget）能够给我们带来事件驱动架构（event-driven architecture EDA）。
4、 作为事件驱动架构的主干
解耦，异步架构的系统允许通过代理器自己配置更多的客户端，内存等（即vertical scalability）来扩大系统，而不是增加更多的代理器（即horizontal scalability）。考虑如亚马逊这样繁忙的电子商务系统。当用户购买物品，事实上系统需要很多步骤去处理，包括下单，创建发票，付款，执行订单，运输等。但是用户下单后，会立即返回“谢谢你下单”的界面。不只是没有延迟，而且用户还会受到一封邮件表明订单已经收到。在亚马逊下单的例子就是一个多步处理的例子。每一步都由单独的服务去处理。当用户下单是，有一个同步的体积表单动作，但整个处理流程并不通过浏览器同步处理。相反地，订单马上被接受和反馈。而剩下的步骤就通过异步处理。如果在处理过程中出错，用户会通过邮件收到通知。这样的异步处理能提供高负载和高可用性。
5、 提高系统扩展性
很多使用事件驱动设计的系统是为了获得高可扩展性，例如电子商务，*，制造业，线上游戏等。通过异步消息分开商业处理步骤给各个应用，能够带来很多可能性。考虑设计一个应用来完成一项特殊的任务。这就是面向服务的架构（service-oriented architecture SOA）。每一个服务完成一个功能并且只有一个功能。应用就通过服务组合起来，服务间使用异步消息和最终一致性。这样的设计便可以引入一个复杂事件处理概念（complex event processing CEP）。使用CEP，部件间的交互可以被记录追踪。在异步消息系统中，可以很容易在部件间增加一层处理。
- 个人理解总结：
activeMQ是什么？
是Apache公司旗下的一个消息总线
ActiveMQ是一个开源兼容Java Message Service (JMS) 1.1面向消息的中件间. 来自Apache Software Foundation. ActiveMQ提供松耦合的应用程序架构.
activeMQ能干什么？
用来在服务与服务之间进行异步通信的 -
activeMQ优势
1.流量肖锋
2.任务异步处理
特点：可以解耦合
(学习新技术的三要素：是什么？能干什么？有什么优势？)图1：
通信模式：
1.点对点(queue)
》一个消息只能被一个服务接收
》消息一旦被消费，就会消失
》如果没有被消费，就会一直等待，直到被消费
》多个服务监听同一个消费空间，先到先得
详解：这个特点的原理是这样的，在activeMQ-
2.发布/订阅模式(topic)
》一个消息可以被多个服务接收
》订阅一个主题的消费者，只能消费自它订阅之后发布的消息。
》消费端如果在生产端发送消息之后启动，是接收不到消息的，除非生产端对消息进行了持久化(例如广播，只有当时听到的人能听到信息)图2：
注：消息是被推送和拉取的(消息生产端和消费端)，不是mq服务器去主动发送的
- 总：一些简单常用的应用场景
1.发送邮件
详解：
最经典的就是当用户注册时，我们就需要用activeMQ来做为中间件，当用户注册后，我门把用户的邮箱号和验证码等信息通过activeMQ的生产端发送到activeMQ的消息队列中，而一旦消息队列中出现了数据，我们的邮件模块通过实时的监控activeMQ的消息队列就能通过消费端获取到这个数据，染回邮件模块就会自行的去对数据进行解析，给用户发送邮件
2.发送短信
详解：
原理同发送邮件相同
3.同步索引库
详解：
为了缓解数据库的压力，我们把经常被调用的数据放入索引库中，当有请求查询时，我们会先去查询索引库，如果索引库内有数据，那么我们就不用就数据库进行查询，这样就能大大的减轻服务器的压力，可是随之而来的一个问题是，假如我们服务器内的数据已经发生了改变，而浏览用户查询数据时，因为索引库中已经有数据了，那么这样一来数据库与索引库的数据就不一致了，那么怎么解决这个问题呢？我们想到了通过用activeMQ来监听数据库的操作来实现数据库与索引库的数据同步，当后台管理员或房产经纪人对数据库的数据进行了增删改的操作时，我们通过activeMQ监听到了数据的改变，获取到被修改的数据的id，然后在另一个服务模块中通过这个数据的id去数据库先查询一把，然后根据查询结果进行判断，再去做索引库的数据同步。打个比方，如果查询结果返回的是空，就说明商品已经被删除，那么我们就可以根据数据的id去把索引库中的数据也一并删除了。
4.同步静态页面
详解：
此原理同上一个同步索引库是一个原理，目的都是为了减缓服务器的压力，我们经过数据分析发现，其实我们的一些商品详情页面的数据其实都是大同小异的，完全可以通过freemarker页面静态化的模块加上后台查询出的数据拼装成一个静态页面，而这些数据从哪来呢？我们经过讨论和研究，最后一致认为还是放在缓冲中比较好，这样一来就能大大的减轻了数据 库的压力，而另一个好处是，由于页面是纯静态页面，所以页面上的数据都是死数据，这样一来就不用像JSP动态页面那样需要和后台数据库有大量的数据交互，可以最大化的降低服务器的压力，其实这个技术已经有很多大型公司在使用了，比如淘宝，京东，网易等，我们要是细心一些就会发现，他们的页面其实就都是HTML格式的静态页面。
消息中间件的主要功能是消息的路由(Routing)和缓存(Buffering)。在AMQP中提供类似功能的两种域模型：Exchange 和 Message queue。
AMQP的更多内容可以看这里： http://www.cnblogs.com/charlesblc/p/6058799.html