消息负载均衡策略

发布方消息负载均衡策略

消息队列针对发布方采取的是轮询制，即 Producer 的消息以轮询的方式发送至 Queue，如下图所示。

图中箭头线条上的标号代表顺序，发布方会把第一条消息发送至 Queue 0，然后第二条消息发送至 Queue 1，以此类推，第八条消息发送至 Queue 7，第九条消息又发送至 Queue 0，循环往复。

订阅方消息负载均衡策略

消息队列包含 Broker 和 Name Server 等节点，其中 Broker 节点负责将 Topic 的路由信息上报至 Name Server 节点。

假设目前消息队列只有一个 Broker 节点，消息从 Producer 发送至消息队列的 Topic，默认会将这些 Topic 下的消息均衡负载至 8 个 Queue（逻辑概念）。消息队列 Broker 会将这些 Queue 再平均分配至属于同一个 Group ID 的订阅方集群。

因此，每台订阅方机器处理的 Queue 的数量有以下几种可能：

• 若订阅方机器数量大于 Queue 的数量，则超出 Queue 数量的机器将不会处理 Queue 上的消息，如下图所示。

• 若订阅方机器数量等于 Queue 的数量，则每台机器会处理 1 个 Queue 上的消息，如下图所示。

• 若订阅方机器数量小于 Queue 的数量，则每台机器会处理多个 Queue 上的消息，如下图所示。

如果其中一台机器处理变慢，可能是机器硬件、系统、远程 RPC 调用或 Java GC 等原因导致分配至此机器上的 Queue 的消息不能及时处理；此外，消息队列的消息负载是按 Queue 为粒度维护，所以，整个 Queue 上的消息都会堆积。