O ApsaraMQ for RocketMQ usa políticas de balanceamento de carga para controlar como os produtores roteiam mensagens para as filas e como os brokers atribuem mensagens ou filas aos consumidores. A política do lado do consumidor depende da versão do SDK cliente TCP.
Como funciona
O ApsaraMQ for RocketMQ oferece dois modelos de balanceamento de carga para consumidores:
|
Modelo |
Comportamento do consumidor |
Compatível com |
Característica principal |
|
Baseado em mensagens |
Os brokers distribuem mensagens individuais aos consumidores. Vários consumidores podem processar mensagens da mesma fila. |
TCP client SDK for Java V2.x.x.Final, TCP client SDK for C++ V3.x.x |
Nenhum consumidor fica ocioso quando o número de consumidores excede o de filas |
|
Baseado em filas |
Os brokers atribuem filas inteiras aos consumidores. Cada fila é processada por exatamente um consumidor. |
TCP client SDK for Java V1.x.x.Final, TCP client SDK for C++ V1.x.x e V2.x.x |
O número de consumidores não deve exceder o de filas para evitar ociosidade |
O balanceamento de carga do produtor funciona da mesma maneira em ambos os modelos:
Mensagens não ordenadas (normais, transacionais, agendadas e atrasadas): os produtores enviam mensagens para as filas em ordem round-robin.
Mensagens ordenadas: os produtores enviam todas as mensagens com a mesma chave de sharding para a mesma fila.
Políticas de balanceamento de carga compatíveis com o SDK for Java V2.x.x.Final e o SDK for C++ V3.x.x
Essas políticas distribuem mensagens individuais — e não filas inteiras — aos consumidores. Vários consumidores podem processar mensagens da mesma fila simultaneamente. Além disso, nenhum consumidor permanece ocioso, mesmo quando o número de consumidores excede o de filas.
Pré-requisitos
Para usar essas políticas de balanceamento de carga, atualize o SDK cliente TCP:
TCP client SDK for Java: atualize para a versão V2.x.x.Final. A instância deve estar implantada em uma destas regiões: China (Hangzhou), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Shenzhen), China (Chengdu), Alemanha (Frankfurt) ou Indonésia (Jakarta).
TCP client SDK for C++: atualize para a versão V3.x.x. A instância pode ser implantada em qualquer região.
Roteamento do produtor
O balanceamento de carga do produtor é o mesmo, independentemente da versão do SDK:
-
Mensagens não ordenadas (normais, transacionais, agendadas e atrasadas): os produtores enviam mensagens para as filas em ordem round-robin. Neste exemplo, há três filas disponíveis. O produtor envia Msg1 para a Fila 1, Msg2 para a Fila 2, Msg3 para a Fila 3, Msg4 novamente para a Fila 1 e assim por diante.
-
Mensagens ordenadas: os produtores enviam todas as mensagens com a mesma chave de sharding para a mesma fila. Neste exemplo, todas as mensagens com chave de sharding 1 vão para a Fila 1, e todas as mensagens com chave de sharding 2 vão para a Fila 2.
Atribuição de consumidor para mensagens não ordenadas
Para mensagens não ordenadas, os brokers distribuem uniformemente todas as mensagens de um tópico entre os consumidores do mesmo grupo. Diferentes consumidores podem consumir mensagens da mesma fila simultaneamente.
Neste exemplo, quatro mensagens na Fila 2 são distribuídas ao Consumidor 1, Consumidor 2, Consumidor 3 e Consumidor 4, respectivamente. Cada consumidor processa mensagens de forma independente, sem depender da fila à qual elas pertencem.
Atribuição de consumidor para mensagens ordenadas
Para mensagens ordenadas, os brokers distribuem as mensagens com base nas chaves de sharding. Todas as mensagens com a mesma chave de sharding vão para o mesmo consumidor, o que preserva a ordem de produção. Mensagens com chaves de sharding diferentes podem ser distribuídas a consumidores distintos.
: mensagens com esta cor de fundo pertencem à Fila 1. Por exemplo, Msg2-1 é a segunda mensagem na Fila 1 e sua chave de sharding é 1.
: mensagens com esta cor de fundo pertencem à Fila 2. Por exemplo, Msg3-2 é a terceira mensagem na Fila 2 e sua chave de sharding é 2.
Neste exemplo:
Msg1-1, Msg2-1 e Msg3-1 vão para o Consumidor 1 porque compartilham a chave de sharding 1.
Todas as mensagens com chave de sharding 2 vão para o Consumidor 2.
Msg4-3 e Msg4-4 vão para consumidores diferentes porque possuem chaves de sharding distintas.
Políticas de balanceamento de carga compatíveis com o SDK for Java V1.x.x.Final e o SDK for C++ V1.x.x e V2.x.x
Essas políticas de balanceamento de carga atribuem filas inteiras aos consumidores. Cada fila é processada por exatamente um consumidor por vez. A política de atribuição é a mesma para mensagens não ordenadas e ordenadas.
Distribuição de filas
A arquitetura do ApsaraMQ for RocketMQ inclui brokers e name servers. Um broker relata informações de rota do tópico a um name server. Por padrão, as mensagens em um tópico são distribuídas entre 8 filas por broker. Uma fila é um conceito lógico. O broker então atribui essas filas uniformemente a todos os consumidores no mesmo grupo.
Roteamento do produtor
O balanceamento de carga do produtor é igual ao do SDK for Java V2.x.x.Final e do SDK for C++ V3.x.x:
Mensagens não ordenadas: os produtores enviam mensagens para as filas em ordem round-robin.
Mensagens ordenadas: os produtores enviam todas as mensagens com a mesma chave de sharding para a mesma fila.
Para obter detalhes e diagramas, acesse Roteamento do produtor acima.
Atribuição de consumidor
Como cada fila só pode ser atribuída a um consumidor por vez, a proporção entre consumidores e filas afeta diretamente a utilização de recursos:
-
Mais consumidores do que filas: consumidores extras permanecem ociosos. Por exemplo, com 8 filas e 10 consumidores, 2 consumidores não processam nenhuma mensagem.
-
Número igual de consumidores e filas: cada consumidor processa mensagens de exatamente uma fila.
-
Menos consumidores do que filas: cada consumidor processa mensagens de várias filas.
Acúmulo de mensagens
No balanceamento de carga baseado em filas, um consumidor pode não conseguir processar prontamente as mensagens da fila atribuída devido a restrições de hardware, limites do sistema, problemas de Remote Procedure Call (RPC) ou pausas do Java Garbage Collection (GC). Quando isso ocorre, as mensagens se acumulam na fila.