我有以下情况：
每天两次，大约 1 小时，我们收到了当前通过 RabbitMQ 运行的大量消息流入。当前的 3 个节点的 Rabbit 集群无法处理峰值，否则运行流畅。它目前设置在纯 EC2 实例上。实例类型是当前的 t3.medium，这是非常低的，除非在每天的其他 22 小时，我们收到 ~5 msg/s。它还设置当前具有 ha-mode=all。
在 rabbitmq docs 中进行了相当冗长且具有启发性的阅读后，我决定尝试设置一个 ECS EC2 集群并在 CPU 负载上升时横向扩展。因此，在其上创建一个服务并将该服务添加到服务发现中。例如discovery.rabbitmq。如果有三个实例，那么它们都会以相同的名称运行，但它会解析为所有三个 IP。加入集群将基于此工作：
那将是 rabbitmq.conf 部分：
cluster_formation.peer_discovery_backend = dns
# the backend can also be specified using its module name
# cluster_formation.peer_discovery_backend = rabbit_peer_discovery_dns
cluster_formation.dns.hostname = discovery.rabbitmq
我将策略 ha_mode=exact 与 2 个副本一起使用。
我们的交换和队列是预先手动创建的，原因我无法进一步讨论，但这是给定的。它们不能被移除，也不会被即时重新创建。我们有 3 个交换，每 4 个队列。
所以，这个想法是：在高负载期间 - 添加更多实例，在无负载期间，运行三个（甚至更少）实例。
向外扩展/向内设置工作正常，直到我开始使用 benchmarking tool 并发现队列总是在成为队列主节点的单个节点上创建。考虑到基准测试工具连接到单个节点，这很好。问题是，在缩小/缩小之后，我们手动创建的队列也不会移动到其他节点。这也符合我在rabbit 3.8 release page上看到的：
<块引用>对 RabbitMQ 集群的服务器执行滚动升级的痛点之一是队列主服务器最终会集中在一台或两台服务器上。新的 rebalance 命令将自动在整个集群中重新平衡 master。
以下是我遇到的问题，我正在寻求一些建议：
如果我正确解释了文档，向外扩展根本无济于事，因为这些节点会闲置在那里，直到有人手动调用 rabbitmq-queues rebalance all。
横向扩展的首选方式是什么？