RocketMQ (III) - Arquitectura del sistema

La arquitectura RocketMQ se divide en cuatro partes principales:

El productor de mensajes es responsable de producir mensajes. El productor selecciona la cola de clúster de Broker adecuada para la entrega de mensajes a través del módulo de equilibrio de carga de. MQ. El proceso de entrega admite fallas rápidas y baja latencia.

Los productores de mensajes RocketMQ existen en forma de grupos de productores. Un grupo de productores es una colección de productores del mismo tipo que envían mensajes del mismo tipo de tema. Un grupo de productores puede enviar mensajes a varios temas al mismo tiempo.

Los consumidores de mensajes son responsables de consumir mensajes. Los consumidores de mensajes obtienen mensajes del servidor proxy y realizan procesamiento comercial en los mensajes.

Los consumidores de mensajes en RocketMQ aparecen en forma de grupos de consumidores. Un grupo de consumidores es una colección de consumidores unificados que consumen mensajes del mismo tipo de tema. En el método de consumo de mensajes, el grupo de consumidores implementa equilibrio de carga (diferentes colas en el tema se distribuyen uniformemente a diferentes consumidores en el mismo grupo de consumidores en lugar de equilibrio de carga) y tolerancia a fallas (el consumidor se cuelga, otros consumidores pueden consumir de la cola consumida por el grupo de consumidores). Colas consumidas por consumidores) el objetivo se vuelve muy fácil

El número de consumidores en el grupo de consumidores debe ser menor o igual que el número de colas en el tema. Si se excede la cantidad de colas, los consumidores adicionales no podrán consumir mensajes.

Sin embargo, los mensajes de tipo Tema pueden ser consumidos por varios grupos de consumidores al mismo tiempo.

NameServer es un registro para el enrutamiento de corredores y temas, que admite el registro dinámico y el descubrimiento de corredores.

El concepto de RocketMQ proviene de Kafuka de Zookeeper. Por lo tanto, las primeras versiones de RocketMQ dependían de Zookeeper y, a partir de la versión 3.0, eliminaron la dependencia de Zookeeper a favor de usar su propio NameServer.

NameServer también suele implementarse como un clúster, pero NameServer no tiene estado, lo que significa que NameServer es un clúster de nodos que no están conectados entre sí. Los nodos individuales del clúster no se pueden distinguir entre sí y los nodos no se pasan información entre sí. ¿Cómo sincronizar datos en cada nodo? Cuando se inicia un nodo Broker, sondea la lista de NameServer, establece una conexión persistente con cada nodo de NameServer e inicia una solicitud de registro. En NameServer, se mantiene una lista de Broker para almacenar dinámicamente la información del Broker

Para demostrar que está activo y mantener una conexión larga con NameServer, el nodo Broker informará la información más reciente al NameServer a través de un paquete de latidos, que se envía cada 30 segundos. El paquete de latidos contiene BrokerId, dirección de Broker (puerto IP), nombre de Broker, nombre del clúster de Broker y otra información. Después de recibir el paquete de latidos, NameServer actualizará la marca de tiempo de los latidos para registrar el último tiempo de supervivencia del Broker.

Si el NameServer no recibe los latidos del broker debido a motivos como el cierre del broker, el tiempo de inactividad o la fluctuación de la red,

Hay una tarea programada en el NameServer que escanea cada 10 segundos. Tabla de corredores, verifique la marca de tiempo del último latido de cada corredor. Si la marca de tiempo del último latido está a más de 120 segundos de la hora actual, se determina que Broekr ha fallado y luego se elimina de la lista de corredores.

El descubrimiento de rutas RocketMQ utiliza el modo pull.

Cuando la información de enrutamiento del tema cambia, NameServer no la enviará activamente al cliente, pero el cliente extraerá periódicamente las rutas más recientes. De forma predeterminada, la última ruta se extrae cada 30 segundos.

El cliente debe escribir la dirección del clúster de NameServer al reconfigurarlo, entonces, ¿a qué nodo de NameServer debería conectarse el cliente? El cliente primero genera un número aleatorio, luego lo multiplica por el número de nodos de NameServer para obtener el índice de nodo al que conectarse y luego se conecta. Si la conexión falla, se utiliza una estrategia de operación por turnos para intentar conectarse a otros nodos uno por uno.

Primero use una estrategia aleatoria para la selección y, después del fracaso, use una estrategia de encuesta.

El corredor actúa como un transmisor de mensajes y es responsable de almacenar y reenviar mensajes, recibir y almacenar mensajes de los productores en el sistema RocketMQ, preparar las solicitudes de extracción de los consumidores y almacenar metadatos relacionados con los mensajes, incluidos los consumidores. grupos, compensaciones de progreso del consumidor, temas, colas, etc.

El corredor almacena metadatos relacionados con los mensajes, incluidos grupos de consumidores, compensaciones de progreso del consumidor, temas, colas, etc.

Un corredor es el primer nodo que intenta conectarse a otro nodo, cola, etc.

Módulo remoto: toda la entidad Broker que maneja las solicitudes de los clientes. La entidad Broker consta de los siguientes módulos.

Gestor de Clientes: Gestor de Clientes. Responsable de recibir y analizar las solicitudes de los clientes (productor/consumidor) y gestionar los clientes.

Servicios de almacenamiento. Proporciona una interfaz API cómoda y sencilla para gestionar el almacenamiento de mensajes y las funciones de consulta de mensajes en discos duros físicos.

Servicio HA: Servicio de alta disponibilidad que proporciona sincronización de datos entre el broker maestro (Master Broker) y el broker esclavo (Slave Broker).

Servicio de indexación: Servicio de indexación. Según una clave de mensaje específica, el servicio de índice del mensaje se entrega al corredor y también se proporciona una consulta rápida de mensajes basada en la clave del mensaje.

Para mejorar el rendimiento y el rendimiento del corredor, el Broker generalmente adopta la forma de un cluster.

Si el nodo Broker deja de funcionar, ¿cómo garantizar que no se pierdan datos?

La solución es escalar cada nodo del clúster Broekr, es decir, construir el nodo Broker en otro clúster HA para resolver el problema del punto único.

El clúster de nodos Broker es un clúster maestro-esclavo, que tiene dos roles: Maestro y Esclavo. El Maestro es responsable de procesar las solicitudes de operación de lectura y escritura, y el Esclavo es responsable de hacer una copia de seguridad de los datos en el Maestro. Cuando el servidor principal se cuelga, Slaver cambiará automáticamente para funcionar en el servidor principal. Por lo tanto, este clúster de Broker es un clúster maestro/de respaldo, y la correspondencia entre el maestro y el esclavo se determina especificando el mismo BrokerName y diferente BrokerId. BrokerId 0 representa la estación maestra y distinto de 0 representa la estación esclava.

② Conéctese y registre periódicamente información del tema con todos los NameServers.

① Inicie NameServer Después de que se inicie NameServer, comienza a escuchar el puerto y espera a que el Broker, el Productor y el Consumidor se conecten.

② Cuando se inicia el Broker, se inicia. mantendrá conexiones largas con todos los NameServers, y el Broker mantendrá conexiones largas con todos los NameServers. NameServer mantiene una conexión larga y envía un paquete de latidos a NameServer cada 30 segundos

③ Antes de enviar un mensaje, puede crear. un tema. Al crear un tema, debe especificar en qué corredor desea almacenar el tema. Por supuesto, también debe escribir la relación entre el tema y el corredor en NameServer. También puedes crear automáticamente un tema al enviar un mensaje.

④ El productor envía el mensaje. Al principio, primero establece una conexión larga con uno de los clústeres de NameServer y obtiene información de enrutamiento del NameServer, es decir, la relación de mapeo entre la cola que actualmente envía el tema y la dirección del corredor. Luego, de acuerdo con la estrategia del algoritmo, se selecciona una cola de la cola y se establece una conexión larga con el Broker donde se encuentra la cola para enviar mensajes al Broker.

⑤ El consumidor es similar al productor: establece una conexión larga con uno de los NameServers para obtener la información de enrutamiento del tema al que se suscribe y luego obtiene la cola que desea consumir del enrutamiento. información de acuerdo con la estrategia del algoritmo, y luego se comunica con el Broker, establece una conexión larga para consumir los mensajes que contiene. El consumidor envía un latido al Broker para garantizar que el Broker esté activo

Al crear un tema manualmente, hay dos modos:

Al crear un tema automáticamente, el modo predeterminado es Modo Broker. Se crearán cuatro colas para cada Broker.

Físicamente, la cola de lectura/escritura es la misma cola. Por lo tanto, no existe ningún problema de sincronización de datos de la cola de lectura/escritura. Las colas de lectura/escritura son conceptos lógicamente distintos. En términos generales, el número de colas de lectura/escritura es el mismo.

Diferentes números de colas de lectura/escritura son problemáticos.

Pero esto hace que sea más fácil acotar

perm se usa para establecer los permisos para operar en el tema creado actualmente: 2 significa solo escritura, 4 significa solo lectura y 6 significa leer/escribir