“来，根据你的了解说下 ActiveMQ 是什么。”
“这个简单，ActiveMQ 是一个 MOM，具体来说是一个实现了 JMS 规范的系统间远程通信的消息代理。它……”
“等等，先解释下什么是 MOM。”
“好。MOM 就是面向消息中间件（Message-oriented middleware），是用于以分布式应用或系统中的异步、松耦合、可靠、可扩展和安全通信的一类软件。MOM 的总体思想是它作为消息发送器和消息接收器之间的消息中介,这种中介提供了一个全新水平的松耦合。”
“JMS呢？”
成小胖是个追求极致的人，为了解释得更通俗易懂，索性搬来一块白板边画边说。
“JMS 叫做 Java 消息服务（Java Message Service）,是 Java 平台上有关面向 MOM 的技术规范，旨在通过提供标准的产生、发送、接收和处理消息的 API 简化企业应用的开发，类似于 JDBC 和关系型数据库通信方式的抽象。”
- Provider：纯 Java 语言编写的 JMS 接口实现（比如 ActiveMQ 就是）
- Domains：消息传递方式，包括点对点（P2P）、发布/订阅（Pub/Sub）两种
- Connection factory：客户端使用连接工厂来创建与 JMS provider 的连接
- Destination：消息被寻址、发送以及接收的对象
“你来说说这其中 P2P 和 Pub/Sub 的区别吧”
P2P （点对点）消息域使用 queue 作为 Destination，消息可以被同步或异步的发送和接收，每个消息只会给一个 Consumer 传送一次。
Consumer 可以使用 MessageConsumer.receive() 同步地接收消息，也可以通过使用MessageConsumer.setMessageListener() 注册一个 MessageListener 实现异步接收。
多个 Consumer 可以注册到同一个 queue 上，但一个消息只能被一个 Consumer 所接收，然后由该 Consumer 来确认消息。并且在这种情况下，Provider 对所有注册的 Consumer 以轮询的方式发送消息。
Pub/Sub（发布/订阅，Publish/Subscribe）消息域使用 topic 作为 Destination，发布者向 topic 发送消息，订阅者注册接收来自 topic 的消息。发送到 topic 的任何消息都将自动传递给所有订阅者。接收方式（同步和异步）与 P2P 域相同。
除非显式指定，否则 topic 不会为订阅者保留消息。当然，这可以通过持久化（Durable）订阅来实现消息的保存。这种情况下，当订阅者与 Provider 断开时，Provider 会为它存储消息。当持久化订阅者重新连接时，将会受到所有的断连期间未消费的消息。
“嗯，总结的很不错，上面的这些知识是学习 ActiveMQ 的理论基础，是必须要掌握的。”
“既然 JMS 是一个通用的规范，那么使用它创建应用程序肯定也有一个通用的步骤吧？”
“有的有的。要不您来说说这个通用步骤？就当我考考您，哈哈！”
答案：
- 获取连接工厂
- 使用连接工厂创建连接
- 启动连接
- 从连接创建会话
- 获取 Destination
- 创建 Producer，或
- 创建 Producer
- 创建 message
- 创建 Consumer，或发送或接收message发送或接收 message
- 创建 Consumer
- 注册消息监听器（可选）
- 发送或接收 message
- 关闭资源（connection, session, producer, consumer 等)
“现在你手写上面步骤对应的代码实现吧”
public class JMSDemo { ConnectionFactory connectionFactory; Connection connection; Session session; Destination destination; MessageProducer producer; MessageConsumer consumer; Message message; boolean useTransaction = false; try { Context ctx = new InitialContext(); connectionFactory = (ConnectionFactory) ctx.lookup("ConnectionFactoryName"); //使用ActiveMQ时：connectionFactory = new ActiveMQConnectionFactory(user, password, getOptimizeBrokerUrl(broker)); connection = connectionFactory.createConnection(); connection.start(); session = connection.createSession(useTransaction, Session.AUTO_ACKNOWLEDGE); destination = session.createQueue("TEST.QUEUE"); //生产者发送消息 producer = session.createProducer(destination); message = session.createTextMessage("this is a test"); //消费者同步接收 consumer = session.createConsumer(destination); message = (TextMessage) consumer.receive(1000); System.out.println("Received message: " + message); //消费者异步接收 consumer.setMessageListener(new MessageListener() { @Override public void onMessage(Message message) { if (message != null) { doMessageEvent(message); } } }); } catch (JMSException e) { ... } finally { producer.close(); session.close(); connection.close(); }} “还算不赖哈~ JMS 通用的规范咱们都聊完了，下面就来聊点 ActiveMQ 更具体点的东西咯。”
“要不我先基于自己的学习讲讲 ActiveMQ 的存储，您看看我哪里讲的不对或者遗漏的，可好？”
“行，那就开始吧。”
ActiveMQ 在 queue 中存储 Message 时，采用先进先出顺序（FIFO）存储。同一时间一个消息被分派给单个消费者，且只有当 Message 被消费并确认时，它才能从存储中删除。
对于持久化订阅者来说，每个消费者获得 Message 的副本。为了节省存储空间，Provider 仅存储消息的一个副本。持久化订阅者维护了指向下一个 Message 的指针，并将其副本分派给消费者。以这种方式实现消息存储，因为每个持久化订阅者可能以不同的速率消费 Message，或者它们可能不是全部同时运行。此外，因每个 Message 可能存在多个消费者，所以在它被成功地传递给所有持久化订阅者之前，不能从存储中删除。
“很好，上面这段知识非常重要。其实我们可以通过表格来更清晰地展示”
| 消息类型 | 是否持久化 | 是否有Durable订阅者 | 消费者延迟启动时，消息是否保留 | Broker重启时，消息是否保留 |
| Queue | N | - | Y | N |
| Queue | Y | - | Y | Y |
| Topic | N | N | N | N |
| Topic | N | Y | Y | N |
| Topic | Y | N | N | N |
| Topic | Y | Y | Y | Y |
虽然对以上特性做过实践对比，但是并没有想到去画一个表格出来使对比更加清晰易懂。
“你再说说 ActiveMQ 常用的存储方式吧。”
1.KahaDB
ActiveMQ 5.3 版本起的默认存储方式。KahaDB存储是一个基于文件的快速存储消息，设计目标是易于使用且尽可能快。它使用基于文件的消息数据库意味着没有第三方数据库的先决条件。
要启用 KahaDB 存储，需要在 activemq.xml 中进行以下配置：
2.AMQ
与 KahaDB 存储一样，AMQ存储使用户能够快速启动和运行，因为它不依赖于第三方数据库。AMQ 消息存储库是可靠持久性和高性能索引的事务日志组合，当消息吞吐量是应用程序的主要需求时，该存储是最佳选择。但因为它为每个索引使用两个分开的文件，并且每个 Destination 都有一个索引，所以当你打算在代理中使用数千个队列的时候，不应该使用它。
3.JDBC
选择关系型数据库，通常的原因是企业已经具备了管理关系型数据的专长，但是它在性能上绝对不优于上述消息存储实现。事实是，许多企业使用关系数据库作为存储，是因为他们更愿意充分利用这些数据库资源。
4.内存存储
内存消息存储器将所有持久消息保存在内存中。在仅存储有限数量 Message 的情况下，内存消息存储会很有用，因为 Message 通常会被快速消耗。在 activema.xml 中将 broker 元素上的 persistent 属性设置为 false 即可。
“下面就根据我在工作中的经历，给你讲讲 ActiveMQ 的部署模式。”
1.单例模式
这个就不啰嗦了，略过。
2.无共享主从模式
这是最简单的 Provider 高可用性的方案，主从节点分别存储 Message。从节点需要配置为连接到主节点，并且需要特殊配置其状态。
所有消息命令（消息，确认，订阅，事务等）都从主节点复制到从节点，这种复制发生在主节点对其接收的任何命令生效之前。并且，当主节点收到持久消息，会等待从节点完成消息的处理（通常是持久化到存储），然后再自己完成消息的处理（如持久化到存储）后，再返回对 Producer 的回执。
从节点不启动任何传输，也不能接受任何客户端或网络连接，除非主节点失效。当主节点失效后，从节点自动成为主节点，并且开启传输并接受连接。这是，使用 failover 传输的客户端就会连接到该新主节点。
Broker 连接配置如下：
failover://(tcp://masterhost:61616,tcp://slavehost:61616)?randomize=false
但是，这种部署模式有一些限制，
- 主节点只会在从节点连接到主节点时复制其活动状态，因此当从节点没有连接上主节点之前，任何主节点处理的 Message 或者消息确认都会在主节点失效后丢失。不过你可以通过在主节点设置 waitForSlave 来避免，这样就强制主节点在没有任何一个从节点连接上的情况下接受连接。
- 就是主节点只能有一个从节点，并且从节点不允许再有其他从节点。
- 把正在运行的单例配置成无共享主从，或者配置新的从节点时，你都要停止当前服务，修改配置后再重启才能生效。
在可以接受一些故障停机时间的情况下，可以使用该模式。
从节点配置：
此外，可以配置 shutdownOnMasterFailure 项，表示主节点失效后安全关闭，保证没有消息丢失，允许管理员维护一个新的从节点。
3.共享存储主从模式
允许多个代理共享存储，但任意时刻只有一个是活动的。这种情况下，当主节点失效时，无需人工干预来维护应用的完整性。另外一个好处就是没有从节点数的限制。
有两种细分模式：
（1）基于数据库
它会获取一个表上的排它锁，以确保没有其他 ActiveMQ 代理可以同时访问数据库。其他未获得锁的代理则处于轮询状态，就会被当做是从节点，不会开启传输也不会接受连接。
需要获取分布式共享文件锁，linux 系统下推荐用 GFS2。
“再讲讲我所理解的 ActiveMQ 的网络连接”
1.代理网络
支持将 ActiveMQ 消息代理链接到不同拓扑，这就是被人们熟知的代理网络。
ActiveMQ 网络使用存储和转发的概念，其中消息总是存储在本地代理中，然后通过网络转发到另一个代理。
如果希望网络是双向的，您可以使用网络连接器将远程代理配置为指向本地代理，或将网络连接器配置为双工，以便双向发送消息。
注意，配置的顺序很重要：
1.网络连接——需要在消息存储前建立好连接，对应 networkConnectors 元素
2.消息存储——需要在传输前配置好，对应 persistenceAdapter 元素 3.消息传输——最后配置，对应 transportConnectors 元素2.网络发现
（1）动态发现
使用多播来支持网络动态发现。配置如下：
其中，multicast:// 中的默认名称表示该代理所属的组。因此使用此方式时，强烈推荐你使用一个独特的组名，避免你的代理连接到其他不相关代理。
（2）静态发现
静态发现接受代理 URI 列表，并将尝试按列表中确定的顺序连接到远程代理。
相关配置如下：
- initialReconnectDelay：默认值1000，表示尝试连接前的时延。
- maxReconnectDelay：默认值30000，表示连接失败后到重新建立连接之间的时延，仅在 useExponentialBackOff 启用时生效。
- useExponentialBackOff：默认值 true，如果启用，表示每次失败后增加重建连接的时延。
- backOffMultiplier：默认值2，表示启用 useExponentialBackOff 后每次的时延增量需要注意的是，网络连接将始终尝试建立到远程代理的连接。
需要注意的是，网络连接将始终尝试建立到远程代理的连接。
（3）多连接场景
上面这些知识点虽然看起来很少，但却花了很多时间看了很多英文资料，同时反复实践才理解透的。
原文地址：