ActiveMQ实战指南：从JMS核心到Spring Boot集成与高可用集群部署-育师

1. 从消息队列到ActiveMQ：为什么它依然是你的可靠选择

在微服务架构和分布式系统成为主流的今天，服务间的解耦与异步通信变得至关重要。消息队列（Message Queue, MQ）作为这一领域的核心组件，承担着削峰填谷、异步处理、应用解耦的重任。市面上有RabbitMQ、Kafka、RocketMQ等众多选择，各有侧重。但今天，我想和你深入聊聊一个在Java生态中有着深厚历史、稳定可靠，并且在许多企业级应用中依然扮演着关键角色的“老兵”——ActiveMQ。

ActiveMQ是Apache基金会下的一个开源项目，它完全实现了JMS（Java Message Service）规范。这意味着，如果你熟悉JMS API，那么上手ActiveMQ几乎是零成本的。它的核心价值在于其稳定性和对JMS标准的完整支持，这使得它在需要强事务保证、复杂消息路由（如Topic/Queue）、以及与企业级Java应用（如Spring、J2EE应用服务器）无缝集成的场景中，依然是一个值得信赖的选项。尽管在一些需要极高吞吐量（如日志处理）的场景下，Kafka可能更胜一筹，但在需要严格的消息顺序、事务性、以及丰富的消息协议支持（如STOMP、AMQP、MQTT）的复杂业务系统中，ActiveMQ的成熟度和功能完备性使其依然占据一席之地。

接下来的内容，我将从一个有多年使用经验的开发者角度，带你从零开始，不仅掌握ActiveMQ的安装、基础使用，更会深入到它的高级特性、性能调优以及在实际项目中容易踩到的“坑”。无论你是正在为项目选型，还是需要维护一个现有的ActiveMQ系统，这篇文章都能为你提供一份详实的参考。

2. 环境搭建与快速启动：避开安装中的那些“小陷阱”

2.1 版本选择与下载

ActiveMQ的版本迭代相对稳定，对于生产环境，我强烈建议选择最新的稳定版（Stable Release），而不是开发版（Snapshot）。你可以直接从Apache官网的下载页面获取。以经典的ActiveMQ 5.x系列为例，apache-activemq-5.17.6-bin.zip（对应Windows）或.tar.gz（对应Linux/macOS）是常见的选择。这里有一个小经验：下载后务必核对文件的SHA512或PGP签名，这是确保文件完整性和安全性的第一步，很多人在内网部署时会忽略这一点，直接使用来路不明的包，存在潜在风险。

2.2 单机部署与启动

解压下载的压缩包后，你会看到一个结构清晰的目录。核心的启动脚本位于bin目录下。

Linux/macOS: 进入bin目录，执行./activemq start即可在后台启动。查看控制台日志，可以执行./activemq console，这会将日志输出到当前终端，非常适合调试。
Windows: 进入bin\win64目录（根据你的系统架构选择win64或win32），双击activemq.bat即可。

启动成功后，默认的控制台管理页面地址是http://localhost:8161/admin。默认的用户名和密码都是admin。这里是你需要修改的第一个重要配置：出于安全考虑，你必须在第一时间修改默认密码。配置文件位于conf/jetty-realm.properties。用文本编辑器打开，找到admin: admin, admin这一行，将其修改为admin: <你的新密码>, admin。修改后需要重启ActiveMQ生效。

注意：很多开发者在测试时喜欢用默认密码，并且忘记修改，一旦将测试环境暴露在公网或内部不安全的网络，就等于敞开了大门。这是一个非常低级但后果可能很严重的安全隐患。

2.3 管理控制台初探

登录管理控制台后，你会看到几个关键面板：

Queues: 点对点消息队列列表。这里可以查看队列中的消息数量（Number of Pending Messages）、消费者数量（Number of Consumers），并执行发送测试消息、清除队列等操作。
Topics: 发布/订阅主题列表。功能类似队列。
Subscribers: 主题的订阅者详情。
Connections: 当前所有活跃的连接，包括连接ID、客户端IP、协议等。
Scheduled: 延迟或定时发送的消息。

这个控制台不仅是监控工具，更是强大的调试工具。当你的程序发送或消费消息出现问题时，第一时间来这里看看消息是否成功进入队列、消费者是否在线，往往能快速定位问题方向。

3. 核心概念与基础API实战：理解JMS模型是根本

在写第一行代码之前，我们必须清晰理解JMS的两个核心消息传递模型，这决定了你整个应用的设计模式。

3.1 点对点（Queue） vs 发布/订阅（Topic）

这是最容易混淆，也最需要理解透彻的一点。

Queue（队列）：经典的点对点模型。消息生产者（Producer）将消息发送到一个特定的队列。消息消费者（Consumer）从该队列中取出消息进行消费。一条消息只能被一个消费者消费一次。消费成功后，消息会从队列中移除。如果多个消费者监听同一个队列，ActiveMQ会采用轮询（Round-Robin）的方式将消息分发给它们，实现简单的负载均衡。Queue模式适用于任务分发、订单处理等场景，确保每个任务只被处理一次。
Topic（主题）：发布/订阅模型。消息生产者将消息发布到一个主题。所有订阅（Subscribe）了这个主题的消费者，都会收到该消息的一份副本。一条消息可以被多个消费者消费。消费者必须在消息发布前订阅主题，否则将收不到历史消息（除非使用持久化订阅，见高级篇）。Topic模式适用于广播通知、事件驱动架构，比如系统配置更新、新闻推送等。

3.2 使用原生JMS API进行开发

虽然Spring Boot极大简化了集成，但理解原生API有助于你洞悉底层原理，在遇到复杂问题时能更从容。下面是一个最简化的Queue模式生产者示例：

import javax.jms.*; import org.apache.activemq.ActiveMQConnectionFactory; public class SimpleQueueProducer { private static final String BROKER_URL = "tcp://localhost:61616"; private static final String QUEUE_NAME = "TEST.QUEUE"; public static void main(String[] args) throws JMSException { // 1. 创建连接工厂 ConnectionFactory connectionFactory = new ActiveMQConnectionFactory(BROKER_URL); // 2. 创建连接 Connection connection = connectionFactory.createConnection(); connection.start(); // 切记要start！ // 3. 创建会话 (参数：是否启用事务， 确认模式) Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); // 4. 创建目的地（队列） Destination destination = session.createQueue(QUEUE_NAME); // 5. 创建消息生产者 MessageProducer producer = session.createProducer(destination); // 6. 创建文本消息 TextMessage message = session.createTextMessage("Hello, ActiveMQ!"); // 7. 发送消息 producer.send(message); System.out.println("消息发送成功: " + message.getText()); // 8. 关闭资源（务必按顺序关闭） producer.close(); session.close(); connection.close(); } }

关键点解析：

连接工厂（ConnectionFactory）：这是入口，需要指定Broker的地址。协议tcp://是最常用的。
连接（Connection）：代表与Broker的TCP连接。创建后必须调用connection.start()才能开始传递消息，这是一个常见的遗漏点，会导致消费者收不到消息。
会话（Session）：一个单线程的上下文，用于生产和消费消息。第二个参数Session.AUTO_ACKNOWLEDGE表示自动确认，消息被消费者成功接收后自动向Broker确认。还有其他模式如CLIENT_ACKNOWLEDGE（客户端手动确认）和用于事务的SESSION_TRANSACTED。
生产者发送：默认是持久化消息（DeliveryMode.PERSISTENT），确保Broker重启后消息不丢失。如果追求极致性能且允许消息丢失，可设置为非持久化。

对应的消费者示例：

public class SimpleQueueConsumer { public static void main(String[] args) throws JMSException { ConnectionFactory factory = new ActiveMQConnectionFactory("tcp://localhost:61616"); Connection connection = factory.createConnection(); connection.start(); Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); Destination destination = session.createQueue("TEST.QUEUE"); MessageConsumer consumer = session.createConsumer(destination); // 设置消息监听器（异步消费） consumer.setMessageListener(message -> { if (message instanceof TextMessage) { try { System.out.println("收到消息: " + ((TextMessage) message).getText()); } catch (JMSException e) { e.printStackTrace(); } } }); // 保持主线程不退出，等待消息 System.out.println("消费者已启动，等待消息..."); // 这里通常用CountDownLatch或System.in.read()来等待 try { Thread.sleep(60000); } catch (InterruptedException e) { e.printStackTrace(); } consumer.close(); session.close(); connection.close(); } }

消费者有两种模式：同步阻塞（consumer.receive()）和异步监听（setMessageListener）。在生产环境中，异步监听是更常见和高效的方式。

4. 与Spring Boot深度集成：现代开发的最佳实践

如今，大部分Java项目都基于Spring Boot。ActiveMQ与Spring Boot的集成非常顺畅，主要通过spring-boot-starter-activemq实现。

4.1 基础配置与自动配置

首先在pom.xml中添加依赖：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-activemq</artifactId> </dependency> <!-- 如果需要连接池（生产环境推荐），添加 --> <dependency> <groupId>org.messaginghub</groupId> <artifactId>pooled-jms</artifactId> </dependency>

在application.yml中进行最小化配置：

spring: activemq: broker-url: tcp://localhost:61616 # Broker地址 user: admin # 可选，如果Broker开启了认证 password: your_password # 可选 packages: trust-all: true # 信任所有序列化包，生产环境应指定具体包名 pool: enabled: true # 启用连接池，提升性能 max-connections: 10 # 最大连接数

Spring Boot会自动为你配置好JmsTemplate（用于发送消息）和JmsListenerContainerFactory（用于监听消费），开箱即用。

4.2 使用JmsTemplate发送消息

JmsTemplate大大简化了发送操作。你可以将其注入到任何Spring管理的Bean中：

@Service public class OrderService { @Autowired private JmsTemplate jmsTemplate; public void placeOrder(Order order) { // 发送到指定队列 jmsTemplate.convertAndSend("order.queue", order); // convertAndSend方法会自动将对象转换为Message（默认使用SimpleMessageConverter） } }

JmsTemplate默认使用SimpleMessageConverter，它可以处理String、Map、Serializable对象等。如果你发送自定义对象，该对象必须实现Serializable接口。

4.3 使用@JmsListener消费消息

这是最优雅的消费消息方式。你只需要在方法上添加一个注解：

@Component public class OrderProcessor { @JmsListener(destination = "order.queue") public void processOrder(Order order) { System.out.println("处理订单: " + order.getId()); // 业务处理逻辑... } }

Spring会在后台自动创建一个消息监听容器，监听order.queue，一旦有消息到达，就会调用processOrder方法，并将消息体自动反序列化为Order对象。

这里有一个至关重要的细节：默认情况下，@JmsListener监听的Destination类型是队列（Queue）还是主题（Topic）？答案是：它取决于你配置的DefaultJmsListenerContainerFactory。默认是Queue。如果你想监听一个Topic，你需要显式配置一个JmsListenerContainerFactory，并设置pubSubDomain为true。

@Configuration public class JmsConfig { @Bean public JmsListenerContainerFactory<?> topicListenerFactory(ConnectionFactory connectionFactory) { DefaultJmsListenerContainerFactory factory = new DefaultJmsListenerContainerFactory(); factory.setConnectionFactory(connectionFactory); factory.setPubSubDomain(true); // 关键！设置为发布订阅模式 // 如果希望订阅持久化，还需要设置clientId和subscriptionName // factory.setSubscriptionDurable(true); // factory.setClientId("myClientId"); return factory; } } // 使用指定的ContainerFactory @Component public class NewsSubscriber { @JmsListener(destination = "news.topic", containerFactory = "topicListenerFactory") public void receiveNews(String news) { System.out.println("收到新闻: " + news); } }

如果不做这个配置，你将一个@JmsListener用在Topic上，它实际上会创建一个同名的临时Queue来接收消息，失去了Topic的广播意义，这是一个常见的配置错误。

5. 高级特性深入：解锁ActiveMQ的完整能力

掌握了基础，我们来看看ActiveMQ那些能解决实际复杂问题的高级特性。

5.1 消息持久化与存储方案选择

消息持久化是确保消息不因Broker重启而丢失的关键。ActiveMQ默认使用KahaDB作为持久化存储，它是一个基于文件的、经过优化的嵌入式数据库，性能不错。

KahaDB：默认选项。它将所有消息存储在一个日志文件中，并通过一个索引文件来加速检索。配置在conf/activemq.xml的persistenceAdapter部分。对于大多数场景，KahaDB已经足够。你可以通过调整indexCacheSize、journalMaxFileLength等参数来优化性能。
JDBC存储：如果你希望将消息存入MySQL、PostgreSQL等关系型数据库，以实现与现有运维体系的整合或更高的可靠性（利用数据库的主从复制），可以选择JDBC存储。配置示例如下：

<bean id="mysql-ds" class="org.apache.commons.dbcp2.BasicDataSource" destroy-method="close"> <property name="driverClassName" value="com.mysql.cj.jdbc.Driver"/> <property name="url" value="jdbc:mysql://localhost:3306/activemq?useSSL=false"/> <property name="username" value="root"/> <property name="password" value="password"/> </bean> <persistenceAdapter> <jdbcPersistenceAdapter dataSource="#mysql-ds"/> </persistenceAdapter>

使用JDBC存储的注意事项：

性能通常低于KahaDB，因为多了数据库IO。
需要手动创建数据库和表（ActiveMQ启动时会检查，但库需要提前建好）。
在高并发下，数据库可能成为瓶颈，需要做好数据库本身的优化。
长期运行后，消息表会变得巨大，需要设计消息清理或归档策略。

LevelDB(已弃用) /RocksDB：在5.x的后期版本，官方推荐使用RocksDB作为更高性能的持久化引擎，它比KahaDB在某些场景下（尤其是大量小消息）有更好的表现。但社区支持和文档相对少一些。

选择建议：中小规模、追求简单稳定，用KahaDB。需要与数据库集成或利用数据库高可用特性，用JDBC。对性能有极致要求，愿意尝试新组件，可以测试RocksDB。

5.2 消息事务与确认机制

消息的可靠性传递离不开事务和确认机制。

事务性会话：在创建Session时，第一个参数传true。
```
Session session = connection.createSession(true, Session.SESSION_TRANSACTED);
```
在事务性会话中，一组发送或接收操作被视为一个原子操作。必须显式调用session.commit()来提交，或session.rollback()来回滚。这对于需要确保“扣减库存”和“发送已扣减消息”必须同时成功的业务场景非常有用。
确认（Acknowledge）模式：
- AUTO_ACKNOWLEDGE（自动确认）：消费者成功接收消息后（即监听器方法成功返回，无异常），自动向Broker确认。如果方法内抛出异常，消息可能会被重新传递（取决于容器的重试策略）。
- CLIENT_ACKNOWLEDGE（客户端手动确认）：消费者需要调用message.acknowledge()来确认消息。这允许你在业务逻辑处理完成后的任意时刻进行确认，控制更灵活。
- DUPS_OK_ACKNOWLEDGE（延迟确认）：一种宽松的确认模式，允许Broker在某些情况下重新传递消息（可能重复），以换取一定的性能提升。适用于可以容忍少量重复消息的场景。

在Spring Boot的@JmsListener中，确认模式通过acknowledge属性配置，通常配合DefaultJmsListenerContainerFactory使用。

@Bean public DefaultJmsListenerContainerFactory jmsListenerContainerFactory(ConnectionFactory connectionFactory) { DefaultJmsListenerContainerFactory factory = new DefaultJmsListenerContainerFactory(); factory.setConnectionFactory(connectionFactory); factory.setSessionAcknowledgeMode(ClientAcknowledge.class); // 设置为客户端手动确认 return factory; } // 在监听方法中手动确认 @JmsListener(destination = "order.queue", containerFactory = "jmsListenerContainerFactory") public void handleOrder(Message message, Session session) throws JMSException { TextMessage textMessage = (TextMessage) message; try { // 业务处理... System.out.println(textMessage.getText()); // 处理成功，手动确认 message.acknowledge(); } catch (Exception e) { // 处理失败，不确认，根据重试策略可能会重新入队 session.recover(); } }

5.3 消息选择器（Message Selector）

消息选择器允许消费者只接收满足特定条件的消息，其语法类似于SQL的WHERE子句，但只针对消息的属性（Message Properties）进行过滤。

生产者可以设置消息属性：

TextMessage message = session.createTextMessage("订单内容"); message.setStringProperty("orderType", "VIP"); // 设置字符串属性 message.setIntProperty("amount", 10000); // 设置整数属性 producer.send(message);

消费者在创建时指定选择器：

// 只消费orderType为VIP且amount大于5000的消息 MessageConsumer consumer = session.createConsumer(destination, "orderType = 'VIP' AND amount > 5000");

在Spring@JmsListener中，可以使用selector参数：

@JmsListener(destination = "order.queue", selector = "orderType = 'VIP'") public void processVipOrder(Order order) { ... }

使用选择器的经验：

选择器是在Broker端进行过滤的，不满足条件的消息不会传递给消费者，这节省了网络带宽和客户端资源。
选择器的条件应尽量基于消息属性，而不是消息体，因为Broker不需要解析消息体就能进行过滤。
复杂的选择器可能会对Broker性能产生轻微影响。

5.4 延迟与定时消息

ActiveMQ支持延迟和定时消息投递。这在你需要实现“30分钟后检查订单状态”、“每天凌晨执行统计”等功能时非常有用。

发送延迟消息需要设置几个特殊的消息属性：

AMQ_SCHEDULED_DELAY：延迟投递的时间（毫秒）。
AMQ_SCHEDULED_PERIOD：重复投递的间隔（毫秒）。
AMQ_SCHEDULED_REPEAT：重复投递的次数。
AMQ_SCHEDULED_CRON：使用Cron表达式定时。

例如，发送一个延迟10秒的消息：

TextMessage message = session.createTextMessage("这是一条延迟消息"); message.setLongProperty("AMQ_SCHEDULED_DELAY", 10 * 1000); producer.send(message);

重要前提：要启用延迟消息功能，必须在Broker的配置文件activemq.xml中，在<broker>标签内添加调度器支持：

<broker ... schedulerSupport="true"> ... </broker>

默认是关闭的，如果不开启，设置这些属性是无效的。

6. 性能调优、监控与故障排查实战

当你的系统流量上来后，对ActiveMQ进行适当的调优和有效的监控就变得至关重要。

6.1 关键性能配置参数

配置文件conf/activemq.xml中有几个关键区域可以调整：

传输连接器（Transport Connectors）：在<transportConnectors>下。确保你使用的协议（如tcp）配置了合理的参数。例如，可以调整TCP缓冲区大小、启用NIO（非阻塞IO）以获得更好的并发性能。
```
<transportConnector name="nio" uri="nio://0.0.0.0:61616?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>
```
maximumConnections限制最大连接数，wireFormat.maxFrameSize限制单条消息的最大尺寸（防止特大消息拖垮Broker）。

内存限制（SystemUsage）：在<broker>标签下的<systemUsage>。这是防止Broker内存溢出的关键配置。

<systemUsage> <systemUsage> <memoryUsage> <memoryUsage percentOfJvmHeap="70" /> <!-- JVM堆内存的70%可用于ActiveMQ消息 --> </memoryUsage> <storeUsage> <storeUsage limit="100 gb"/> <!-- 持久化存储限制 --> </storeUsage> <tempUsage> <tempUsage limit="50 gb"/> <!-- 临时存储限制（用于非持久化消息等） --> </tempUsage> </systemUsage> </systemUsage>

当内存使用达到memoryUsage限制时，Broker会尝试将消息换页（Page）到磁盘，如果storeUsage也满了，生产者将被阻塞。根据你的物理内存和消息量合理设置这些值。

目的地策略（Destination Policy）：可以为特定的队列或主题设置内存限制、过期时间、死信策略等。

<destinationPolicy> <policyMap> <policyEntries> <policyEntry topic=">" producerFlowControl="true" memoryLimit="512mb"> <!-- 对所有Topic生效 --> <pendingMessageLimitStrategy> <constantPendingMessageLimitStrategy limit="1000"/> <!-- 当积压消息超过1000条时，开始丢弃旧消息 --> </pendingMessageLimitStrategy> </policyEntry> <policyEntry queue=">" optimizedDispatch="true" /> <!-- 对所有Queue启用优化分发 --> </policyEntries> </policyMap> </destinationPolicy>

6.2 监控手段与指标解读

除了Web控制台，还有更强大的监控方式：

JMX监控：ActiveMQ暴露了大量的JMX MBean。你可以使用JConsole、VisualVM或Zabbix、Prometheus（通过JMX Exporter）来监控。关键指标包括：
- Queue/或Topic/下的QueueSize（队列大小）、ConsumerCount（消费者数量）、EnqueueCount/DequeueCount（入队/出队总数）。
- Broker下的TotalMessageCount（总消息数）、TotalConnectionsCount（总连接数）、MemoryPercentUsage（内存使用百分比）。监控这些指标可以及时发现消息积压、消费者掉线、内存不足等问题。
日志分析：data/activemq.log是主要的日志文件。关注WARN和ERROR级别的日志。例如，频繁出现Usage Manager Memory Limit reached的警告，说明内存配置不足；出现Transport failed错误，可能是网络或客户端问题。

6.3 常见问题与排查思路

生产者发送消息慢或被阻塞：
- 检查点：首先看管理控制台，对应队列的Memory Usage和Store Usage是否接近100%。如果是，说明Broker资源不足，触发了流控（Producer Flow Control）。需要调整systemUsage限制或优化消费者消费速度。
- 网络与连接：检查网络是否通畅，连接数是否达到上限（maximumConnections）。
- 客户端代码：检查是否使用了同步发送且未设置超时，或者事务未及时提交。
消费者收不到消息：
- 基础检查：连接URL是否正确？connection.start()是否调用？消费者监听的目的地名称是否与生产者发送的完全一致（大小写敏感）？
- 选择器过滤：是否设置了消息选择器，而消息属性不匹配？
- 确认模式：如果是CLIENT_ACKNOWLEDGE，是否忘了调用acknowledge()？未确认的消息在会话关闭时可能会被重新传递。
- 持久化订阅（Topic）：对于Topic，消费者是否在消息发布前就创建了持久化订阅？非持久化订阅会丢失离线期间的消息。
消息堆积：
- 根本原因：生产速度持续大于消费速度。
- 应急处理：通过管理控制台临时清除积压消息（慎用！）。
- 长期解决：增加消费者实例（水平扩展）、优化消费者业务逻辑性能、检查消费者是否健康（无异常退出）、确认消息确认机制是否正常（避免因未确认导致消息反复投递）。
Broker内存持续增长直至OOM：
- 配置检查：memoryUsage是否设置过大或过小？过小容易触发流控，过大可能引起JVM GC问题。
- 消息检查：是否有大量大消息（如文件）在传输？考虑使用Blob消息或外部存储。
- 客户端检查：是否有消费者异常断开导致消息无法被确认和清除？检查Inactive Destinations。
- 启用消息过期：在发送消息时设置timeToLive，或在目的地策略中配置默认过期时间，让无用消息自动清理。

7. 集群与高可用方案：保障生产环境的生命线

单点Broker无法满足生产环境的高可用要求。ActiveMQ提供了主从（Master-Slave）和网络（Network of Brokers）两种主要的集群方式。

7.1 基于共享存储的主从（Master-Slave）

这是实现高可用（HA）的经典模式。多个Broker实例共享同一个持久化存储（如KahaDB目录、共享数据库、共享文件系统）。同一时间只有一个Master对外提供服务，其他Slave处于待命状态。当Master宕机，其中一个Slave会自动接管成为新的Master。

基于共享文件系统（如NFS、SAN）：配置简单，只需将所有Broker的persistenceAdapter指向同一个共享目录。但共享文件系统本身可能成为单点和性能瓶颈。
基于JDBC共享数据库：所有Broker配置相同的JDBC数据源。数据库的行锁机制会保证只有一个Broker能成为Master。对数据库的稳定性和性能要求较高。

配置示例（JDBC Master-Slave）：每个Broker的activemq.xml中配置相同的JDBC数据源和持久化适配器。启动时，第一个成功获取数据库锁的Broker成为Master。

优点：故障自动转移，消息零丢失（因为存储共享）。缺点：存在脑裂风险（需要可靠的网络和存储锁），Slave资源在平时闲置。

7.2 网络连接器（Network Connector）

这种模式用于实现负载均衡和分布式目的地。多个Broker通过网络连接器互联，形成一个消息路由网络。生产者连接Broker A，消费者连接Broker B，消息可以通过网络在Broker间自动转发。

<!-- 在Broker A的配置中，添加指向Broker B的网络连接器 --> <networkConnectors> <networkConnector name="bridge-to-b" uri="static:(tcp://brokerB-host:61616)" duplex="true"/> </networkConnectors>

动态转发：默认情况下，只有当某个Broker上有该目的地的消费者时，其他Broker上的消息才会被转发过来。这可以防止消息在没有消费者的Broker上堆积。
负载均衡：消费者可以均匀地连接到不同的Broker上，实现消费能力的水平扩展。
双重作用（Duplex）：设置duplex="true"表示建立双向连接，配置更简洁。

优点：水平扩展能力强，可实现跨地域的消息路由。缺点：配置相对复杂，网络分区（Network Partition）时可能导致消息不一致。

7.3 综合方案：主从+网络

在实际生产环境中，通常会结合两者。例如，在同一个数据中心内部，部署一组基于共享存储的主从Broker（保证HA）；在多个数据中心之间，使用网络连接器将各中心的主Broker连接起来（实现消息同步和灾备）。这样既保证了单点的高可用，又实现了系统的可扩展性和容灾能力。

选择集群方案时，一定要根据你的业务对消息可靠性、可用性、性能和运维复杂度的要求进行权衡。没有一种方案是万能的。

ActiveMQ实战指南：从JMS核心到Spring Boot集成与高可用集群部署