ActiveMQ使用详解---相关概念

一、前言

　　公司之前使用activeMQ做过一款用于系统之间传递信息的工具，最近才正式投入生产使用，这期间出现了一些比较奇怪的问题，最终发现是没有清晰的了解activeMQ的相关配置以及一些相关概念，借着这次机会，深入的对activeMQ进行一次剖析，也希望对看官有一定的帮助~

二、正文

　　ActiveMQ：是Apache出品，最流行的，能力强劲的开源消息总线。是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现。JMS（Java消息服务）：是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。

2.1 JMS消息模式

　　2.1.1 点对点或队列模式

  　 每个消息只能有一个消费者。消息的生产者和消费者之间没有时间上的相关性，无论消费者在生产者发送消息的时候是否处于运行状态，它都可以提取消息。

      

     2.1.2 Pub/Sub 发布/订阅模式

     每个消息可以有多个消费者。生产者和消费者之间有时间上的相关性。订阅一个主题的消费者只能消费自它订阅之后发布的消息。

2.2 Broker节点

　  代表一个运行MQ的节点。

2.3 Transport传输方式

　　ActiveMQ目前支持的Transport有：VM Transport、TCP Transport、NIO Transport、SSL Transport、Peer Transport、UDP Transport、Multicast Transport、HTTP and HTTPS Transport、WebSockets Transport、Failover Transport、Fanout Transport、Discovery Transport、ZeroConf Transport等。

　　2.3.1 VM Transport

　　允许客户端和Broker直接在VM内部通信，采用的连接不是Socket连接，而是直接的方法调用，从而避免了网络传输的开销。应用场景也仅限于Broker和客户端在同一JVM环境下。

　　2.3.2 TCP Transport

　　 客户端通过TCP Socket连接到远程Broker。配置语法：

  tcp://hostname:port?transportOptions

　　2.3.3 HTTP and HTTPS Transport

　　允许客户端使用REST或者Ajax的方式进行连接。这意味着可以直接使用Javascript向ActiveMQ发送消息。

　　2.3.4 WebSockets Transport

      允许客户端通过HTML5标准的WebSockets方式连接到Broker。

　　2.3.5 Failover Transport

青龙系统MQ采用的就是这种连接方式。这种方式具备自动重新连接的机制，工作在其他Transport的上层，用于建立可靠的传输。允许配置任意多个的URI，该机制将会自动选择其中的一个URI来尝试连接。配置语法：

  failover:(tcp://localhost:61616,tcp://localhost:61617,.....)?transportOptions

　　2.3.6 Fanout Transport

      主要适用于生产消息发向多个代理。如果多个代理出现环路，可能造成消费者接收重复的消息。所以，使用该协议时，最好将消息发送给多个不相连接的代理。

2.4 Persistence持久化存储

　　2.4.1 AMQ Message Store

　　ActiveMQ 5.0 的缺省持久化存储方式。

　　2.4.2 Kaha Persistence

　　这是一个专门针对消息持久化的解决方案。它对典型的消息使用模式进行了优化。

　　2.4.3 JDBC Persistence

　　目前支持的数据库有：Apache Derby, Axion, DB2, HSQL, Informix, MaxDB, MySQL, Oracle, Postgresql, SQLServer, Sybase。

　　2.4.4 Disable Persistence

　　不应用持久化存储。

2.5 集群方案

　 2.5.1 Pure Master Slave

　　无单点故障；

　　不需要依赖共享文件系统或是共享数据库，使用 KahaDB的方式持久化存储；

　　一个Master只能带一个Slave；

　　Master工作期间，会将消息状况自动同步到Slave；

　　Master一旦崩溃，Slave自动接替其工作，已发送并尚未消费的消息继续有效；

　　Slave接手后，必须停止Slave才能重启先前的Master；

　2.5.2 Shared File System Master Slave

   2.5.3 JDBC Master Slave

　　配置上，不存在Master和Slave的区分，多个共享数据源的Broker构成JDBC Master Slave，首先抢到资源（数据库锁）的Broker成为Master，其他Broker定期尝试抢占资源，一旦Master崩溃，其他Broker抢占资源，最终只有一台抢到，立刻成为Master，之前的Master即便重启成功，也只能作为Slave等待；

三、引用

　　“正文”部分转自：http://blog.csdn.net/xiaobai51509660/article/details/32695965

      如对博文有疑问或者建议，欢迎加Q探讨：1163142850