ECS集群自动扩缩容架构下RabbitMQ扩容效能与方案咨询

不是完全失效，但完全达不到预期削峰效果，扩容投入的成本会浪费80%以上：

• RabbitMQ的队列主节点是实际承接消息路由、入站分发、消费者投递的核心实体，副本节点仅承担数据同步职责，不会承接主队列的核心业务流量。
• 结合当前场景仅12个队列、主节点全集中在单节点的现状，就算自动扩容新增2-3个节点，这些新节点上只会存在对应队列的副本，不会分配主队列流量，最终所有高峰流量还是会全部挤在原来扛主队列的单个节点上，新节点的CPU、内存几乎处于空闲状态，完全起不到分担高峰负载的作用。
• 仅有的正向收益是新节点可以分流一部分客户端的长连接开销、持久化IO压力，最多能把单节点的高峰负载降低10%-20%，远达不到“扩容削峰”的设计目标。

所有调整都严格遵守“不得删除、修改已创建的交换机与队列、低峰缩容、高峰自动扩容”的业务约束，不需要改动原有队列定义：

• 将主节点重平衡动作内嵌到自动扩容流程中，完全替代人工操作
  在ECS服务的扩容生命周期钩子中新增内置步骤：当新节点成功加入集群、所有队列副本状态从同步中转为完成同步后，自动在集群中执行轻量重平衡命令rabbitmq-queues rebalance all。由于当前总共仅12个队列，整个重平衡过程耗时不到2秒，无业务感知，执行完成后所有主队列会被均匀打散到所有在线节点上，新节点一上线即可承接高峰流量。
• 全局配置主节点调度规则，从根源避免主节点集中问题
  在所有节点的rabbitmq.conf中新增配置：queue-master-locator = min-masters。该配置不需要改动任何已有的队列定义，会在队列主节点发生故障转移、缩容节点退出集群时，自动将主节点优先分配到当前持有最少主队列的节点上，从逻辑上避免节点缩容回3个甚至更少节点的规模时，主队列再次集中到单节点的问题。
• 优化副本同步配置，适配自动扩缩容场景
  保持现有ha-mode = exact、2个副本的策略不变，新增配置：ha-sync-mode = automatic、ha-sync-batch-size = 4096。该配置可以让新加入的扩容节点自动追平队列副本数据，不需要人工触发全量同步，避免重平衡后主节点切到新节点时出现副本数据不一致、消息阻塞的问题。低峰期5条/秒的消息速率下，自动同步几乎不占用额外资源。
• 调整扩缩容的触发逻辑，匹配高峰流量周期
  将自动缩容的冷却时间调整为90分钟，匹配单次1小时的高峰持续时长，避免高峰流量爬坡阶段，新扩容的节点因为暂时CPU负载偏低被提前缩容掉；同时将扩容触发的CPU阈值从默认的80%下调到50%，在流量爬坡阶段就提前拉起新节点，留出足够的时间完成节点加入、副本同步、主节点重平衡的全流程，等流量真正到达峰值时，集群已经处于最优的承载状态。
• 低峰期提前做负载校验
  在每日固定的两个高峰时段前，通过定时任务自动校验集群的主节点分布情况，如果发现各节点的主队列数量差值超过1个，就自动触发一次轻量重平衡，避免高峰时段才临时发现主节点集中的问题。

注：上述调整均不需要删除、重建原有队列与交换机，完全符合业务约束，RabbitMQ 3.8版本的重平衡操作对客户端连接无感知，不会造成消息丢失或业务中断。

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