ApsaraMQ for RocketMQ utiliza directivas de balanceo de carga para controlar cómo los productores enrutan los mensajes a las colas y cómo los brokers asignan mensajes o colas a los consumidores. La directiva del lado del consumidor depende de la versión del SDK de cliente TCP que utilice.
Funcionamiento
ApsaraMQ for RocketMQ admite dos modelos de balanceo de carga para consumidores:
|
Modelo |
Comportamiento del consumidor |
Compatible con |
Característica principal |
|
Basado en mensajes |
Los brokers distribuyen mensajes individuales a los consumidores. Varios consumidores pueden procesar mensajes de la misma cola. |
TCP client SDK for Java V2.x.x.Final, TCP client SDK for C++ V3.x.x |
No hay consumidores inactivos cuando el número de consumidores supera al de colas |
|
Basado en colas |
Los brokers asignan colas completas a los consumidores. Cada cola la procesa exactamente un consumidor. |
TCP client SDK for Java V1.x.x.Final, TCP client SDK for C++ V1.x.x y V2.x.x |
El número de consumidores no debe superar al de colas para evitar consumidores inactivos |
El balanceo de carga del productor funciona igual en ambos modelos:
Mensajes no ordenados (mensajes normales, transaccionales, programados y diferidos): Los productores envían mensajes a las colas en orden cíclico (round-robin).
Mensajes ordenados: Los productores envían todos los mensajes con la misma clave de fragmentación a la misma cola.
Directivas de balanceo de carga compatibles con el SDK for Java V2.x.x.Final y el SDK for C++ V3.x.x
Estas directivas de balanceo de carga distribuyen mensajes individuales, no colas completas, a los consumidores. Varios consumidores pueden procesar mensajes de la misma cola simultáneamente; además, ningún consumidor permanece inactivo incluso cuando el número de consumidores supera al de colas.
Requisitos previos
Para usar estas directivas de balanceo de carga, actualice su SDK de cliente TCP:
TCP client SDK for Java: Actualice a la V2.x.x.Final. La instancia debe estar desplegada en una de las siguientes regiones: China (Hangzhou), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Shenzhen), China (Chengdu), Germany (Frankfurt) o Indonesia (Jakarta).
TCP client SDK for C++: Actualice a la V3.x.x. La instancia puede estar desplegada en cualquier región.
Enrutamiento del productor
El balanceo de carga del productor es el mismo sin importar la versión del SDK:
-
Mensajes no ordenados (mensajes normales, transaccionales, programados y diferidos): Los productores envían mensajes a las colas en orden cíclico. En este ejemplo, hay tres colas disponibles. El productor envía Msg1 a Queue 1, Msg2 a Queue 2, Msg3 a Queue 3, Msg4 nuevamente a Queue 1, y así sucesivamente.
-
Mensajes ordenados: Los productores envían todos los mensajes con la misma clave de fragmentación a la misma cola. En este ejemplo, todos los mensajes con la clave de fragmentación 1 van a Queue 1, y todos los mensajes con la clave de fragmentación 2 van a Queue 2.
Asignación de consumidores para mensajes no ordenados
Para los mensajes no ordenados, los brokers distribuyen uniformemente todos los mensajes de un tema entre los consumidores del mismo grupo. Distintos consumidores pueden consumir mensajes de la misma cola simultáneamente.
En este ejemplo, cuatro mensajes en Queue 2 se distribuyen a Consumer 1, Consumer 2, Consumer 3 y Consumer 4, respectivamente. Cada consumidor procesa los mensajes de forma independiente, sin importar a qué cola pertenezcan.
Asignación de consumidores para mensajes ordenados
Para los mensajes ordenados, los brokers distribuyen los mensajes según las claves de fragmentación. Todos los mensajes con la misma clave de fragmentación van al mismo consumidor, lo cual conserva el orden de producción. Los mensajes con diferentes claves de fragmentación pueden distribuirse a distintos consumidores.
: Los mensajes con este color de fondo pertenecen a Queue 1. Por ejemplo, Msg2-1 es el segundo mensaje en Queue 1 y su clave de fragmentación es 1.
: Los mensajes con este color de fondo pertenecen a Queue 2. Por ejemplo, Msg3-2 es el tercer mensaje en Queue 2 y su clave de fragmentación es 2.
En este ejemplo:
Msg1-1, Msg2-1 y Msg3-1 van a Consumer 1 porque comparten la clave de fragmentación 1.
Los mensajes con la clave de fragmentación 2 van a Consumer 2.
Msg4-3 y Msg4-4 van a diferentes consumidores porque tienen distintas claves de fragmentación.
Directivas de balanceo de carga compatibles con el SDK for Java V1.x.x.Final y el SDK for C++ V1.x.x y V2.x.x
Estas directivas de balanceo de carga asignan colas completas a los consumidores. Cada cola la procesa exactamente un consumidor a la vez. La directiva de asignación es la misma para mensajes no ordenados y ordenados.
Distribución de colas
La arquitectura de ApsaraMQ for RocketMQ incluye brokers y servidores de nombres. Un broker reporta la información de ruta del tema a un servidor de nombres. De forma predeterminada, los mensajes de un tema se distribuyen en 8 colas por broker. Una cola es un concepto lógico. Posteriormente, el broker asigna estas colas uniformemente a todos los consumidores del mismo grupo.
Enrutamiento del productor
El balanceo de carga del productor es el mismo que en el SDK for Java V2.x.x.Final y el SDK for C++ V3.x.x:
Mensajes no ordenados: Los productores envían mensajes a las colas en orden cíclico.
Mensajes ordenados: Los productores envían todos los mensajes con la misma clave de fragmentación a la misma cola.
Para más detalles y diagramas, consulte Producer routing arriba.
Asignación de consumidores
Dado que cada cola solo puede asignarse a un consumidor a la vez, la proporción entre consumidores y colas afecta directamente la utilización de recursos:
-
Más consumidores que colas: Los consumidores adicionales permanecen inactivos. Por ejemplo, con 8 colas y 10 consumidores, 2 consumidores no procesan ningún mensaje.
-
Igual número de consumidores y colas: Cada consumidor procesa mensajes de exactamente una cola.
-
Menos consumidores que colas: Cada consumidor procesa mensajes de varias colas.
Acumulación de mensajes
Con el balanceo de carga basado en colas, un consumidor podría no procesar oportunamente los mensajes de su cola asignada debido a limitaciones de hardware, límites del sistema, problemas de llamada a procedimiento remoto (RPC) o pausas de recolección de basura (GC) de Java. Cuando esto ocurre, los mensajes se acumulan en la cola.