这个问题是我之前问过的问题的后续。
设置与该问题中概述的相同，具有 4 个独立 ActiveMQ Artemis (v2.20) 节点的对称集群，每个节点具有相同的配置 - 相同的设置、队列等。多个客户端应用程序连接到该集群消息消费者或消息，所有客户端都使用如下连接字符串进行连接：
(tcp://artemis1:61616,tcp://artemis2:61616,tcp://artemis3:61616,tcp://artemis4:61616)?type=XA_CF&ha=true&retryInterval=1000&retryIntervalMultiplier=2&maxRetryInterval=32000&reconnectAttempts=-1
通常，消费者连接是持久的，可以保持几个小时。我们遇到的具体问题是，有时会出现这样的情况：特定队列在 4 个节点中的任何一个上都没有消费者。例如，消费应用程序可能会因维护一个小时而关闭。在此期间，生产者应用程序可能会向队列发送消息，并且在没有任何消费者的情况下，这些消息会相当随机地分发。例如。假设 artemis1 和 artemis3 各收到 1 条消息，而其他 2 个服务器保留零条消息。然后，稍后消费者连接回队列 - 但这些连接似乎与队列上消息的状态无关。如果客户端应用程序生成 2 个消费者线程，这些线程可能会连接到 artemis1 和 artemis4，这会使 artemis3 上的消息无限期地“卡住”。根据上面链接的其他问题，在这种情况下似乎重新分配也不会启动。我注意到，即使在客户端产生的消费者线程多于服务器数量的情况下，我们仍然可能会遇到这样的情况：一台服务器没有获得任何消费者，因此可能会留下“搁浅”的消息。
希望问题的解释有意义！我们是否应该预期会发生这种情况，或者消费者连接是否应该更加了解集群中目标队列上的消息状态？感谢您对我们可以采取哪些措施来避免此问题的任何建议，或任何其他评论。
请注意，相反的情况并不适用 - 消息生产者客户端确实表现出对消费者分布的认识：消息总是优先发送到连接了消费者（如果有）的服务器，而不是没有连接的服务器。
连接负载平衡策略分布在集群周围。
需要明确的是，有一个称为“连接路由器”的高级功能，它可以根据连接提供的信息（例如客户端 ID、用户名、角色等）以更智能的方式在集群中分配连接。它可用于确保某些生产者和消费者始终连接到相同的集群节点，从而避免消息转发或重新分发的性能损失。但我离题了。
但是，您所看到的缺乏“消息重新分发”的情况并不是预期的。实施重新分配就是为了解决这个问题。基于您使用的是 redistribution-delay
600000 的事实，那么没有消息的节点上的消费者应该在 10 分钟后开始接收消息（当然假设它们保持连接那么长时间），因为它们是从节点重新分发的有
有消息。
我建议您使用最新版本制作一个最小的、可重现的示例
。如果您能够这样做，请打开 Jira 并连接复制器。如果没有，请将集群升级到最新版本，并确保您的配置与工作版本相当。 作为信息，我们开始了一些测试，并且能够轻松复制 v2.20 上的（缺乏）消息重新分发问题。然后我们升级到 v2.31，无法再使用相同的测试用例进行复制。我们已经将 v2.31 发布到生产环境，并且也不再出现此类问题。所以看起来这两个版本之间已经得到解决。