[RocketMQ advanced one] Principio y arquitectura de RocketMQ

Diagrama de componentes centrales de RocketMQ

RocketMQ es un middleware de mensajes de código abierto, que se compone principalmente de NameServer, Producer, Broker y Consumer.

NameServer : NameServer es el principal responsable de la gestión de la información de enrutamiento y temas, y su función es similar a la del guardián del zoológico de Dubbo.
Productor : El productor de mensajes, responsable de generar mensajes, generalmente el sistema empresarial se encarga de generar mensajes.
Broker : Rol de retransmisión de mensajes, responsable de almacenar y reenviar mensajes.
Consumidor : consumidor de mensajes, responsable del consumo de mensajes, generalmente el sistema en segundo plano es responsable del consumo asincrónico.

Diagrama de implementación física de RokcetMQ

NameServer : NameServer es un nodo casi sin estado que se puede implementar en clústeres sin ninguna sincronización de información entre nodos.

Broker : Dividido en Master y Slave. Un Master puede corresponder a múltiples Slaves, pero un Slave solo puede corresponder a un Master. La correspondencia entre Master y Slave se define especificando el mismo BrokerName y diferente BrokerId. Un BrokerId de 0 significa Master. 0 significa esclavo. Master también puede implementar varios. Cada Broker establece una conexión larga con todos los nodos del clúster del servidor de nombres y registra periódicamente la información del tema en todos los servidores de nombres. Master admite lectura y escritura, mientras que Slave solo admite lectura .

Productor : El productor establece una conexión larga con uno de los nodos (seleccionados al azar) en el clúster del servidor de nombres, obtiene periódicamente información de enrutamiento del tema del servidor de nombres, establece una conexión larga con el maestro que proporciona el servicio del tema y envía latidos al maestro con regularidad . Producer es completamente apátrida y se puede implementar en clústeres .

Consumidor : El consumidor establece una conexión prolongada con uno de los nodos en el clúster del servidor de nombres (seleccionado al azar), obtiene regularmente información de enrutamiento de temas del servidor de nombres y establece una conexión prolongada con el maestro y el esclavo que brindan servicios de tema y envía latidos al maestro y al esclavo con regularidad . El consumidor puede suscribirse a los mensajes del maestro o esclavo, y las reglas de suscripción están determinadas por la configuración del intermediario.

Estructura de implementación lógica de RocketMQ

Grupo de productores

Usado para representar una aplicación de envío de mensajes, un Grupo de productores contiene múltiples instancias de Productor, que pueden ser múltiples máquinas, múltiples procesos de una máquina o múltiples objetos Productor de un proceso. Un Grupo de Productores puede enviar múltiples mensajes de Temas. Las funciones del Grupo de Productores son las siguientes:

Identificar un tipo de productor
Puede consultar varias instancias de Producer en esta aplicación de mensajería a través de herramientas de operación y mantenimiento
Al enviar mensajes de transacciones distribuidas, si el Productor se cae inesperadamente a la mitad, el Broker llamará activamente a cualquier máquina del Grupo de Productores para confirmar el estado de la transacción.

Grupo de consumidores

Se utiliza para representar una aplicación de mensajes de consumidor. Un grupo de consumidores contiene varias instancias de consumidor, que pueden ser varias máquinas, varios procesos o varios objetos de consumidor de un proceso. Varios consumidores de un grupo de consumidores consumen mensajes de forma amortizada. Si está configurado para transmitir, cada instancia de este grupo de consumidores consume la cantidad total de datos.

Mecanismo de eliminación y registro de enrutamiento de NameServer

El agente envía un paquete de latidos a NameServer cada 30 segundos y el paquete de latidos contiene información de enrutamiento para el tema.
NarneServer actualiza la información en brokerLiveTable después de recibir el paquete de latido del Broker, especialmente registrando el tiempo de latido lastUpdateTime
NarneServer escanea el brokerLiveTable cada 10 segundos, detecta la última vez que se recibió el paquete de latidos en la tabla, compara la hora actual con la última vez, si supera los 120 segundos , el corredor se considera no disponible y se elimina toda la información relacionada con el corredor en la tabla de enrutamiento
El productor del mensaje extrae la información de enrutamiento del tema, es decir, el productor del mensaje no percibe inmediatamente la adición y eliminación del servidor Broker .

Nota : Productor (productor de mensajes), en primer lugar, tiene que saber a qué Broker se enviará el mensaje, por lo que cada 30 segundos obtendrá la relación de mapeo de Topic y Broker de un NameServer y la almacenará en la memoria local.Si se encuentra un nuevo Broker, se establecerá con él. Conexión larga, se enviarán latidos al corredor cada 30 segundos para mantener la conexión . Y va a sondear el Broker disponibles actualmente para enviar mensajes de lograr el objetivo de equilibrio de carga :

Envío síncrono , si el envío falla, se reintentará dos veces de forma predeterminada (retryTimesWhenSendFailed = 2) , y el corredor que falló la última vez no será seleccionado y la entrega se enviará a otros corredores .
Envío asincrónico , volverá a intentarlo en caso de falla. El valor predeterminado también es dos veces (retryTimesWhenSendAsyncFailed = 2), pero solo en el mismo Broker .

Diagrama del modelo de dominio de mensajes de RocketMQ

Tema

El tema representa el tipo de mensajes de primer nivel. Por ejemplo, los mensajes de un sistema de comercio electrónico se pueden dividir en: mensajes de transacciones, mensajes de logística, etc. Un mensaje debe tener un tema.
La unidad de suscripción más detallada, un grupo puede suscribirse a varios mensajes de temas.

Etiqueta : indica el tipo de mensaje de segundo nivel. Por ejemplo, los mensajes de transacción se pueden dividir en: mensajes de creación de transacciones, mensajes de finalización de transacciones, etc. RocketMQ proporciona una clasificación de mensajes de dos niveles para un control conveniente y flexible.

Grupo de grupo : un grupo puede suscribirse a varios temas.

Cola de mensajes : la unidad de gestión física del mensaje. Puede haber varias colas en un tema, y la introducción de colas permite que el almacenamiento de mensajes se distribuya y agrupe, con escalabilidad horizontal.

En RocketMQ, todas las colas de mensajes son estructuras de datos persistentes con longitud ilimitada. La denominada longitud ilimitada significa que cada unidad de almacenamiento en la cola es de longitud fija. Se accede a la unidad de almacenamiento mediante Offset, y el desplazamiento es de tipo java long. , 64 bits, teóricamente no se desbordará en 100 años, por lo que se considera que tiene una duración ilimitada.

También puede pensar en Message Queue como una matriz de longitud ilimitada, y Offset es el subíndice.

Esquema de mensaje de secuencia

El orden de consumo de mensajes debe ser el mismo que el orden de envío de mensajes. En RocketMQ, la parte principal es el orden local, es decir, un tipo de mensaje debe ser enviado en secuencia en un solo hilo por el Productor y enviado a la misma cola, para que el Consumidor pueda seguir El productor consume los mensajes en el orden en que se envían.

Diagrama de principio de diseño de almacenamiento de mensajes de RocketMQ

CommitLog : archivo de almacenamiento de mensajes, todos los mensajes del asunto del mensaje se almacenan en el archivo CommitLog. La vista lógica del almacenamiento de archivos Commitlog se muestra en la figura

ConsumeQueue

Cola de consumo de mensajes. Una vez que el mensaje llega al archivo CommitLog, se reenviará de forma asincrónica a la cola de consumo de mensajes para que lo consuman los consumidores de mensajes. El formato de almacenamiento de ConsumeQueue es el siguiente:

Un solo archivo ConsumeQueue contiene 300,000 entradas de forma predeterminada. La longitud de un solo archivo es 30w × 20 bytes. Un solo archivo ConsumeQueue puede verse como una matriz de entradas ConsumeQueue. Su subíndice es el desplazamiento lógico de ConsumeQueue, y el progreso de consumo del mensaje se almacena El desplazamiento es el desplazamiento lógico.
ConsumeQueue es el archivo de índice del archivo de Commitlog, y su mecanismo de construcción es que cuando el mensaje llega al archivo de Commitlog, un hilo especial genera una tarea de reenvío de mensajes para construir el archivo de cola de consumo de mensajes y el archivo de índice mencionado a continuación.

IndexFile : archivo de índice de mensajes, que almacena principalmente la correspondencia entre la clave del mensaje y la compensación.

La cola de consumo de mensajes es un archivo de índice especialmente creado por RocketMQ para las suscripciones de mensajes, lo que mejora la velocidad de recuperación de mensajes según los temas y las colas de mensajes. Además, RocketMQ introduce un mecanismo de índice Hash para indexar mensajes. El diseño de HashMap incluye dos puntos básicos: ranura Hash y Hash Estructura de lista enlazada en conflicto. El diseño del archivo de índice RocketMQ se muestra en la figura

lndexFile contiene lndexHeader, ranura Hash y entradas Hash en total

Servicio de estado de transacciones

Almacene el estado de la transacción de cada mensaje.

Servicio de mensajes cronometrados

Cada nivel de retraso corresponde a una cola de consumo de mensajes, que almacena el progreso de extracción de mensajes de la cola de retraso.

Capa de modelo de almacenamiento de archivos RMQ

Capa de procesador empresarial RocketMQ

El lado del corredor lee y escribe la entrada de la lógica empresarial del mensaje. Esta capa contiene principalmente operaciones de procesamiento relacionadas con la lógica empresarial (basadas en el análisis del RequestCode en RemotingCommand para distinguir tipos específicos de operaciones empresariales y luego ejecutar diferentes procedimientos de procesamiento empresarial). Tales como pasos de verificación previa y verificación, construcción del objeto MessageExtBrokerInner, decodificación de deserialización, construcción del objeto de retorno de respuesta, etc.

Capa de componentes de almacenamiento de datos de RocketMQ

Esta capa es principalmente la clase central de almacenamiento de RocketMQ: DefaultMessageStore, que es la entrada de acceso para los archivos de datos de mensajes de RocketMQ. Los métodos "putMessage ()" y "getMessage ()" de esta clase se utilizan para leer y escribir los archivos de datos de registro almacenados por los mensajes de CommitLog. Operación (la operación de acceso de lectura y escritura específica aún depende del método proporcionado por el modelo de objetos CommitLog en la siguiente capa);
Además, cuando se inicializa el componente, se iniciarán muchos subprocesos de servicio en segundo plano relacionados con el almacenamiento, incluido AllocateMappedFileService (subproceso de servicio de asignación previa de MappedFile), ReputMessageService (subproceso de servicio de mensajes de almacenamiento de reproducción), HAService (subproceso de servicio de alta disponibilidad de sincronización maestro-esclavo de intermediario) StoreStatsService (hilo de servicio de estadísticas de almacenamiento de mensajes), IndexService (hilo de servicio de archivo de índice), etc.

Capa de objetos lógicos de almacenamiento de RocketMQ

Esta capa contiene principalmente tres clases de modelo IndexFile, ConsumerQueue y CommitLog directamente relacionadas con el almacenamiento de archivos de datos de RocketMQ.
IndexFile proporciona servicios de acceso para archivos de datos de índice, ConsumerQueue proporciona servicios de acceso para colas de mensajes lógicos y CommitLog proporciona servicios de acceso para archivos de datos de registro almacenados en mensajes.
Estas tres clases de modelos también constituyen la estructura general de la capa de almacenamiento de RocketMQ.

Capa de mapeo de memoria de archivos encapsulada

RocketMQ utiliza principalmente MappedByteBuffer y FileChannel en JDK NIO para completar la lectura y escritura de archivos de datos.
Entre ellos, MappedByteBuffer se usa para completar la lectura y escritura de archivos grandes en un método de archivo de disco mapeado en memoria, y esta clase está encapsulada en una clase MappedFile en RocketMQ.
Aquí, la clase MappedFile proporciona cada tipo de archivo único para proporcionar servicios de operación de lectura y escritura (entre los cuales, la clase MappedFile proporciona escritura secuencial / lectura aleatoria, actualización de datos de memoria, limpieza de memoria, etc. y servicios relacionados con archivos).

Capa de almacenamiento en disco

Se refiere principalmente al disco utilizado para implementar el servidor RocketMQ. Aquí, debe considerar el impacto de los diferentes tipos de discos (como SSD o HDD ordinario), las características y los parámetros de rendimiento del disco (como IOPS, rendimiento y latencia de acceso) en las operaciones de escritura secuencial / lectura aleatoria.

Actualización de mensaje en RocketMQ

El cepillado de mensajes en RocketMQ se puede dividir en dos tipos: cepillado sincrónico y cepillado asincrónico.

Parpadeo sincrónico

Cuando se devuelve el estado de escritura exitosa, el mensaje se ha escrito en el disco.
El proceso específico es que después de que el mensaje se escribe en el PAGECACHE de la memoria, inmediatamente informa al hilo que parpadea para que parpadee y luego espera a que se complete el parpadeo. Después de que se ejecuta el hilo que parpadea, el hilo en espera se despierta y el mensaje se vuelve a escribir correctamente.
Generalmente solo se usa en escenarios financieros.

Cepillado asincrónico

Cuando se devuelve el estado de escritura exitosa, el mensaje solo se puede escribir en la PAGECACHE de la memoria. La operación de escritura regresa rápidamente y el rendimiento es grande; cuando la cantidad de mensajes en la memoria se acumula hasta cierto punto, la operación de escritura en disco se activa de manera uniforme y se escribe rápidamente.

Original: https://blog.csdn.net/zhuyanlin09/article/details/101751549