【问题标题】:Facing cluster testing issue with ActiveMQ Artemis面对 ActiveMQ Artemis 的集群测试问题
【发布时间】:2020-08-30 08:27:12
【问题描述】:

我有 2 个 ActiveMQ Artemis 实例,只需使用命令创建 /.artemis create artemis/server1

/.artemis create artemis/server2

我正在使用 linux ubantu。

这里是 server1 的broker.xml:

  <acceptors>
     <!-- Acceptor for every supported protocol -->
     <acceptor name="artemis">tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300</acceptor>

  </acceptors>

  <connectors>
     <connector name="netty-connector">tcp://localhost:61616</connector>
     <!-- connector to the server1 -->
     <connector name="server1-connector">tcp://localhost:61617</connector>
  </connectors>

 <cluster-connections>
     <cluster-connection name="my-cluster">
        <connector-ref>netty-connector</connector-ref>
        <retry-interval>500</retry-interval>
        <use-duplicate-detection>true</use-duplicate-detection>
        <message-load-balancing>STRICT</message-load-balancing>
        <max-hops>1</max-hops>
        <static-connectors>
           <connector-ref>server1-connector</connector-ref>
        </static-connectors>
     </cluster-connection>
  </cluster-connections>

这里是 server2 的 broker.xml:

     <!-- Acceptor for every supported protocol -->
   <acceptor name="artemis">tcp://0.0.0.0:61617?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300</acceptor>
  </acceptors>

  <connectors>
     <connector name="netty-connector">tcp://localhost:61617</connector>
     <!-- connector to the server0 -->
     <connector name="server0-connector">tcp://localhost:61616</connector>
  </connectors>

  <cluster-connections>
     <cluster-connection name="my-cluster">
        <connector-ref>netty-connector</connector-ref>
        <retry-interval>500</retry-interval>
        <use-duplicate-detection>true</use-duplicate-detection>
        <message-load-balancing>STRICT</message-load-balancing>
        <max-hops>1</max-hops>
        <static-connectors>
           <connector-ref>server0-connector</connector-ref>
        </static-connectors>
     </cluster-connection>
  </cluster-connections>

同样在 server2 中,更改 bootstrap.xml,更改 web 绑定端口

<web bind="http://localhost:8163" path="web">

我正在使用StaticClusteredQueueExample 和这个示例工作文件对其进行测试。

现在我正在针对我的集群运行 ActiveMQ Artemis JMeter Performance,我正在使用 here 的 JMeter 测试示例

现在,当我使用 Jmeter 运行 point to point test 时,消费者的错误率接近 50%(Jmeter 中的汇总报告),

但是我在 ubantu 系统中只运行一个节点(server1 或 server2 中的任何一个),它工作正常,0% 错误率(Jmeter 中的聚合报告)。

您能否帮助我在使用 docker 运行多个实例(节点)时得到 50% 的错误率(Jmeter 中的汇总报告)

【问题讨论】:

  • 在明确错误究竟是什么之前,真的无法提供帮助。此外,对测试进行更清晰的解释也会有所帮助(例如,JMeter 是在其中一个 Docker 容器中运行还是在其他地方运行?)。最后,集群真的形成了吗?
  • @JustinBertram 感谢您的回复,我已经更新了我的问题,在没有 docker 的情况下也面临同样的问题,因此更新的详细信息已在本地机器(在 Ubuntu 中)进行测试。

标签: activemq-artemis


【解决方案1】:

问题在于您将一个示例(即 JMeter 示例)与一个真正不兼容的集群配置(即来自 clustered-static-discovery 示例)混合在一起。

集群的<message-load-balancing> 是严格的,这意味着无论消费者是否存在,消息都将在集群中进行负载平衡。此外,默认<redistribution-delay> 为-1,这意味着由于 STRICT 消息负载平衡类型而发送到集群中其他节点的消息将保留在这些节点上,并且不会根据消费者需求重新分配。

JMeter 示例是在考虑单个节点的情况下编写的,因此它只向 1 个节点发送消息并使用来自 1 个节点的消息,这意味着它只会收到它发送的一半消息,因为另一半将被转发到由于配置,集群中的其他节点。

如果您将 更改为 ON_DEMAND,您将不会看到任何错误,因为所有消息都将保留在专门发送它们的节点上,该节点也是连接消费者的位置。

【讨论】:

  • 嗨@Justin,可能是我错了,在StaticClusteredQueueExample 中,仅使用一台服务器ConnectionFactory cf0 = new ActiveMQConnectionFactory("tcp://localhost:61619"); 创建连接,但有4 个消费者从所有4 个artemis 服务器获取数据(使用轮询)。现在 Jmeter 消费者正在连接 TCP://localhost:61616 服务器,那么为什么 Jmeter 消费者没有发生同样的事情,为什么它的集群没有为它返回数据......
  • StaticClusteredQueueExample 使用 same 连接工厂来创建所有连接,这就是连接以循环方式在集群中的节点之间进行负载平衡的原因。但是,JMeter 会在 JNDI 中为 每个 线程查找连接工厂,这意味着连接不会进行负载平衡,因为每个连接工厂只有 1 个连接。
  • 嗨贾斯汀,但负载平衡是在服务器端,如果我在谈论 tomcat 负载平衡,那么如果多个请求来自多个浏览器,那么负载平衡器处理每个请求并分发所有请求(轮-robin fashion) 在多个节点上并返回响应给浏览器,但是这里消费者的请求有一半是成功的,50% 失败
  • 负载平衡发生在 2 个级别。消息负载平衡由代理基于 完成。然后是由客户端完成的连接负载平衡。在 JMeter 示例中,据我所知,连接负载平衡并没有发生。换句话说,所有连接都集中在集群的单个节点上。然而,与此同时,消息负载平衡正在发生,因为消息以循环方式在节点之间分发,有效地使一半消费者挨饿并导致错误。
猜你喜欢
  • 2020-06-09
  • 2018-05-08
  • 2020-10-20
  • 1970-01-01
  • 2018-06-21
  • 2021-02-15
  • 2020-02-24
  • 2021-10-13
  • 1970-01-01
相关资源
最近更新 更多