Jboss 活动MQ消息顺序处理

我们有两台服务器：server1和server2。这两台服务器都在Wildfly 11的域模式配置下运行。下面介绍如何配置这两台服务器

让我们考虑Serv1域节点在我们的情况下。

问题:

如果两条具有相同组ID的消息同时到达server1和server2，它们将不知道该消息应发送给哪个消费者。因此，消息最终会被不同的使用者处理，有时最先到达的消息会在稍后处理，这是不可取的。 我们希望对系统进行配置，以便两个节点都知道消息应该由哪个使用者处理

我们尝试的解决方案：

将server1配置为本地组处理程序，将server2配置为远程组处理程序。现在，无论消息何时到达，本地组处理程序都会确定特定组ID的使用者在哪个节点上，并相应地拾取消息

此解决方案在server1正常运行之前有效。但是，如果server1停机，则不会处理消息。为了解决这个问题，我们将server1的消息传递子系统活动mq的备份添加到server2，同样地，我们也为server2添加了备份

/profile=abc/subsystem=messaging-activemq/server=backup:add

（备份服务器将添加到两个节点，因为server1是域节点）

我们还向该备份服务器添加了相同的发现组、http连接器和广播组。我们为备份服务器和活动服务器建立了群集连接，使它们位于server1和server2的同一组中

/profile=abc/subsystem=messaging-activemq/server=default/ha-policy=replication-master:add(cluster-name=my-cluster,group-name=${livegroup},check-for-live-server=true)
/profile=abc/subsystem=messaging-activemq/server=backup/ha-policy=replication-slave:add(cluster-name=my-cluster,group-name=${backupgroup})

server1配置为读取以下属性：

livegroup=group1
backupgroup=group2

livegroup=group2
backupgroup=group1

server2配置为读取以下属性：

livegroup=group1
backupgroup=group2

livegroup=group2
backupgroup=group1

但是，此解决方案似乎无法修复故障转移情况，并且当具有本地组处理程序节点的活动节点关闭时，未在其他节点上处理消息。当服务器1关闭时，服务器2上出现以下错误：

[org.apache.activemq.artemis.core.server] (default I/O-3) AMQ222092: Connection to the backup node failed, removing replication now: ActiveMQRemoteDisconnectException[errorType=REMOTE_DISCONNECT message=null]
        at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.connectionDestroyed(RemotingServiceImpl.java:533)
        at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor$Listener.connectionDestroyed(NettyAcceptor.java:682)
        at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelInactive(ActiveMQChannelHandler.java:79)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:224)
        at io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:360)
        at io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:325)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:224)
        at io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1329)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
        at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:908)
        at io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:744)
        at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
        at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)

---

请建议所有其他方法来处理此问题，或者我们如何配置具有本地组处理程序的服务器关闭的场景。

建议的群集分组解决方案是您已配置的—具有本地组处理程序的节点备份。这里的底线是，如果集群中没有具有本地分组处理程序的活动节点，那么就无法决定消费者应该处理哪个组。在我看来，您的备份代理根本没有按预期工作（这可能是另一个问题的主题）

除了备份之外，你可以考虑完全消除群集，这样你只需要1个代理，或者仅仅是一个生存/备份对，而不是2个活跃的代理。集群是一种使用水平扩展提高总体消息吞吐量的方法。然而，消息分组会自然地序列化每个组的消息消耗，从而降低总体消息吞吐量（可能严重取决于用例）。可能因为您正在分组消息，所以不需要集群的性能可伸缩性。您是否执行过任何基准测试来确定您的性能瓶颈？如果是，集群是否是解决这些瓶颈的经验证的解决方案