Código fuente de RocketMQ: replicación síncrona maestro-esclavo y replicación asíncrona
2 Introducción a clases relacionadas
3 Principios de replicación sincrónica
4 Principios de replicación asincrónica
5 Precauciones
Para proporcionar confiabilidad del sistema, RocketMQ adopta un mecanismo de replicación maestro-esclavo. Cada Broker maestro se puede configurar con múltiples Brokers esclavos. El intermediario maestro recibe mensajes del productor y luego los replica de forma sincrónica o asincrónica a los intermediarios esclavos para lograr alta disponibilidad.
La replicación sincrónica garantiza la máxima confiabilidad del mensaje, pero cada vez que escribe un mensaje, debe esperar a que el mensaje se sincronice con al menos un Broker esclavo, lo que afecta el rendimiento del sistema. La replicación asincrónica es lo opuesto a la replicación sincrónica. En la replicación asincrónica, independientemente de si el mensaje se ha copiado al Broker esclavo, el Broker maestro regresará inmediatamente después de escribir el mensaje, por lo que el rendimiento será ligeramente mayor, pero si el Broker maestro. copia el mensaje al Broker esclavo. Si ocurre una falla antes, es posible perder información que no se copia al Broker esclavo a tiempo.
En este artículo, presentaremos brevemente la implementación de la sincronización maestro-esclavo de RocketMQ.
Es la clase de implementación principal del servicio de replicación maestro-esclavo. Utiliza componentes internos para aceptar solicitudes de conexión del Broker esclavo y registrar el progreso de replicación informado por el Broker esclavo.
Es el principal responsable de aceptar solicitudes de conexión del proxy y crear una nueva instancia de objeto HAConnection después de aceptar cada conexión del proxy.
El Broker maestro administra una serie de conexiones de Broker esclavo e internamente contiene una instancia de objeto ReadSocketService y una instancia de objeto WriteSocketService. La primera es responsable de recibir el progreso de replicación actual del Broker esclavo, y el segundo es responsable de recibir el progreso de replicación actual del Broker esclavo. responsable de enviar mensajes al Broker esclavo cuando el canal se puede escribir. Enviar datos replicados desde el Broker. Cuando se puede escribir en el canal, envía datos al Broker esclavo para completar la replicación maestro-esclavo.
La clase de implementación ServiceThread (si proviene de un Broker) intentará establecer una conexión con el Broker principal e informará periódicamente su progreso de replicación al Broker principal, y luego escuchará el evento OP_READ (consulte la artículo del autor sobre cómo comprender el evento NIO SelectionKey) y manejar la solicitud de conexión del Broker principal a través de HAConnection.WriteSocketService.
HAConnection.WriteSocketService maneja los datos de replicación enviados por el Broker principal a través de HAConnection.WriteSocketService.
Si la clase de implementación de replicación síncrona maestro-esclavo es replicación síncrona maestro-esclavo, se enviará una solicitud de tarea de replicación a esta clase y entrará en el estado de espera de bloqueo. Esta tarea encapsula principalmente el progreso de escritura del mensaje. El Broker principal actual y GroupTransferService también. Un ServiceThread obtendrá periódicamente los mensajes recibidos por HAConnection.ReadSocketService de HAConnection.ReadSocketService. ReadSocketService recibe el progreso de replicación máximo del Broker y luego compara las solicitudes de todas las tareas de replicación. Si el progreso de replicación máximo del Broker ya es mayor que la solicitud dentro del progreso de la solicitud, activa el bloqueo de replicación sincrónica. El despertar se implementa a través de CountDownLatch.
BrokerController almacena mensajes a través de DefaultMessageStore.putMessage, que completa el almacenamiento de mensajes real llamando a CommitLog.putMessage para escribir el mensaje en el búfer de memoria. Después de escribir el mensaje en el búfer de memoria, CommitLog.putMessage llama a handleDiskFlush para vaciar el disco sincrónico o asincrónico, y luego llama a handleHA para la replicación maestro-esclavo.
La definición del método handlerHA es la siguiente:
GroupTransferService acepta la tarea de solicitud de copia en espera, luego verifica el progreso máximo de copia del Broker en el método en ejecución y activa el tarea en espera cuyo progreso ha alcanzado el progreso máximo de copia.
De hecho, el principio de la replicación asincrónica es relativamente simple. Si el Broker está configurado para la replicación asincrónica, después de escribir el mensaje en CommitLog.putMessage, llamar al método handleHA no realizará ninguna operación. , no hay necesidad de preocuparse por el mensaje del Broker. El servicio HAConnection.WriteSocketService en segundo plano monitorea completamente el progreso de la copia. El servicio WriteSocketService escucha las conexiones de escritura del Broker y escribe los datos que se copiarán en él. ReadSocketService es responsable de procesar este informe, y el progreso de replicación máximo informado por el Broker se utiliza para la replicación sincrónica como se describe en la Sección 3, bloqueando los subprocesos que esperan tareas de replicación.
La comunicación entre Broker y Namesrv, Producer y Namesrv, Consumer y Namesrv, Producer y Consumer y Broker en los componentes RocketMQ se implementa en base a Netty, pero la implementación de replicación maestro-esclavo descrita en este artículo es Basado en Java local.