ActiveMQ Artemis集群负载不均：如何实现节点间流量均衡？

我们期望达到1600事件/秒的吞吐量（理想情况可提升至2000以预留缓冲）。当前部署3台ActiveMQ Artemis 2.42.0 Broker的HA集群（暂无备份节点），测试采用m7i-flex.4xlarge实例，硬件并非瓶颈——负载测试期间CPU与内存利用率始终处于低位。

集群连接配置 #

<cluster-connections>
  <cluster-connection name="artemis-cluster">
    <address></address>
    <connector-ref>artemis</connector-ref>
    <check-period>1000</check-period>
    <connection-ttl>60000</connection-ttl>
    <call-timeout>30000</call-timeout>
    <retry-interval>500</retry-interval>
    <retry-interval-multiplier>2.0</retry-interval-multiplier>
    <max-retry-interval>5000</max-retry-interval>
    <initial-connect-attempts>-1</initial-connect-attempts>
    <reconnect-attempts>-1</reconnect-attempts>
    <use-duplicate-detection>true</use-duplicate-detection>
    <message-load-balancing>ON_DEMAND</message-load-balancing>
    <max-hops>1</max-hops>
    <confirmation-window-size>32000</confirmation-window-size>
    <call-failover-timeout>30000</call-failover-timeout>
    <notification-interval>1000</notification-interval>
    <notification-attempts>2</notification-attempts>
    <discovery-group-ref discovery-group-name="artemis-discovery-group"/>
  </cluster-connection>
</cluster-connections>

地址设置 #

<address-setting match="domain-events.#">
  <max-size-bytes>-1</max-size-bytes>
  <message-counter-history-day-limit>10</message-counter-history-day-limit>
  <address-full-policy>PAGE</address-full-policy>
  <auto-create-queues>true</auto-create-queues>
  <auto-create-addresses>true</auto-create-addresses>
  <auto-create-jms-queues>true</auto-create-jms-queues>
  <auto-create-jms-topics>true</auto-create-jms-topics>
  <redistribution-delay>0</redistribution-delay>
  <default-address-routing-type>MULTICAST</default-address-routing-type>
  <redelivery-delay>4000</redelivery-delay>                 
  <redelivery-delay-multiplier>3</redelivery-delay-multiplier>
  <max-redelivery-delay>300000</max-redelivery-delay>       
  <max-delivery-attempts>5</max-delivery-attempts>           
  <redelivery-collision-avoidance-factor>0.05</redelivery-collision-avoidance-factor>
  <dead-letter-address>DLQ</dead-letter-address>
  <auto-create-dead-letter-resources>true</auto-create-dead-letter-resources>
  <dead-letter-queue-prefix></dead-letter-queue-prefix>
  <dead-letter-queue-suffix>.DLQ</dead-letter-queue-suffix>
</address-setting>

<address-setting match="#">
  <dead-letter-address>DLQ</dead-letter-address>
  <auto-create-dead-letter-resources>true</auto-create-dead-letter-resources>
  <dead-letter-queue-prefix></dead-letter-queue-prefix>
  <dead-letter-queue-suffix>.DLQ</dead-letter-queue-suffix>
  <expiry-address>ExpiryQueue</expiry-address>
</address-setting>

部署架构 #

生产者

• 基于Spring Boot + messaginghub/pooled-jms实现连接复用；
• 消息生产速度较快，瓶颈源于慢消费者触发的流控；
• 测试过不同producerWindowSize值：更大值可减少节流但会增加Broker内存占用，理想状态是Artemis为慢消费者分页消息，同时为快消费者保留内存。

消费者

• 采用Spring @JmsListener实现，使用CLIENT_ACKNOWLEDGE确认模式；
• 并发数基于可用CPU与数据库连接数配置；
• 已调优consumerWindowSize以平衡内存占用与吞吐量；
• 使用核心客户端动态发现，默认采用RoundRobinConnectionLoadBalancingPolicy。

部署方式

• 生产者与消费者运行于Kubernetes Pod中；
• 示例配置：4个生产者Pod，2个消费者服务（如4个Pod+6个Pod）；
• 支持水平扩容。

问题现象 #

在吞吐量约1600事件/秒时，流量不稳定。例如：

• 所有4个生产者Pod连接至节点1；
• 消费者服务1连接至节点1；
• 其他消费者（服务2、3）连接至节点2。

此时出现：

• 节点1上的消费者处理大部分负载；
• 其他节点的消费者仅获取少量消息；
• 服务器端负载分布不均。

咨询问题 #

能否配置ActiveMQ Artemis，让节点1按比例（如75%）将消息转发至节点2，以实现集群节点间更均衡的负载分布？

当前测试结果 #

我们期望吞吐量曲线平稳，且消息添加与确认的差距更小，计划进行单节点测试以对比结果。

内容的提问来源于stack exchange，提问作者la00