El análisis esencial del principio de arquitectura de RocketMq es el núcleo de nuestro artículo, a partir de la comparación del middleware de mensajes, el modelo de arquitectura, el modelo de mensajes, los problemas comunes, etc.:
1. Comparación de software intermedio:
El efecto del clúster RabbitMq no es muy bueno, la capa inferior no es lenguaje Java y el principio de investigación es más difícil;
Kafka está diseñado para escenarios de recopilación de registros y su rendimiento de simultaneidad no es ideal. Especialmente cuando hay demasiados temas, porque habrá demasiados archivos de partición, lo que afectará seriamente el rendimiento de E/S;
Aunque el rendimiento de mensajes de RocketMQ aún no es tan bueno como el de Kafka, es mucho mayor que el de RabbitMQ. Dentro de Ali, el clúster RocketMQ procesa más de 5 billones de solicitudes por día y admite más de 3000 aplicaciones principales.
RocketMQ es un middleware de mensajes de código abierto de Alibaba. Ha pasado por la prueba de muchos escenarios de alta concurrencia, como Double Eleven dentro de Alibaba, y puede manejar cientos de millones de mensajes. Donado a Apache después del código abierto en 2016, ahora es un proyecto de nivel superior de Apache.
En la actualidad, RocketMQ tiene una versión comercial disponible para su compra en Alibaba Cloud. La versión comercial integra algunas funciones más profundas y personalización de O&M dentro de Alibaba. Lo que estamos aprendiendo aquí es la versión de código abierto de Apache. En comparación con la versión comercial en Alibaba Cloud, a la versión de código abierto le faltan algunas funciones, pero en general las funciones son las mismas.
2. Principio de funcionamiento básico de RocketMq
RocketMQ consta de los siguientes componentes:
NameServer: proporciona servicios de enrutamiento de Broker ligeros.
Broker: el componente central que realmente maneja servicios como el almacenamiento y el reenvío de mensajes.
Productor: Clúster productor de mensajes. Suele ser un módulo funcional en el sistema empresarial.
Consumidor: grupo de consumidores de mensajes. Por lo general, también es un módulo funcional en el sistema empresarial.
Entonces, si queremos iniciar el servicio RocketMQ, primero debemos iniciar NameServer y luego iniciar Broker.
3. Modelo de reenvío de mensajes
1 Modelo de mensaje (Modelo de mensaje)
RocketMQ se compone principalmente de Productor, Corredor y Consumidor.Entre ellos, el Productor es responsable de producir mensajes, el Consumidor es responsable de consumir mensajes y el Corredor es responsable de almacenar mensajes. Broker corresponde a un servidor en el proceso de implementación real. Cada Broker puede almacenar mensajes de múltiples Temas, y los mensajes de cada Tema también se pueden fragmentar y almacenar en diferentes BrokerMessage Queues para almacenar la dirección física del mensaje. Las direcciones de mensajes se almacenan en múltiples Colas de mensajes. ConsumerGroup consta de varias instancias de consumidor.
2 El productor de mensajes (Producer)
es el encargado de producir los mensajes, generalmente el sistema empresarial es el encargado de producir los mensajes. Un productor de mensajes envía mensajes generados en el sistema de aplicaciones comerciales al servidor de intermediario. RocketMQ proporciona una variedad de métodos de envío, envío síncrono, envío asíncrono, envío secuencial y envío unidireccional. Tanto los métodos síncronos como los asíncronos requieren que Broker devuelva información de confirmación, y la transmisión unidireccional no. Entre los productores, el mismo tipo de Productores se combinará en un conjunto, denominado grupo de productores. Se considera que los productores del mismo grupo envían el mismo tipo de mensaje y la lógica de envío es consistente.
3 El consumidor de mensajes (Consumer)
es el encargado de consumir los mensajes, normalmente el sistema de fondo se encarga del consumo asíncrono. Un consumidor de mensajes extraerá mensajes del servidor Broker y los proporcionará a la aplicación. Desde la perspectiva de las aplicaciones de usuario, se prevén dos formas de consumo: consumo pull y consumo push. Las aplicaciones de consumo de extracción suelen llamar al método de extracción de mensajes del consumidor para extraer mensajes del servidor del intermediario y la aplicación controla la iniciativa. Una vez que se obtiene el lote de mensajes, la aplicación inicia el proceso de consumo. En el modo de consumo push, el corredor empujará activamente los datos al consumidor después de recibir los datos.Este modo de consumo generalmente tiene un alto rendimiento en tiempo real. Los Consumidores también formarán una colección del mismo tipo de Consumidores, denominada grupo de consumidores, tales Consumidores generalmente consumen el mismo tipo de mensajes y la lógica de consumo es consistente. Los grupos de consumidores facilitan mucho el logro de los objetivos de equilibrio de carga y tolerancia a fallas en términos de consumo de mensajes. Cabe señalar que las instancias de consumidor del grupo de consumidores deben suscribirse exactamente al mismo tema. RocketMQ admite dos modos de mensajes: consumo de clúster (Clustering) y consumo de transmisión (Broadcasting). En el modo de consumo de clúster, cada instancia de consumidor del mismo grupo de consumidores comparte mensajes por igual. En el modo de consumo de difusión, cada instancia de consumidor del mismo grupo de consumidores recibe la cantidad total de mensajes.
4 Topic (Tema)
representa una colección de una clase de mensajes, cada tema contiene varios mensajes, y cada mensaje solo puede pertenecer a un tema, que es la unidad básica de RocketMQ para la suscripción de mensajes. El tema es solo un concepto lógico y en realidad no almacena mensajes. Los mensajes bajo el mismo tema se almacenarán en fragmentos en diferentes agentes, y cada unidad de fragmentación se denomina MessageQueue. MessageQueue es una estructura de cola con características FIFO, la unidad más pequeña para que los productores envíen mensajes y los consumidores consuman mensajes.
5 Broker Server (Servidor Broker)
función de transferencia de mensajes, responsable de almacenar y reenviar mensajes. En el sistema RocketMQ, el servidor proxy es responsable de recibir y almacenar los mensajes enviados por el productor y, al mismo tiempo, preparar la solicitud de extracción del consumidor. El servidor proxy también almacena metadatos relacionados con mensajes, incluidos grupos de consumidores, compensaciones de progreso de consumo, temas y mensajes en cola.
Broker Server es el núcleo comercial real de RocketMQ, que incluye varios submódulos importantes:
Módulo remoto: la entidad de todo el Broker, que es responsable de procesar las solicitudes de los clientes.
Administrador de clientes: responsable de administrar el cliente (productor/consumidor) y mantener la información de suscripción de temas del consumidor
Servicio de almacenamiento: proporciona una interfaz API conveniente y simple para manejar el almacenamiento de mensajes en el disco duro físico y las funciones de consulta.
Servicio HA: Servicio de alta disponibilidad, que proporciona la función de sincronización de datos entre Master Broker y Slave Broker.
Servicio de índice: según la clave de mensaje específica, el mensaje entregado al corredor se indexa para proporcionar una consulta rápida del mensaje. Para garantizar una alta disponibilidad, Broker Server necesita construir una arquitectura de clúster maestro-esclavo. Hay dos modos de arquitectura Broker en RocketMQ:
Clúster ordinario:
en este modo de clúster, a cada nodo se le asigna un rol fijo y el maestro es responsable de responder a las solicitudes de los clientes y almacenar los mensajes. El esclavo solo es responsable de guardar sincrónicamente los mensajes del maestro y responder a las solicitudes de lectura de algunos clientes. Los métodos de sincronización de mensajes se dividen en sincronización síncrona y sincronización asíncrona. En este modo de clúster, el rol de cada nodo no se puede cambiar, es decir, si el nodo maestro está inactivo, este grupo de Brokers no estará disponible.
Clúster de alta disponibilidad de Dledger:
Dledger es una tecnología introducida por RocketMQ desde la versión 4.5 para realizar un clúster de alta disponibilidad. El clúster en este modo seleccionará aleatoriamente un nodo como maestro y, cuando el nodo maestro cuelgue, seleccionará automáticamente un nodo del esclavo para actualizarlo al maestro.
Lo que hace la tecnología Dledger: 1. Elige el nodo maestro del clúster 2. Completa la sincronización de mensajes desde el nodo maestro al nodo esclavo.
6 Servicio de nombres (Servidor de nombres)
El servicio de nombres actúa como proveedor de enrutamiento de mensajes. Broker Server registrará su propia información de servicio con todos los NameServers al inicio y luego garantizará el rendimiento en tiempo real de esta información de servicio a través de solicitudes de latidos. Los productores o consumidores pueden buscar la lista de IP de Broker correspondiente para cada tema a través del servicio de nombres. Varias instancias de Namesrv forman un clúster, pero son independientes entre sí y no hay intercambio de información. Esta característica también significa que cualquier nodo en el NameServer cuelga. Mientras un nodo de servicio sea normal, todo el servicio de enrutamiento no se verá afectado. Por supuesto, la carga de los nodos no se considera aquí.
7 Mensaje (Message)
El portador físico de la información transmitida por el sistema de mensajes, la unidad más pequeña de datos de producción y consumo, y cada mensaje debe pertenecer a un tema Topic. Cada mensaje en RocketMQ tiene una ID de mensaje única y puede llevar una clave con un identificador comercial. El sistema proporciona la función de consultar mensajes por ID de mensaje y clave. Y hay una marca establecida para el mensaje en el mensaje, la etiqueta Tag. Se utiliza para distinguir diferentes tipos de mensajes bajo el mismo tema. Para mensajes de la misma unidad comercial, se pueden establecer diferentes etiquetas bajo el mismo tema de acuerdo con diferentes propósitos comerciales. Las etiquetas pueden mantener efectivamente la claridad y la coherencia del código y optimizar el sistema de consulta proporcionado por RocketMQ. Los consumidores pueden implementar diferentes lógicas de consumo para diferentes subtemas basados en etiquetas para lograr una mejor escalabilidad.
El concepto básico general se resume en la siguiente figura:
Hasta ahora, se han compartido los principios básicos de RocketMq. En la siguiente parte, compartiremos los problemas encontrados en el uso, ¡así que estad atentos!