Principio y selección de la cola de mensajes
Message Queue (Message Queue) es un método de comunicación entre procesos o comunicación entre diferentes subprocesos de un mismo proceso.
Broker (servidor de mensajes)
El concepto de Broker proviene de Apache ActiveMQ. En términos sencillos, es un servidor MQ.
Productor
El iniciador del negocio, responsable de transmitir los mensajes de producción al corredor
Consumidor
Negocio El procesador es responsable de obtener mensajes del corredor y realizar procesamiento de lógica de negocios
Tema (tema)
Un lugar de reunión unificado para mensajes en el modo de publicación-suscripción. Diferentes productores envían mensajes al tema. por el servidor MQ a diferentes suscriptores para implementar la transmisión de mensajes
Cola (cola)
En el modo PTP, un productor específico envía un mensaje a una cola específica y el consumidor se suscribe a una específico La cola completa la recepción del mensaje especificado.
Mensaje (cuerpo del mensaje)
Paquetes de datos codificados según formatos fijos definidos por diferentes protocolos de comunicación para encapsular datos comerciales y realizar la transmisión de mensajes
Punto a point Modelo para comunicación punto a punto entre productores y consumidores de mensajes.
El modelo peer-to-peer consta de tres roles:
Cada mensaje se envía a una cola específica y el receptor recibe el mensaje de la cola. Las colas retienen mensajes, ya sea en la memoria o persistentes, hasta que se consumen o se agotan.
Características:
El modelo de publicación-suscripción contiene tres roles:
Varios editores envían mensajes al tema y el sistema entrega estos mensajes a varias suscripciones.
Características:
AMQP, Protocolo avanzado de cola de mensajes, es un estándar abierto para protocolos de capa de aplicación y está diseñado para middleware orientado a mensajes. El middleware de mensajes se utiliza principalmente para el desacoplamiento entre componentes. El remitente del mensaje no necesita conocer la existencia del consumidor del mensaje y viceversa. Las características principales de AMQP son la orientación a mensajes, las colas, el enrutamiento (incluido punto a punto y publicación/suscripción), confiabilidad y seguridad.
Ventajas: fiable y versátil
MQTT (Message Queuing Telemetry Transport) es un protocolo de mensajería instantánea desarrollado por IBM y puede convertirse en una parte importante del Internet de las cosas. El protocolo es compatible con todas las plataformas y puede conectar casi todos los elementos conectados a Internet con el mundo exterior. Se utiliza como protocolo de comunicación para sensores y actuadores (como conectar casas a Internet a través de Twitter).
Ventajas: formato simple, pequeña ocupación de ancho de banda, comunicación móvil, PUSH, sistema integrado
STOMP (Protocolo de mensajes orientados a texto en streaming) es un protocolo de mensajes de texto en streaming orientado a un protocolo de texto simple. diseñado para MOM (Message Oriented Middleware, middleware orientado a mensajes). STOMP proporciona un formato de conexión interoperable que permite a los clientes interactuar con cualquier intermediario de mensajes STOMP (Broker).
Ventajas: modo comando (no modo tema\cola)
XMPP (Protocolo de presencia y mensajería extensible) se basa en el protocolo de lenguaje de marcado extensible (XML), utilizado principalmente para mensajería instantánea ( IM) y detección de campo en línea. Adecuado para operaciones casi en tiempo real entre servidores. En esencia, basado en la transmisión XML, este protocolo puede eventualmente permitir a los usuarios de Internet enviar mensajes instantáneos a cualquier otra persona en Internet, incluso si sus sistemas operativos y navegadores son diferentes.
Ventajas: apertura universal, gran compatibilidad, escalabilidad y alta seguridad, pero el formato de codificación XML ocupa mucho ancho de banda
RabbitMQ es un middleware de mensajes que implementa AMQP (Advanced Message Protocolo de cola) Es un tipo de software que se originó originalmente en los sistemas financieros y se utiliza para almacenar y reenviar mensajes en sistemas distribuidos. Tiene un buen rendimiento en términos de facilidad de uso, escalabilidad y alta disponibilidad. RabbitMQ se implementa principalmente para lograr un desacoplamiento bidireccional entre sistemas. Cuando el productor genera una gran cantidad de datos y el consumidor no puede consumirlos rápidamente, se necesita una capa intermedia. Guarde estos datos.
RabbitMQ es una implementación AMQP de código abierto. El servidor está escrito en lenguaje Erlang y admite una variedad de clientes, como: Python, Ruby, .NET, Java, JMS, C, PHP, ActionScript, XMPP. , STOMP Espera, admite AJAX. Se utiliza para almacenar y reenviar mensajes en sistemas distribuidos y tiene un buen rendimiento en términos de facilidad de uso, escalabilidad y alta disponibilidad.
Canal
Un canal es una conexión de comunicación unidireccional punto a punto entre dos administradores. Si se requiere comunicación bidireccional, se pueden establecer un par de canales.
Exchange (conmutador de mensajes)
Exchange es similar a un conmutador en una red de comunicación de datos y proporciona estrategias de enrutamiento de mensajes.
En RabbitMq, el productor no envía el mensaje directamente a la cola a través del canal, sino que primero lo envía a Exchange. Un Exchange puede estar vinculado a varias colas. Cuando el productor entrega un mensaje, pasará una ROUTING_KEY. Exchange enrutará el mensaje a la cola especificada según esta ROUTING_KEY de acuerdo con un algoritmo de enrutamiento específico. Al igual que las colas, Exchange también se puede configurar para que sea persistente, temporal o se elimine automáticamente.
Hay 4 tipos de Exchange: directo (predeterminado), fanout, tema y encabezados.
Los diferentes tipos de Exchange tienen diferentes estrategias para reenviar mensajes:
Enlace
El llamado enlace consiste en combinar un Exchange específico con una cola específica. atado. El vínculo entre Exchange y Queue puede ser una relación de muchos a muchos.
Clave de enrutamiento (clave de enrutamiento)
Exchange entrega mensajes basados en esta clave.
vhost (host virtual)
Se pueden crear múltiples intermediarios de mensajes virtuales en el servidor RabbitMq, también llamados hosts virtuales (vhosts). Cada vhost es esencialmente un servidor mini-rabbitmq, que gestiona su propio intercambio y enlaces respectivamente.
Vhost es equivalente a un servidor físico, que puede proporcionar aislamiento de límites para diferentes aplicaciones, de modo que las aplicaciones puedan ejecutarse de forma segura en diferentes instancias de vhost sin interferir entre sí. Los productores y consumidores deben especificar un vhost para conectarse al servidor Rabbit.
Supongamos que P1 y C1 han registrado el mismo Broker, Exchange y Cola. El mensaje enviado por P1 eventualmente será consumido por C1.
El proceso de comunicación básico es aproximadamente el siguiente:
Cuando el consumidor recibe el mensaje, debe enviar explícitamente el mensaje básico al corredor de conejo. Establezca el parámetro auto_ack en verdadero cuando el mensaje de confirmación o el consumidor se suscriba al mensaje.
Durante el proceso de comunicación, la cola procesa ACK en las siguientes situaciones:
Ese es el mecanismo de confirmación de reconocimiento del mensaje. Para garantizar que el mensaje no se pierda, el. La cola de mensajes proporciona el mecanismo de reconocimiento de mensajes, es decir, el mecanismo ACK. Cuando el consumidor confirma que el mensaje se ha consumido y procesado, envía un ACK a la cola de mensajes. En este momento, la cola de mensajes puede eliminar el mensaje. Si el Consumidor está inactivo/cerrado y no se envía ningún ACK, la cola de mensajes considerará que el mensaje no ha sido procesado y lo reenviará a otros Consumidores para que lo vuelvan a consumir y procesar.
El procesamiento de envío y recepción de mensajes admite transacciones. Por ejemplo: en un escenario de centro de tareas, un procesamiento puede implicar la recepción y el procesamiento de múltiples mensajes, que deben estar dentro del mismo alcance de transacción. el procesamiento falla, la transacción se revierte y el mensaje se vuelve a colocar en la cola.
La persistencia de mensajes es muy importante para algunas empresas principales clave. Una vez habilitada la persistencia de mensajes, después de cerrar y reiniciar la cola de mensajes, el mensaje se puede restaurar desde el almacenamiento persistente sin perderlo. seguir consumiendo y procesando.
modo fanout
Características del modo:
modo directo
Cualquier mensaje enviado a Direct Exchange se reenviará a la cola especificada con la clave de enrutamiento.
Si un intercambio se declara como directo y se especifica la clave de enrutamiento en el enlace, entonces se deben especificar tanto el intercambio como la clave de enrutamiento al enviar un mensaje.
En resumen: el productor genera mensajes y los envía a Exchange. Exchange envía mensajes según el tipo de Exchange y la clave de enrutamiento en basic_publish. Consumidores: suscríbase a Exchange y envíe mensajes según el tipo de Exchange y la clave de enlace (. enrutamiento en enlaces), si la clave de enrutamiento del productor y del suscriptor es la misma, Exchange enrutará a esa cola.
modo de tema
Como se mencionó anteriormente, la regla de enrutamiento de Exchange de tipo directo coincide completamente con la clave de enlace y la clave de enrutamiento, pero este método de coincidencia estricto en muchos casos no puede satisfacer las necesidades comerciales reales.
El tipo de tema Exchange ha ampliado las reglas de coincidencia. Es similar al Exchange de tipo directo. También enruta mensajes a la cola que coincide con la clave de enlace y la clave de enrutamiento, pero las reglas de coincidencia aquí son algo diferentes.
Está de acuerdo:
Tomando la configuración de la figura anterior como ejemplo, los mensajes con routeKey="quick.orange.rabbit" se enrutarán a Q1 y Q2 al mismo tiempo. , los mensajes de enrutamientoKey="lazy.orange" .fox" se enrutarán al primer trimestre, los mensajes de routeKey="lazy.brown.fox" se enrutarán al segundo trimestre, los mensajes de routeKey="lazy.pink.rabbit" se enrutarán al segundo trimestre ( solo se entregará al segundo trimestre una vez, aunque esta clave de enrutamiento coincide con ambas claves vinculantes del segundo trimestre con enrutamientoKey="quick.brown.fox", enrutamientoKey="orange", enrutamientoKey="quick.orange.male.rabbit" se descartarán); porque no coinciden con ninguna clave vinculante.
RabbitMQ se implementa en tres modos: modo independiente, modo de clúster ordinario y modo de clúster espejo.
Modo de clúster ordinario
Se implementan varias máquinas. Cada máquina coloca una instancia de RabbitMQ, pero la cola creada solo se colocará en una instancia de RabbitMQ. Cada instancia sincroniza los elementos de la cola. . datos.
Si el consumidor está conectado a otra instancia, esa instancia extraerá datos de la instancia donde se encuentra la cola. Esto generará una sobrecarga al extraer datos. Si la instancia que contiene la cola deja de funcionar, otras instancias no podrán extraer datos de esa instancia. Incluso si la persistencia de mensajes está activada y se implementa Rabbitmq para almacenar mensajes, los mensajes sí lo harán. No necesariamente se perderá, pero debe esperar a que la instancia se recupere antes de poder continuar extrayendo datos de esta cola. No hay ninguna alta disponibilidad. Principalmente proporciona rendimiento y permite que varios nodos en el clúster sirvan la lectura. y escribir operaciones de una determinada cola.
Modo de clúster espejo
Los metadatos y mensajes de la cola se almacenarán en varias instancias y, cada vez que se escriba un mensaje, se sincronizará automáticamente con varias instancias de la cola. De esta manera, si alguna máquina falla, otras máquinas pueden tomar el control, pero la sobrecarga de rendimiento es demasiado alta y la sincronización de mensajes provoca una gran presión y consumo de ancho de banda de la red. Además, no hay escalabilidad. agregue máquinas y agregue otras nuevas. La máquina también contiene todos los datos de esta cola y no hay forma de expandir linealmente su cola. En este momento, debe habilitar el modo de clúster espejo y agregar una política en la consola de administración de Rabbitmq para sincronizar los datos con la cantidad especificada de nodos. Luego, cuando vuelva a crear la cola, aplique esta política y los datos se sincronizarán automáticamente. a otros nodos.
Kafka es un subproyecto de Apache. Es un sistema de cola de mensajes de publicación/suscripción distribuido en varios idiomas de alto rendimiento (no implementa estrictamente el modelo punto a punto de la especificación JMS, pero su efecto se puede lograr). En el desarrollo empresarial Tiene una amplia gama de aplicaciones. El alto rendimiento es su mayor ventaja y su desventaja es la confiabilidad de los mensajes (pérdida o duplicación). Esta desventaja es que a cambio de un alto rendimiento, los desarrolladores pueden reducir ligeramente el rendimiento a cambio de la confiabilidad de los mensajes.
Un tema se puede considerar como un tipo de mensaje. Cada tema se dividirá en varias particiones (áreas) y cada partición es un archivo de registro adjunto en el nivel de almacenamiento. Cualquier mensaje publicado en esta partición se agregará directamente al final del archivo de registro. La posición de cada mensaje en el archivo se llama desplazamiento y es un número largo que marca de forma única un mensaje. Sólo marca un mensaje. Kafka no proporciona otros mecanismos de indexación adicionales para almacenar compensaciones, porque en Kafka casi no se permite la "lectura y escritura aleatoria" de mensajes.
La diferencia entre la implementación de Kafka y JMS (Java Message Service) (activeMQ) es que incluso si el mensaje se consume, no se eliminará inmediatamente. El archivo de registro se conservará durante un cierto período de tiempo y luego se eliminará de acuerdo con los requisitos de configuración del intermediario. Por ejemplo, el archivo de registro se conservará durante 2 días y luego se borrará después de dos días, independientemente de si; los mensajes que contiene se consumen. Kafka utiliza este método simple para liberar espacio en disco y reducir los gastos de E/S del disco para cambiar el contenido del archivo después del consumo de mensajes.
Para el consumidor, necesita guardar el desplazamiento del mensaje consumido. El almacenamiento y el uso del desplazamiento son controlados por el consumidor cuando el consumidor consume el mensaje normalmente, el desplazamiento se controlará "linealmente" " adelante. Es decir, los mensajes se consumirán secuencialmente. De hecho, el consumidor puede consumir mensajes en cualquier orden, sólo necesita restablecer el desplazamiento a cualquier valor. (La compensación se guardará en zookeeper, ver más abajo)
El clúster de Kafka apenas necesita mantener información sobre el estado del consumidor y del productor. Esta información la guarda zookeeper, por lo tanto, la implementación del cliente de productor y consumidor es. Muy livianos, pueden salir a voluntad sin causar un impacto adicional en el clúster.
Las particiones están diseñadas para múltiples propósitos. La razón más fundamental es que Kafka se basa en el almacenamiento de archivos. Mediante la partición, el contenido del registro se puede distribuir en varios servidores para evitar que el tamaño del archivo alcance el límite superior de un solo disco de la máquina. Cada partición será guardada por el servidor actual (una instancia de Kafka se puede dividir en cualquier número de). particiones para ahorro de mensajes/eficiencia de consumo. Además, más particiones significa que se pueden acomodar más consumidores, lo que mejora efectivamente la capacidad de consumo simultáneo. (Consulte a continuación los principios específicos).
Varias particiones de un tema se distribuyen en varios servidores en el clúster de Kafka; cada servidor (instancia de Kafka) es responsable de leer y escribir mensajes en las particiones. Además, Kafka también puede configurar las particiones para las que se realizará una copia de seguridad; La cantidad de copias (réplicas), cada partición se respaldará en varias máquinas para mejorar la disponibilidad.
Según la solución replicada, significa que es necesario programar varias copias de seguridad; cada partición tiene un servidor como "líder"; el líder es responsable de todas las operaciones de lectura y escritura. habrá otros seguidores para tomar el control (convertirse en el nuevo líder); los seguidores simplemente siguen al líder de manera monótona y sincronizan mensajes. Se puede ver que el servidor como líder soporta toda la presión de solicitud. Por lo tanto, considerando el clúster general, el número de particiones significa cuántos "líderes" hay y Kafka distribuirá los "líderes" uniformemente en cada instancia para garantizar. rendimiento estable general.
Productores
El Productor publica el mensaje en el Tema especificado, y el Productor también puede decidir a qué partición pertenece el mensaje, por ejemplo, basándose en el método "round-robin"; o mediante otros Algunos algoritmos, etc.
Consumidores
Esencialmente, Kafka solo admite temas. Cada consumidor pertenece a un grupo de consumidores; por el contrario, puede haber varios consumidores en cada grupo. Los mensajes enviados a un Tema solo serán consumidos por un consumidor de cada grupo suscrito a este Tema.
Si todos los consumidores tienen el mismo grupo, esta situación es muy similar al modo de cola; los mensajes se equilibrarán entre la carga de los consumidores.
Si todos los consumidores tienen grupos diferentes, entonces esto es "publicar-suscribir"; el mensaje se transmitirá a todos los consumidores.
En Kafka, los mensajes en una partición solo serán consumidos por un consumidor en el grupo; el consumo de mensajes del consumidor en cada grupo es independiente entre sí; podemos considerar un grupo como un "suscriptor" y un "suscriptor". Tema Cada partición en solo será consumida por un consumidor en un "suscriptor", pero un consumidor puede consumir mensajes de múltiples particiones. Kafka solo puede garantizar que cuando un consumidor consume los mensajes en una partición, los mensajes sean secuenciales. De hecho, desde la perspectiva del Tema, los mensajes todavía no están en orden.
El principio de diseño de Kafka determina que para un tema, no más que la cantidad de particiones que los consumidores en el mismo grupo pueden consumir al mismo tiempo, de lo contrario significará que algunos consumidores no podrán obtener el mensaje.
Garantías
Kafka es más adecuado para escenarios con alto rendimiento y que permiten una pequeña pérdida de datos. Si debe garantizar una "transmisión de mensajes confiable", puede usar JMS.
Hay dos formas para que Kafka Producer envíe mensajes (parámetro de configuración productor.tipo):
¿Para modo sincrónico (producer.type=sync)? Hay tres métodos de confirmación para el envío de mensajes de Kafka Producer (confirmaciones de parámetros de configuración):
La intención del diseño original de Kafka es servir como una plataforma unificada de recopilación de información que pueda recopilar información de retroalimentación en tiempo real y debe ser capaz de admitir una mayor cantidad de datos y tiene buena tolerancia a fallos.
Persistencia
Kafka usa archivos para almacenar mensajes, lo que determina directamente que el rendimiento de Kafka depende en gran medida de las características del propio sistema de archivos.
E independientemente del sistema operativo, es casi imposible optimizar el sistema de archivos en sí. El almacenamiento en caché de archivos/mapeo de memoria directa, etc. son métodos comúnmente utilizados. Debido a que Kafka agrega archivos de registro, el costo de recuperación del disco es pequeño. Para reducir la cantidad de escrituras en el disco, el intermediario almacenará temporalmente los mensajes cuando la cantidad (o tamaño) de los mensajes alcance un cierto valor. umbral, tiempo y luego vaciarlo en el disco, reduciendo así la cantidad de llamadas de E/S del disco.
Rendimiento
Hay muchos puntos de rendimiento que deben considerarse además del disco IO, también debemos considerar el IO de la red, que está directamente relacionado con el rendimiento de Kafka. Kafka no proporciona muchas habilidades excelentes; para el lado del productor, los mensajes se pueden almacenar en un búfer y, cuando la cantidad de mensajes alcanza un cierto umbral, se envían al intermediario en lotes, lo mismo ocurre con el lado del consumidor, donde hay varios mensajes; se puede recuperar en lotes. Sin embargo, el tamaño del volumen del mensaje se puede especificar a través del archivo de configuración. Para el lado del corredor de Kafka, parece haber una llamada al sistema de envío de archivos que puede mejorar potencialmente el rendimiento de la E/S de la red: asigne los datos del archivo a la memoria del sistema y el socket puede leer directamente el área de memoria correspondiente sin la necesidad de que el proceso Copiar e intercambiar nuevamente. De hecho, para el productor/consumidor/corredor, el gasto de CPU no debería ser grande, por lo que habilitar el mecanismo de compresión de mensajes es una buena estrategia. La compresión requiere una pequeña cantidad de recursos de CPU, pero para Kafka, la IO de red debería ser más necesaria; . Cualquier mensaje transmitido a través de la red se puede comprimir. Kafka admite múltiples métodos de compresión como gzip/snappy.
Productor
Equilibrio de carga: el productor mantendrá conexiones de socket con todos los líderes de partición bajo el tema. Los mensajes se envían directamente desde el productor al corredor a través del socket sin pasar por ningún "; capa de enrutamiento" ". De hecho, el cliente productor decide a qué partición se enruta el mensaje. Por ejemplo, puede utilizar "aleatorio", "key-hash", "sondeo", etc. Si hay varias particiones en un tema, entonces es necesario implementar una "distribución equilibrada de mensajes" en el lado del productor.
La ubicación del líder de la partición (host: puerto) está registrada en zookeeper. Como cliente de zookeeper, el productor ha registrado una vigilancia para monitorear los eventos de cambio del líder de la partición.
Envío asincrónico: almacene temporalmente varios mensajes en el cliente y envíelos al corredor en lotes. Demasiadas E/S de datos pequeños ralentizarán el retraso general de la red, y el envío retrasado por lotes en realidad mejorará la eficiencia de la red. Sin embargo, esto también tiene ciertos peligros ocultos, por ejemplo, cuando el productor falla, los mensajes no enviados se perderán.
Consumidor
El lado del consumidor envía una solicitud de "búsqueda" al corredor y le informa del desplazamiento del mensaje; después de eso, el consumidor recibirá una cierta cantidad de mensajes; el lado del consumidor también puede repetir la solicitud. Establezca el desplazamiento para consumir el mensaje nuevamente.
En la implementación JMS, el modelo de tema se basa en el método push, es decir, el corredor envía el mensaje al consumidor.
Sin embargo, en Kafka, se adopta el método de extracción, es decir, después de que el consumidor establece una conexión con el corredor, toma la iniciativa de extraer (o recuperar) mensajes. Este modelo tiene algunas ventajas: primero, el consumidor puede recuperar mensajes; de manera oportuna de acuerdo con su propia capacidad de procesamiento de consumo y puede controlar el progreso (compensación) del consumo de mensajes, además, los consumidores pueden controlar la cantidad de mensajes consumidos y la recuperación por lotes.
En otras implementaciones JMS, la ubicación del consumo de mensajes la reserva el proveedor para evitar enviar mensajes repetidamente o reenviar mensajes que no se han consumido exitosamente, etc., y al mismo tiempo, el estado del El mensaje debe ser controlado. Esto requiere demasiado trabajo adicional por parte del intermediario JMS. En Kafka, solo un consumidor consume los mensajes en la partición, no hay control sobre el estado del mensaje y no existe un mecanismo complejo de confirmación de mensajes. Se puede ver que el corredor de Kafka es bastante liviano. Una vez que el consumidor recibe el mensaje, el consumidor puede guardar el desplazamiento del último mensaje localmente y registrar el desplazamiento con zookeeper de forma intermitente. Se puede ver que el cliente consumidor también es muy liviano.
Para implementaciones JMS, la garantía de entrega del mensaje es muy sencilla: exactamente una vez.
Es ligeramente diferente en Kafka:
como máximo una vez: el consumidor recupera el mensaje, luego guarda el desplazamiento y luego procesa el mensaje después de que el cliente guarda el desplazamiento, pero; durante el procesamiento del mensaje Se produjo una excepción que provocó que algunos mensajes no pudieran procesarse. Entonces los mensajes "no procesados" no se recuperarán en el futuro, que es "como máximo una vez".
Al menos una vez: el consumidor recupera el mensaje, luego lo procesa y luego guarda el desplazamiento. Si el mensaje se procesa con éxito, pero la excepción del cuidador del zoológico hace que la operación de guardado falle durante la etapa de guardado de compensación, esto dará lugar a la posibilidad de obtener el último mensaje procesado al recuperarlo nuevamente. Esto es "al menos una vez" porque el desplazamiento es. Si no lo envía al cuidador del zoológico a tiempo, el cuidador del zoológico volverá al estado normal o al estado de compensación anterior.
Exactamente una vez: Kafka no se implementa estrictamente (basado en confirmación y transacción de 2 fases. Creemos que esta estrategia es innecesaria en Kafka).
Normalmente "al menos una vez" es nuestra primera opción. (En comparación con como máximo una vez, recibir datos repetidamente es mejor que perderlos).
La alta disponibilidad de Kafka consta de varios corredores, cada corredor es un nodo
Cree un tema, que se dividirá en múltiples particiones, cada partición existe en diferentes En el corredor, cada una; La partición pone una parte de los datos.
Kafka es una cola de mensajes distribuida, lo que significa que los datos de un tema están dispersos en diferentes máquinas y cada máquina almacena una parte de los datos.
Antes de la versión 0.8, no había ningún mecanismo de alta disponibilidad. Si algún intermediario fallaba, la partición de ese intermediario sería inútil y no se podría escribir ni leer. No había ninguna alta disponibilidad.
Después de la versión 0.8, se proporciona el mecanismo HA, que es el mecanismo de réplica. Los datos de cada partición se sincronizarán con otras máquinas para formar sus propias copias de réplicas múltiples. Entonces todas las réplicas elegirán un líder, luego la producción y el consumo se ocuparán de este líder, y otras réplicas serán seguidores.
Al escribir, el líder será responsable de sincronizar los datos con todos los seguidores. Al leer, simplemente lea los datos del líder directamente.
Kafka distribuirá uniformemente todas las réplicas de una partición en diferentes máquinas para mejorar la tolerancia a fallos.
Si un determinado corredor deja de funcionar, estará bien. Las particiones que contiene tienen copias en otras máquinas. Si hay un líder de una determinada partición, entonces se reelegirá un nuevo líder. En este momento, salga y todos podrán seguir leyendo y escribiendo al nuevo líder. A esto se le llama alta disponibilidad.
Al escribir datos, el productor escribe al líder, y luego el líder escribe los datos en el disco local, y luego otros seguidores toman la iniciativa de extraer datos del líder. Una vez que todos los seguidores hayan sincronizado los datos, enviarán un reconocimiento al líder. Después de que el líder reciba los reconocimientos de todos los seguidores, devolverá un mensaje de escritura exitosa al productor.
La pérdida de mensajes se producirá en tres enlaces, a saber, productor, mq middleware y consumidor:
RabbitMQ
Kafka
Más o menos lo mismo como RabbitMQ.
Rabbitmq
Los mensajes que deben entregarse en orden deben entregarse en la misma cola. Esta cola solo puede tener un consumidor. Si necesita mejorar el rendimiento, puede utilizar un. cola de memoria en cola y luego distribuirla a Diferentes trabajadores en la capa inferior la manejan.
Kafka
Los datos escritos en una partición deben estar en orden. Cuando el productor escribe, puede especificar una clave, como especificar la identificación del pedido como clave, y los datos relacionados con el pedido definitivamente se distribuirán a una partición. Cuando el consumidor extrae los datos de la partición, debe estar en orden. Cada dato se coloca en una cola de memoria correspondiente. Si hay varios datos relacionados en una partición, se utilizan varias colas de memoria cada una. El hilo maneja una cola de memoria.