22 preguntas y respuestas comunes de la entrevista RocketMQ

Un middleware de mensajes Java puro con un modelo de cola distribuida, que fue de código abierto por Alibaba en 2012. Fue donado a la Apache Software Foundation y se convirtió en un proyecto de alto nivel de Apache el 25 de septiembre de 2017 . Como middleware nacional que ha experimentado muchas veces el bautismo de "súper ingeniería" como Double Eleven de Alibaba y tiene un rendimiento estable y sobresaliente, tiene las características de alto rendimiento, baja latencia y alta confiabilidad. Se utiliza principalmente para desacoplamiento, reducción de picos, distribución de mensajes, etc.

2. ¿Cuál es la función de RocketMQ?

1. Desacoplamiento de aplicaciones
Cuanto mayor sea el acoplamiento del sistema, menor será la tolerancia a fallas. Tomando una aplicación de comercio electrónico como ejemplo, después de que un usuario crea un pedido, si el sistema de inventario, el sistema de logística y el sistema de pago están acoplados y llamados, si algún subsistema falla o no está disponible temporalmente debido a actualizaciones, etc., causar una operación anormal del pedido y afectar la experiencia de uso del usuario. Al utilizar el desacoplamiento de la cola de mensajes, se mejorará el acoplamiento del sistema. Por ejemplo, si el sistema logístico falla, la reparación demora unos minutos, durante este tiempo los datos que procesará el sistema logístico se almacenan en caché en la cola de mensajes y la operación del pedido del usuario se completa normalmente. Una vez que el sistema logístico responde, solo necesita complementar y procesar los mensajes de pedido almacenados en la cola de mensajes, y el sistema terminal no se dará cuenta de la falla del sistema logístico durante unos minutos.

2. Recorte del pico de tráfico
Si el sistema de aplicaciones encuentra un aumento repentino en el tráfico de solicitudes del sistema, puede saturar el sistema. Con la cola de mensajes, se puede almacenar en caché y procesar una gran cantidad de solicitudes durante un largo período de tiempo, lo que puede mejorar en gran medida la estabilidad del sistema y la experiencia del usuario.

3. Distribución de datos
A través de la cola de mensajes, los datos pueden circular entre múltiples sistemas. El generador de datos no necesita preocuparse por quién usará los datos, solo necesita enviar los datos a la cola de mensajes, y el usuario de los datos puede obtener los datos directamente en la cola de mensajes.

3. La arquitectura de RoctetMQ

Productor: remitente del mensaje; ejemplo: remitente
Consumidor: receptor del mensaje; ejemplo: receptor
Agente: almacenamiento temporal y transmisión de mensajes; ejemplo: oficina de correos
NameServer: agente de gestión; ejemplo: la organización de gestión de cada oficina de correos
Tema: distinguir los tipos de mensajes ;Un remitente puede enviar mensajes a uno o más Temas; un receptor de un mensaje puede suscribirse a uno o más mensajes de Tema. Cola de mensajes
: equivalente a una partición de Tema; se utiliza para enviar y recibir mensajes en paralelo

4. Ventajas y desventajas de RoctetMQ

Ventajas: desacoplamiento, recorte de picos, distribución de datos.

Las desventajas incluyen las siguientes :

1. Disponibilidad reducida del sistema

Cuantas más dependencias externas introduzca el sistema, peor será la estabilidad del sistema. Una vez que MQ caiga, afectará el negocio. ¿Cómo garantizar la alta disponibilidad de MQ?

2. Mayor complejidad del sistema

La adición de MQ ha aumentado considerablemente la complejidad del sistema. En el pasado, había llamadas remotas sincrónicas entre sistemas, pero ahora las llamadas asincrónicas se realizan a través de MQ. ¿Cómo garantizar que los mensajes no se consuman repetidamente? ¿Cómo lidiar con la pérdida de mensajes? Entonces, ¿para garantizar el orden de entrega de los mensajes?

3. Problemas de coherencia

Después de procesar el negocio, el sistema A envía datos de mensajes a tres sistemas B, C y D a través de MQ. Si el sistema B y el sistema C procesan con éxito, el sistema D no puede procesar. ¿Cómo garantizar la coherencia del procesamiento de datos de mensajes?

5. Características del clúster RoctetMQ

NameServer es un nodo casi sin estado que se puede implementar en un clúster sin ninguna sincronización de información entre los nodos.
La implementación del Broker es relativamente complicada. El Broker se divide en Maestro y Esclavo. Un Maestro puede corresponder a múltiples Esclavos, pero un Esclavo solo puede corresponder a un Maestro. La relación correspondiente entre Maestro y Esclavo se define especificando el mismo BrokerName y diferente BrokerId. BrokerId es 0 Indica maestro y un valor distinto de cero indica esclavo. Master también puede implementar múltiples. Cada Broker establece una conexión persistente con todos los nodos en el clúster de NameServer y registra periódicamente información del tema en todos los NameServers.
El Productor establece una conexión larga con uno de los nodos en el clúster del Servidor de Nombres (seleccionado al azar), recupera periódicamente información de enrutamiento del Tema del Servidor de Nombres, establece una conexión larga con el Maestro que proporciona servicios de Tema y envía latidos al Maestro regularmente. El productor no tiene ningún estado y se puede implementar en clústeres.
El consumidor establece una conexión a largo plazo con uno de los nodos en el clúster de NameServer (seleccionado al azar), periódicamente recupera información de enrutamiento de temas de NameServer, establece conexiones a largo plazo con Master y Slave que brindan servicios de temas y envía latidos a Master y Esclavo regularmente. Los consumidores pueden suscribirse a mensajes del Maestro o del Esclavo, y las reglas de suscripción están determinadas por la configuración del Broker.

6. El modo del clúster RoctetMQ

1) Modo maestro único

Este método es arriesgado: una vez que el Broker se reinicia o deja de funcionar, todo el servicio no estará disponible. No se recomienda su uso en un entorno en línea, pero puede usarse para pruebas locales.

2) Modo multimaestro

Un clúster no tiene esclavos y son todos maestros, como 2 maestros o 3 maestros. Las ventajas y desventajas de este modo son las siguientes:

Ventajas: la configuración simple, el tiempo de inactividad del maestro único o el mantenimiento de reinicio no tienen ningún impacto en la aplicación; cuando el disco está configurado como RAID10, incluso si el tiempo de inactividad de la máquina es irrecuperable, debido a que el disco RAID10 es muy confiable, el mensaje no se perderá (un (se pierde una pequeña cantidad de mensajes de cepillado asincrónico, deslizando el disco sincrónicamente sin perder un mensaje), con el mayor rendimiento;
Desventaja: cuando una sola máquina está inactiva, los mensajes no consumidos en esta máquina no se pueden suscribir hasta que la máquina se recupere, y el mensaje real El rendimiento temporal de los mensajes se verá afectado.
3) Modo multimaestro y multiesclavo (asíncrono)

Cada Maestro configura un Esclavo, y hay múltiples pares de Maestro-Esclavo. HA adopta el modo de replicación asíncrona, y el maestro y el respaldo tienen un retraso de mensaje corto (nivel de milisegundos). Las ventajas y desventajas de este modo son las siguientes:

Ventajas: incluso si el disco está dañado, la pérdida de mensajes es muy pequeña y el rendimiento en tiempo real del mensaje no se verá afectado. Al mismo tiempo, después de que el Maestro esté inactivo, el consumidor aún puede consumir desde el Esclavo. y este proceso es transparente para la aplicación, no se requiere intervención manual y el rendimiento es el mismo El modo Maestro es casi el mismo;
Desventajas: El Maestro está inactivo y se perderá una pequeña cantidad de mensajes en el caso del disco daño.
4) Modo Multi-Master y Multi-Slave (sincronización)

Cada maestro está configurado con un esclavo y hay varios pares de maestro-esclavo. HA adopta un método de doble escritura sincrónica, es decir, solo cuando tanto el maestro como la copia de seguridad se escriben correctamente, el éxito se puede devolver a la aplicación. Las ventajas y desventajas de esta modalidad son las siguientes:

Ventajas: no existe un punto único de falla tanto para los datos como para los servicios. Cuando el maestro está inactivo, no hay demoras en los mensajes y la disponibilidad del servicio y de los datos es muy alta. Desventajas: el rendimiento es ligeramente menor que la replicación
asincrónica modo (aproximadamente un 10% más bajo) y se envía un solo mensaje. El RT será ligeramente más alto y, en la versión actual, después de que el nodo maestro cae, la máquina en espera no puede cambiar automáticamente al maestro.

7. Mensajes secuenciales de RoctetMQ, ¿cómo asegurar la secuencia?

La secuencia de mensajes enviados desde el productor al corredor es FIFO, por lo que el envío es secuencial y los mensajes en una única cola son secuenciales. El consumo simultáneo de varias colas no puede garantizar absolutamente el orden de los mensajes. Por lo tanto, para el mismo tema y la misma cola, un hilo envía un mensaje cuando envía un mensaje y un hilo consume un mensaje en una cola cuando lo consume. RocketMQ nos proporciona la interfaz MessageQueueSelector, que puede reescribir la interfaz interna e implementar su propio algoritmo, como juzgar i% 2 == 0 y luego enviar el mensaje a la cola1 o enviarlo a la cola2.

8. ¿Cómo implementar el filtrado de mensajes ?

Hay dos soluciones. Una es filtrar en el lado del corredor de acuerdo con la lógica de deduplicación del consumidor. La ventaja de esto es evitar la transmisión de mensajes inútiles al lado del consumidor. La desventaja es que aumenta la carga para el corredor. y es relativamente complicado de implementar. El otro es filtrar en el lado del consumidor, como la deduplicación según la etiqueta establecida en el mensaje. La ventaja de esto es que es simple de implementar, pero la desventaja es que llega una gran cantidad de mensajes inútiles al lado del consumidor
. y sólo se puede descartar sin procesar.

9. Deduplicación de mensajes: si se entregan varios mensajes duplicados al consumidor debido a la red y otras razones, ¿cómo se deduplican los mensajes?

Primero hablemos del principio de idempotencia del mensaje: es decir, el resultado de múltiples solicitudes iniciadas por el usuario para la misma operación es el mismo y no se producirán resultados diferentes debido a múltiples operaciones. Mientras se mantenga la idempotencia, no importa cuántos mensajes lleguen, el resultado final del procesamiento será el mismo y debe ser implementado por el consumidor. Solución de deduplicación: debido a que cada mensaje tiene un MessageId, se garantiza que cada mensaje tendrá una clave única, que puede ser la clave principal o la restricción única de la base de datos, o la clave en el caché de Redis. Antes de consumir un mensaje, verifique si es único. La clave existe en la base de datos o caché, si existe, el mensaje ya no se procesará. Si el consumo es exitoso, es necesario asegurarse de que la clave única se inserte en la tabla de deduplicación.

10. ¿Cómo implementa RocketMQ mensajes de transacciones distribuidas?

La figura anterior es el proceso de implementación de mensajes de transacciones distribuidas, que se basa en un mecanismo de medio mensaje, confirmación secundaria y revisión de mensajes.

1. El Productor envía un medio mensaje al corredor.
2. El Productor recibe una respuesta y el mensaje se envía con éxito. En este momento, el mensaje es un medio mensaje, marcado como "no entregable" y el Consumidor no puede consumirlo. .
3. El Productor ejecuta transacciones locales.
4. En circunstancias normales, cuando se completa la ejecución de la transacción local, el Productor envía un Commit / Rollback al Broker. Si es un Commit, el Broker marcará el medio mensaje como un mensaje normal y el Consumidor podrá consumirlo. Si se trata de un Rollback, el Broker descarta este mensaje.
5. En circunstancias anormales, el lado del corredor no ha podido esperar la segunda confirmación. Después de un cierto período de tiempo, se consultarán todos los semimensajes y luego el estado de ejecución de los semimensajes se consultará en el lado del Productor.
6. El lado del productor consulta el estado de la transacción local
7. Envía el compromiso/reversión al lado del corredor de acuerdo con el estado de la transacción. (5, 6, 7 son revisión de mensajes)

11. ¿Qué es un medio mensaje en los mensajes distribuidos?

Semimensaje: se refiere al mensaje que el consumidor no puede consumir por el momento. El mensaje que el productor envía con éxito al corredor final, pero este mensaje está marcado como estado "temporalmente no entregable", solo después de la segunda confirmación. Después de que el productor ejecuta la transacción local, el consumidor puede consumir este mensaje.

12. Disponibilidad de mensajes, ¿cómo puede RocketMQ garantizar la disponibilidad/confiabilidad de los mensajes? (Otra forma de hacer esta pregunta: cómo asegurar que los mensajes no se pierdan)

Respuesta desde tres vertientes: Productor, Consumidor y Corredor.

Desde la perspectiva del Productor, ¿cómo garantizar que el mensaje se envíe correctamente al Broker?

1. Se puede utilizar el envío sincrónico , es decir, enviar un dato y esperar a que el receptor devuelva una respuesta antes de enviar el siguiente paquete de datos. Si se devuelve la respuesta OK, significa que el mensaje se envió correctamente al intermediario y el estado de tiempo de espera o falla activará un segundo reintento.
2. Se puede adoptar el método de entrega de mensajes de transacciones distribuidas .
3. Si un mensaje caduca después de ser enviado, también puede verificar si se almacenó correctamente en el Broker consultando la API de registro.

En general, Producer todavía utiliza el envío sincrónico para garantizarlo.

Desde la perspectiva de Broker, ¿cómo garantizar la persistencia del mensaje?

1. Siempre que el mensaje persista en CommitLog (archivo de registro), incluso si el Broker está inactivo, el mensaje no consumido se puede recuperar y consumir nuevamente.

2. Mecanismo de vaciado de disco del corredor: vaciado de disco sincrónico y vaciado de disco asíncrono . No importa qué tipo de vaciado de disco pueda garantizar que el mensaje se almacenará en el caché de página (en la memoria), pero el vaciado de disco sincrónico es más confiable, son los datos. esperando a que el Productor envíe el mensaje Después de persistir en el disco, la respuesta se devuelve al Productor.

3. El corredor admite el modo de replicación asíncrona multi- maestro , multi-esclavo y doble escritura síncrona multi-maestro . Los mensajes se envían al host maestro, pero el consumo se puede consumir desde el maestro o desde el esclavo. El modo de doble escritura síncrono puede garantizar que incluso si el Maestro deja de funcionar, se debe hacer una copia de seguridad del mensaje en el Esclavo, asegurando que el mensaje no se pierda.

Desde la perspectiva del consumidor, ¿cómo garantizar que los mensajes se consuman correctamente?

El propio consumidor mantiene un desplazamiento persistente (correspondiente al desplazamiento mínimo en la cola de mensajes), que se utiliza para marcar el subíndice del mensaje que se ha consumido con éxito y se ha devuelto con éxito al corredor. Si el consumidor no consume, devolverá el estado de falla de consumo al corredor y actualizará su propia compensación si la respuesta es exitosa. Si el corredor cuelga al enviar de vuelta al corredor, el consumidor lo volverá a intentar periódicamente. Si el consumidor y el corredor cuelgan juntos, el mensaje aún se almacena en el lado del corredor y la compensación en el lado del consumidor también es persistente. Al reiniciar, continúe realizando el desplazamiento antes de que se consuman los mensajes.

13. ¿Cuál es el mecanismo de flasheo de RocketMQ?

RocketMQ proporciona dos estrategias de descarga: descarga sincrónica y descarga asincrónica

Disco de cepillo síncrono

Una vez que el mensaje llega a la memoria del Broker, se debe vaciar en el archivo de registro commitLog para que se considere exitoso y luego devolver al Productor que los datos se enviaron exitosamente.

Cepillado asincrónico

El vaciado asincrónico significa que una vez que el mensaje llega a la memoria del Broker, le devolverá al Productor que los datos se enviaron correctamente y se despertará un subproceso para conservar los datos en el archivo de registro CommitLog.

Análisis de ventajas y desventajas.

El vaciado sincrónico garantiza que los mensajes no se perderán, pero el tiempo de respuesta es aproximadamente un 10% más largo que el vaciado asincrónico, lo cual es adecuado para escenarios que requieren una alta confiabilidad de los mensajes. El rendimiento del cepillado de disco asíncrono es relativamente alto y el RT es pequeño, pero si el intermediario se apaga, algunos datos de la memoria se perderán, lo que es adecuado para escenarios con requisitos de rendimiento relativamente altos.

14. ¿Cómo logra RocketMQ el equilibrio de carga?

1. Equilibrio de carga del productor

En el lado del Productor, cuando cada instancia envía un mensaje, sondeará todas las colas de mensajes de forma predeterminada para enviar mensajes, de modo que los mensajes caigan en colas diferentes en promedio. Y debido a que la cola puede estar dispersa en diferentes intermediarios, el mensaje se envía a diferentes intermediarios, como se muestra en la siguiente figura:

Las etiquetas en las líneas de flecha en la figura representan la secuencia: el editor enviará el primer mensaje a la cola 0, luego el segundo mensaje a la cola 1, y así sucesivamente.

2. Equilibrio de carga del consumidor

1 ) modo de clúster

En el modo de consumo de clúster, cada mensaje solo debe entregarse a una instancia del grupo de consumidores que se suscribe a este tema. RocketMQ utiliza la extracción activa para extraer y consumir mensajes. Al extraer, es necesario especificar qué cola de mensajes extraer.

Siempre que cambie el número de instancias, se activará un equilibrio de carga de todas las instancias. En este momento, las colas se asignarán uniformemente a cada instancia de acuerdo con el número de colas y el número de instancias.

El algoritmo de asignación predeterminado es AllocateMessageQueueAveragely, como se muestra a continuación:

Existe otro algoritmo promedio, AllocateMessageQueueAveragelyByCircle, que también asigna cada cola por igual, pero divide las colas de forma circular, como se muestra en la siguiente figura:

Cabe señalar que en el modo de clúster, a la cola solo se le permite asignar una sola instancia, esto se debe a que si varias instancias consumen mensajes de una cola al mismo tiempo, el consumidor controla activamente qué mensajes extraer, lo que El resultado es el mismo mensaje, que se consume varias veces en diferentes instancias, por lo que el algoritmo es que una cola solo se asigna a una instancia de consumidor y una instancia de consumidor se puede asignar a diferentes colas al mismo tiempo.

Al agregar instancias de consumidores para compartir el consumo de la cola, puede desempeñar un papel en la expansión horizontal de la capacidad de consumo. Cuando una instancia se desconecta, se activará nuevamente el equilibrio de carga. En este momento, la cola asignada originalmente se asignará a otras instancias para continuar con el consumo.

Sin embargo, si la cantidad de instancias de consumidor es mayor que la cantidad total de colas de mensajes, las instancias de consumidor adicionales no se asignarán a las colas, los mensajes no se consumirán y no podrán compartir la carga. Por lo tanto, es necesario controlar que el número total de colas sea mayor o igual al número de consumidores.

2 ) modo de transmisión

Dado que el modo de transmisión requiere que se entregue un mensaje a todas las instancias de consumidores de un grupo de consumidores, no se puede decir que el mensaje esté asignado para consumo.

En términos de implementación, una de las diferencias es que cuando los consumidores asignan colas, todos los consumidores se asignan a todas las colas.

15. ¿Qué es letra muerta?

Cuando un mensaje no se puede consumir por primera vez, la cola de mensajes RocketMQ reintentará automáticamente el mensaje; después de alcanzar el número máximo de reintentos, si el consumo aún falla, indica que el consumidor no puede consumir el mensaje correctamente en circunstancias normales. En este momento, la cola de mensajes RocketMQ El mensaje no se descartará inmediatamente, sino que se enviará a la cola especial correspondiente al consumidor.

En la cola de mensajes RocketMQ, los mensajes que no se pueden consumir en circunstancias normales se denominan mensajes de mensajes no entregados, y las colas especiales que almacenan mensajes de mensajes no entregados se denominan colas de mensajes no entregados.

1. Función de letra muerta

Los mensajes de letra muerta tienen las siguientes propiedades:

Los consumidores ya no lo consumirán normalmente.

El período de validez es el mismo que el de los mensajes normales, ambos son de 3 días y se eliminarán automáticamente después de 3 días. Por lo tanto, solucione el mensaje de letra muerta a tiempo dentro de los 3 días posteriores a su generación.

Una cola de mensajes fallidos tiene las siguientes características :

Una cola de mensajes fallidos corresponde a un ID de grupo, no a una única instancia de consumidor.

Si un ID de grupo no genera un mensaje de mensajes no entregados, la cola de mensajes RocketMQ no creará una cola de mensajes no entregados correspondiente para él.

Una cola de mensajes no entregados contiene todos los mensajes de mensajes no entregados generados por el ID de grupo correspondiente, sin importar a qué tema pertenezca el mensaje.

2. Ver información de mensajes fallidos

Consultar la información del tema de la cola de mensajes no entregados en la consola.

Consultar mensajes fallidos según el asunto en la interfaz de mensajes

Elige reenviar mensaje

Un mensaje ingresa a la cola de mensajes no entregados, lo que significa que algunos factores impiden que los consumidores consuman el mensaje normalmente, por lo que generalmente es necesario manejarlo de manera especial. Después de solucionar los factores sospechosos y resolver el problema, puede reenviar el mensaje en la consola RocketMQ de la cola de mensajes para que los consumidores puedan consumirlo nuevamente.

16. ¿Qué es la idempotencia del mensaje?

Después de que el consumidor de RocketMQ en la cola de mensajes recibe el mensaje, es necesario realizar un procesamiento idempotente en el mensaje de acuerdo con la clave única en el negocio.

1. La necesidad de la idempotencia del mensaje

En aplicaciones de Internet, especialmente cuando la red es inestable, los mensajes de la cola de mensajes RocketMQ pueden repetirse, esta repetición se puede resumir de la siguiente manera:

A. El mensaje se repite al enviar

Cuando un mensaje se envía con éxito al servidor y persiste, se produce una desconexión repentina de la red o el cliente falla, lo que hace que el servidor no responda al cliente. Si el productor se da cuenta de que el mensaje no se pudo enviar e intenta enviarlo nuevamente, el consumidor recibirá dos mensajes con el mismo contenido y el mismo ID de mensaje.

B. El mensaje se repite durante la entrega.

En el escenario de consumo de mensajes, el mensaje se entregó al consumidor y se completó el procesamiento comercial. Cuando el cliente responde al servidor, la red se desconecta. Para garantizar que el mensaje se consuma al menos una vez, el servidor RocketMQ de la cola de mensajes intentará entregar el mensaje previamente procesado nuevamente después de que se restablezca la red, y el consumidor recibirá posteriormente dos mensajes con el mismo contenido y el mismo ID de mensaje. .

C. Duplicación de mensajes durante el equilibrio de carga (incluidos, entre otros, fluctuaciones de la red, reinicio del corredor y reinicio de la aplicación del suscriptor)

Cuando el corredor o cliente de la cola de mensajes RocketMQ se reinicia, se expande o se reduce, se activará el reequilibrio y los consumidores pueden recibir mensajes duplicados en este momento.

2. Método de procesamiento

Debido a que el ID del mensaje puede entrar en conflicto (duplicarse), no se recomienda utilizar el ID del mensaje como base para un procesamiento idempotente verdaderamente seguro. La mejor manera es utilizar el identificador único de la empresa como base clave para el procesamiento idempotente, y el identificador único de la empresa se puede configurar mediante la clave del mensaje:

Mensaje mensaje = nuevo mensaje();

mensaje.setKey("ORDERID_100");

EnviarResultado enviarResultado = productor.enviar(mensaje);

Cuando el suscriptor recibe el mensaje, puede realizar un procesamiento idempotente según la clave del mensaje:

consumidor.subscribe("ons_test", "*", nuevo MessageListener() {

Acción pública consumir (mensaje mensaje, contexto ConsumeContext) {

Clave de cadena = mensaje.getKey()

// Realizar procesamiento idempotente según la clave identificada de forma única por la empresa

}

});

17. ¿Qué es el modo de mensaje push-pull?

PULL : Un consumidor de tipo pull extrae activamente el consumo de mensajes del corredor. Siempre que se extraiga el mensaje, se iniciará el proceso de consumo, que se denomina consumo activo.

PUSH : Un consumidor push es un oyente que necesita registrar mensajes, y el usuario debe implementar el oyente. Cuando el mensaje llega al servidor del intermediario, hará que el oyente extraiga el mensaje y luego iniciará el proceso de consumo. Pero, de hecho, todavía extrae mensajes del corredor, lo que se denomina consumo pasivo.

18. ¿Qué debo hacer si algún Broker cae repentinamente?

Arquitectura de broker maestro-esclavo y estrategia de múltiples copias. Después de que el Maestro reciba el mensaje, lo enviará al Esclavo sincrónicamente, de modo que habrá más de una copia de un mensaje. Si el Maestro está inactivo, los mensajes en el esclavo estarán disponibles, lo que garantiza la confiabilidad y alta disponibilidad de MQ. Además, Rocket MQ4.5.0 ha sido compatible con el modo Dlegder ya que se basó en balsa y logró HA real.

19. ¿En qué NameServer registra el Broker su propia información?

Esta pregunta obviamente te está engañando, porque Broker registrará su propia información en todos los NameServers, no solo en uno, ¡sino en todos y cada uno de ellos!

20. ¿Se eliminarán los mensajes en RocketMQ Broker inmediatamente después de ser consumidos?

No, cada mensaje persistirá en el CommitLog. Después de que cada Consumidor se conecte al Broker, mantendrá la información del progreso del consumo. Cuando se consume un mensaje, solo se conservará el progreso del consumo del Consumidor actual (el desplazamiento del CommitLog). estar actualizado.

21. ¿Cuál es el mecanismo de almacenamiento y envío de mensajes?

Almacenamiento de mensajes : RocketMQ utiliza archivos para almacenar mensajes, y las operaciones del disco deben usarse correctamente y su velocidad puede coincidir con la velocidad de transmisión de carga en la red. En el disco de alto rendimiento actual, la velocidad de escritura secuencial puede alcanzar los 600 MB/s, superando la velocidad de transmisión de la tarjeta de red general. Sin embargo, la velocidad de escritura aleatoria del disco es de solo unos 100 KB/s, ¡lo que es 6000 veces diferente del rendimiento de escritura secuencial! Debido a que existe una diferencia de velocidad tan grande, un buen sistema de cola de mensajes será mucho más rápido que un sistema de cola de mensajes normal. Los mensajes de RocketMQ se escriben secuencialmente , lo que garantiza la velocidad de almacenamiento de mensajes .

Envío de mensajes : el proceso de enviar un mensaje de archivo al receptor. El proceso correspondiente es el siguiente. El sistema operativo Linux se divide en [modo de usuario] y [modo kernel]. Las operaciones de archivos y las operaciones de red deben implicar el cambio entre estos dos modos, y el procesamiento de datos es una copia inevitable. Un servidor envía el contenido del archivo del disco local al cliente, generalmente dividido en dos pasos:

1) leer; leer el contenido del archivo local;

2) escribir; enviar el contenido leído a través de la red.

Estas dos operaciones aparentemente simples en realidad realizaron 4 replicaciones de datos, a saber:

Copie datos del disco a la memoria en modo kernel;

Copiar de la memoria en modo kernel a la memoria en modo usuario;

Luego copie desde la memoria en modo usuario a la memoria en modo kernel del controlador de red;

Finalmente, se copia desde la memoria en modo kernel del controlador de red a la tarjeta de red para su transmisión.

El uso del método mmap puede guardar la copia de la memoria en el modo de usuario y mejorar la velocidad. Este mecanismo se implementa en Java a través de MappedByteBuffer.

RocketMQ aprovecha al máximo las funciones anteriores, la denominada tecnología de " copia cero " , para mejorar la velocidad de almacenamiento de mensajes y envío de red .

22. ¿Cuál es la estructura de almacenamiento de mensajes de RocketMQ?

El almacenamiento de mensajes RocketMQ se completa con la cooperación de ConsumeQueue y CommitLog. El archivo de almacenamiento físico real del mensaje es CommitLog. ConsumeQueue es la cola lógica del mensaje, similar al archivo de índice de la base de datos, que almacena la dirección que apunta a el almacenamiento físico. Cada cola de mensajes bajo cada tema tiene un archivo ConsumeQueue correspondiente.

CommitLog: almacena los metadatos del mensaje.

ConsumerQueue: almacena el índice del mensaje en CommitLog

IndexFile: proporciona un método para consultar mensajes por clave o intervalo de tiempo para la consulta de mensajes. Este método de búsqueda de mensajes a través de IndexFile no afecta el proceso principal de envío y consumo de mensajes.