Arquitectura técnica de RocketMQ (tres)

1 Arquitectura técnica

La arquitectura de RocketMQ se divide principalmente en cuatro partes, como se muestra en la figura anterior:

• Productor: la función de la publicación de mensajes, que admite la implementación de clústeres distribuidos. Producer selecciona la cola de clúster de Broker correspondiente 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.
• Consumidor: la función del consumo de mensajes, que admite la implementación de clústeres distribuidos. Admite dos modos de empujar y tirar para consumir mensajes. Al mismo tiempo, también admite el consumo de modo de clúster y modo de transmisión. Proporciona un mecanismo de suscripción de mensajes en tiempo real para satisfacer las necesidades de la mayoría de los usuarios.
• NameServer: NameServer es un centro de registro de enrutamiento de temas muy simple.Su función es similar a la del guardián del zoológico en Dubbo y admite el registro dinámico y el descubrimiento de Broker. Incluye principalmente dos funciones: Gestión de broker, NameServer acepta la información de registro del clúster de Broker y la guarda como los datos básicos de la información de enrutamiento. Luego proporcione un mecanismo de detección de latidos para verificar si el Broker aún está activo; administración de información de enrutamiento, cada NameServer guardará toda la información de enrutamiento sobre el clúster de Broker y la información de la cola para las consultas de los clientes. Luego, el Productor y el Conumser pueden conocer la información de enrutamiento de todo el clúster de Broker a través de NameServer, para entregar y consumir mensajes. NameServer generalmente se implementa en un clúster y las instancias no se comunican entre sí. Broker registra su propia información de enrutamiento con cada NameServer, por lo que cada instancia de NameServer guarda una información de enrutamiento completa. Cuando un NameServer se desconecta por alguna razón, el Broker aún puede sincronizar su información de enrutamiento con otros NameServers, y el Productor y el Consumidor aún pueden percibir dinámicamente la información de enrutamiento del Broker.
• BrokerServer: Broker es el principal responsable del almacenamiento, entrega y consulta de los mensajes, así como de la garantía de alta disponibilidad del servicio, para la realización de estas funciones, Broker incluye los siguientes submódulos importantes.

1. Módulo Remoting: La entidad de todo el Broker, responsable de procesar las solicitudes de los clientes.
2. Administrador de clientes: Responsable de administrar el cliente (Productor / Consumidor) y mantener la información de suscripción del Tema del Consumidor.
3. Servicio de tienda: proporciona una interfaz API conveniente y sencilla para procesar el almacenamiento de mensajes en el disco duro físico y funciones de consulta.
4. Servicio HA: Servicio de alta disponibilidad, que proporciona la función de sincronización de datos entre Master Broker y Slave Broker.
5. Servicio de índice: servicio de índice para mensajes entregados al corredor de acuerdo con una clave de mensaje específica para proporcionar una consulta rápida de mensajes.

2 arquitectura de implementación

[Error en la transferencia de la imagen del enlace externo. El sitio de origen puede tener un mecanismo anti-hotlink. Se recomienda guardar la imagen y subirla directamente (img-6MCviSPf-1606900409585) (https://github.com/apache/rocketmq/raw/master/docs/cn /image/rocketmq_architecture_3.png)]

Características de implementación de la red RocketMQ

• NameServer es un nodo casi sin estado que se puede implementar en clústeres sin ninguna sincronización de información entre nodos.
• La implementación del agente es relativamente complicada. El agente se divide en maestro y esclavo. Un maestro puede corresponder a varios esclavos, pero un esclavo solo puede corresponder a un maestro. La correspondencia entre el maestro y el esclavo se define especificando el mismo nombre de agente y diferente BrokerId. BrokerId es 0 Representa maestro, distinto de cero representa esclavo. Master también puede implementar varios. Cada Broker establece una conexión larga con todos los nodos del clúster de NameServer y registra periódicamente la información del tema en todos los NameServers. Nota: La versión actual de RocketMQ admite un maestro y varios esclavos en la arquitectura de implementación, pero solo el servidor esclavo con BrokerId = 1 participará en la carga de lectura de mensajes.
• El Productor establece una conexión larga con uno de los nodos (seleccionados al azar) en el clúster de NameServer, obtiene periódicamente información de enrutamiento de Topic del NameServer, establece una conexión larga con el Master que proporciona el servicio Topic y envía latidos al Master con regularidad. Producer es completamente apátrida y se puede implementar en clústeres.
• El consumidor establece una conexión larga con uno de los nodos (seleccionados al azar) en el clúster de NameServer, obtiene periódicamente información de enrutamiento de Topic del NameServer, establece una conexión larga con el maestro y el esclavo que brindan servicios de tema y envía latidos al maestro y al esclavo con regularidad. Los consumidores pueden suscribirse a los mensajes del Maestro o del Esclavo. Cuando los consumidores extraen mensajes del Maestro, el servidor Maestro determinará si leer los mensajes antiguos o no de acuerdo con la distancia entre el desplazamiento de extracción y el desplazamiento máximo. E / S), así como si el servidor esclavo es legible o no, se recomienda extraer del maestro o esclavo la próxima vez.

Combinado con el diagrama de la arquitectura de implementación, describe el flujo de trabajo del clúster:

• Inicie el servidor de nombres, escuche el puerto después de que se active el servidor de nombres y espere a que el corredor, el productor y el consumidor se conecten, lo que equivale a un centro de control de enrutamiento.
• Broker inicia, mantiene largas conexiones con todos los NameServers y envía paquetes de latidos con regularidad. El paquete de latido contiene la información actual del corredor (IP + puerto, etc.) y almacena toda la información del tema. Después del registro exitoso, existe una relación de mapeo entre Topic y Broker en el cluster NameServer.
• Antes de enviar y recibir mensajes, primero cree un tema. Al crear un tema, debe especificar en qué intermediario se almacenará el tema, o puede crear automáticamente un tema al enviar un mensaje.
• El productor envía un mensaje, establece una conexión larga con uno de los clústeres de NameServer cuando se inicia y obtiene del servidor de nombres en qué intermediarios existe el tema enviado actualmente, el sondeo selecciona una cola de la lista de colas y luego establece con el intermediario dónde se encuentra la cola. La conexión larga envía un mensaje al Broker.
• Consumidor es similar al Productor, establece una conexión larga con uno de los NameServers, obtiene a qué Brokers están suscritos actualmente y luego establece directamente un canal de conexión con el Broker para comenzar a consumir mensajes.

3 Enlace original

注释：来源于GitHub
https://github.com/apache/rocketmq/blob/master/docs/cn/README.md