本文最早发布与本人的博客园 （ https://www.cnblogs.com/libingbin/p/6562007.html ） ，因为项目需要，故决定出一个关于 消息队列ActiveMQ 完整的理论介绍与实际项目应用案例的系列文章！
1 业务需求描述
举例描述：
再警情通报的业务时通过发送消息界面可以选择
警情联络，和船情通报两种消息
发送方式可分为
一对一发送：部门对部门、个人对个人
一对多发送：部门对多部门、个人对多人
2 功能实现设计
基于上述需求描述，在消息传输功能实现上选用activemq进行警情联络消息传输功能的实现。
1. 基础概念
ActiveMQ：是Apache出品，最流行的，能力强劲的开源消息总线。是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现。
JMS（Java消息服务）：是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。
2. JMS消息模式
1) 点对点或队列模式
每个消息只能有一个消费者。消息的生产者和消费者之间没有时间上的相关性，无论消费者在生产者发送消息的时候是否处于运行状态，它都可以提取消息。
2) Pub/Sub 发布/订阅模式
每个消息可以有多个消费者。生产者和消费者之间有时间上的相关性。订阅一个主题的消费者只能消费自它订阅之后发布的消息。（基于我们的需求选用pub/sub）
3. Broker节点
代表一个运行MQ的节点。
4. 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等。
1) VM Transport：允许客户端和Broker直接在VM内部通信，采用的连接不是Socket连接，而是直接的方法调用，从而避免了网络传输的开销。应用场景也仅限于Broker和客户端在同一JVM环境下。
2) TCP Transport：客户端通过TCP Socket连接到远程Broker。配置语法：
tcp://hostname:port?transportOptions
3) HTTP and HTTPS Transport：允许客户端使用REST或者Ajax的方式进行连接。这意味着可以直接使用Javascript向ActiveMQ发送消息。
4) WebSockets Transport：允许客户端通过HTML5标准的WebSockets方式连接到Broker。
5) Failover Transport：青龙系统MQ采用的就是这种连接方式。这种方式具备自动重新连接的机制，工作在其他Transport的上层，用于建立可靠的传输。允许配置任意多个的URI，该机制将会自动选择其中的一个URI来尝试连接。配置语法：
failover:(tcp://localhost:61616,tcp://localhost:61617,.....)?transportOptions
6) Fanout Transport：主要适用于生产消息发向多个代理。如果多个代理出现环路，可能造成消费者接收重复的消息。所以，使用该协议时，最好将消息发送给多个不相连接的代理。
5. Persistence持久化存储
1) AMQ Message Store
ActiveMQ 5.0 的缺省持久化存储方式。
2) Kaha Persistence
这是一个专门针对消息持久化的解决方案。它对典型的消息使用模式进行了优化。
3) JDBC Persistence
目前支持的数据库有：Apache Derby, Axion, DB2, HSQL, Informix, MaxDB, MySQL, Oracle, Postgresql, SQLServer, Sybase。
4) Disable Persistence
不应用持久化存储。
6. 集群方案
1. Master / Slave
1.1. Pure Master Slave
无单点故障；
不需要依赖共享文件系统或是共享数据库，使用 KahaDB的方式持久化存储；
一个Master只能带一个Slave；
Master工作期间，会将消息状况自动同步到Slave；
Master一旦崩溃，Slave自动接替其工作，已发送并尚未消费的消息继续有效；
Slave接手后，必须停止Slave才能重启先前的Master；
1.2. Shared File System Master Slave
1.3. JDBC Master Slave
配置上，不存在Master和Slave的区分，多个共享数据源的Broker构成JDBC Master Slave；
首先抢到资源（数据库锁）的Broker成为Master，其他Broker定期尝试抢占资源；
一旦Master崩溃，其他Broker抢占资源，最终只有一台抢到，立刻成为Master，之前的Master即便重启成功，也只能作为Slave等待。
来源：oschina
链接：https://my.oschina.net/u/3375733/blog/2051649