ActiveMQ负载均衡实例怎么配？ActiveMQ集群高可用方案

ActiveMQ 本身是一个单节点的消息中间件，要实现负载均衡和高可用，通常有以下几种主流方案，下面我将重点介绍最常用、最成熟的两种方案：ActiveMQ 集群（Master-Slave + Network of Brokers） 和 基于 Nginx 的 TCP 负载均衡。

---

✅ 方案一：ActiveMQ 集群（推荐生产环境）

这是 ActiveMQ 官方推荐的高可用架构，包含两个层面：

1. Master-Slave 模式：保证单个 Broker 的高可用（主备切换）。
2. Network of Brokers：多个 Broker 之间互联，实现负载分担和故障转移。

📌 架构示意图

Producer → [Broker A (Master)] ↔ [Broker B (Slave)]
                ↑
Consumer ← [Broker A] / [Broker B]

🔧 配置步骤（以 Master-Slave + Network 为例）

共享存储（如 KahaDB、LevelDB 或 JDBC）

ActiveMQ 的 Master-Slave 需要共享持久化存储，推荐使用 LevelDB 或 JDBC + MySQL。

示例：使用 LevelDB（本地共享目录，需配合 ZooKeeper 或共享文件系统）

在 activemq.xml 中配置：

<persistenceAdapter>
    <levelDB directory="/shared/activemq-data" />
</persistenceAdapter>

⚠️ 注意：LevelDB 要求所有节点访问同一个共享存储（如 NFS、GlusterFS 等）。

示例：使用 JDBC（MySQL）

<persistenceAdapter&g
t;
    <jdbcPersistenceAdapter dataSource="#mysql-ds" />
</persistenceAdapter>
<bean id="mysql-ds" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
    <property name="driverClassName" value="com.mysql.jdbc.Driver"/>
    <property name="url" value="jdbc:mysql://localhost:3306/activemq?relaxAutoCommit=true"/>
    <property name="username" value="root"/>
    <property name="password" value="password"/>
    <property name="maxActive" value="200"/>
    <property name="poolPreparedStatements" value="true"/>
</bean>

配置 Network of Brokers（负载均衡）

在 activemq.xml 中添加网络连接器：

<networkConnectors>
    <networkConnector uri="static:(tcp://broker2:61616)" />
</networkConnectors>

• broker1 配置指向 broker2
• broker2 配置指向 broker1

这样两个 Broker 会自动同步队列和消息，消费者可以连接到任意一个 Broker，实现负载均衡。

客户端连接方式

客户端使用 Failover Transport 自动故障转移：

String url = "failover:(tcp://broker1:61616,tcp://broker2:61616)?randomize=false";
ConnectionFactory factory = new ActiveMQConnectionFactory(url);

---

✅ 方案二：Nginx + ActiveMQ TCP 负载均衡（轻量级）

如果你不想配置复杂的集群,可以使用 Nginx 的 TCP 负载均衡 来分发连接请求。

📌 架构示意图

Producer/Consumer
       ↓
   [Nginx (TCP LB)]
       ↓
   [Broker1:61616]
   [Broker2:61616]
   [Broker3:61616]

🔧 配置步骤

Nginx 配置（nginx.conf）

stream {
    upstream activemq_cluster {
        server broker1:61616;
        server broker2:61616;
        server broker3:61616;
    }
    server {
        listen 61616;
        proxy_pass activemq_cluster;
        proxy_timeout 1m;
        proxy_connect_timeout 10s;
    }
}

客户端连接 Nginx

String url = "tcp://nginx-server:61616";
ConnectionFactory factory = new ActiveMQConnectionFactory(url);

⚠️ 注意：

• 这种方案没有消息同步，每个 Broker 是独立的。
• 适合无状态生产者/消费者，或配合外部消息存储。
• 如果某个 Broker 宕机，Nginx 会自动剔除，但消息可能丢失（未持久化到该 Broker 的消息）。

---

✅ 方案三：ActiveMQ Artemis（新一代替代方案）

如果你正在新项目,建议考虑 ActiveMQ Artemis，它原生支持集群、负载均衡和高可用，配置更简单：

<cluster-user>admin</cluster-user>
<cluster-password>admin</cluster-password>
<connectors>
    <connector name="netty">tcp://host1:61616</connector>
</connectors>
<cluster-connections>
    <cluster-connection name="my-cluster">
        <connector-ref>netty</connector-ref>
        <address>jms</address>
    </cluster-connection>
</cluster-connections>

---

📊 方案对比

特性	Master-Slave + Network	Nginx TCP LB	ActiveMQ Artemis
高可用	✅ 主备切换	❌ 无状态，依赖外部	✅ 原生支持
负载均衡	✅ 自动	✅ Nginx 分发	✅ 原生支持
消息持久化	✅ 共享存储	❌ 各节点独立	✅ 共享存储
配置复杂度	中	低	中
适用场景	生产环境	轻量级/测试	新项目推荐

---

✅ 最佳实践建议

1. 生产环境：使用 Master-Slave + Network of Brokers，配合共享存储（JDBC/LevelDB）。
2. 客户端：始终使用 failover: 协议连接，避免单点故障。
3. 监控：使用 JMX 或 Prometheus + Grafana 监控 Broker 状态。
4. 测试：在上线前进行故障转移测试，确保消息不丢失。

---

如需具体配置示例（如 Spring Boot 集成、Docker 部署等），请告诉我你的具体场景，我可以提供更详细的代码和配置。