Red de conocimiento informático - Conocimiento del nombre de dominio - Si desea hacer un buen trabajo en microservicios, debe tener middleware de mensajes. Comience con los conceptos básicos de Kafka.

Si desea hacer un buen trabajo en microservicios, debe tener middleware de mensajes. Comience con los conceptos básicos de Kafka.

Los microservicios son muy populares ahora y los proyectos lanzados por muchas empresas son microservicios distribuidos, pero ¿alguna vez lo han pensado? Los microservicios no se dividen en monolitos, sino que se sintonizan entre sí mediante nombres de dominio. Un buen patrón de diseño de arquitectura de microservicios requiere que cada servicio sea autónomo, de modo que el servicio pueda ser estable después de dividirse en microservicios.

¿Cómo se esfuerza cada servicio por conseguir la autonomía? Esto requiere eventos de dominio, trazabilidad de eventos, CQRS y patrones de diseño Saga. Lamento explicar muchos conceptos a la vez, pero se los explicaré más adelante.

Un punto clave en estos patrones es que necesita sincronizar datos mediante la publicación de eventos de dominio en otros servicios en ubicaciones remotas. Esto requiere middleware de mensajes. No sé mucho sobre middleware de mensajes. La empresa utiliza RocketMQ, pero la versión paga y la versión de código abierto son muy diferentes.

Escuché que muchos conceptos de Rocket MQ también provienen de Kafka. Aprender su otro middleware de mensajes básicamente no está nada mal. Hoy compartiré con ustedes un artículo que básicamente presenta a Kafka. > Kafka es una cola de mensajes (Message Queue) basada en el modelo distribuido de publicación / suscripción, que se utiliza principalmente para el procesamiento de big data en tiempo real. Sus principales objetivos de diseño son los siguientes:

Kafka es esencialmente un MQ (cola de mensajes). ¿Cuáles son los beneficios de utilizar una cola de mensajes?

A continuación se proporcionan algunos conceptos importantes de Kafka para brindarle una comprensión general de Kafka

Particiones de Kafka

La diferencia entre Kafka y la relación Zookeeper

Antes de comprender el clúster de Kafka, primero comprendamos el flujo de trabajo de Kafka, que almacena el flujo de mensajes en el tema.

Flujo de trabajo de Kafka

Los mensajes en Kafka se clasifican por tema. Los productores producen mensajes y los consumidores consumen mensajes leyendo y consumiendo el mismo tema, pero el tema es un concepto lógico. concepto Cada partición corresponde a un archivo de registro. El archivo de registro contiene la información almacenada en el tema, y ​​la información almacenada en el archivo de registro es la información almacenada en la partición. Sin embargo, el tema es un concepto lógico y la partición es un concepto físico. Cada partición corresponde a un archivo de registro y los datos almacenados en el archivo de registro son los datos producidos por el productor. Los datos generados por el productor se agregarán al final del archivo de registro en orden y cada dato se registrará con su propio desplazamiento. Cada consumidor del grupo de consumidores también realiza un seguimiento de la compensación que está utilizando actualmente para poder seguir utilizando la compensación anterior después de la recuperación del fallo.

Mecanismo de almacenamiento de Kafka

En este momento, los mensajes producidos por el Productor continuarán agregándose al final del archivo de registro, por lo que el archivo se hará cada vez más grande. Para evitar que el archivo de registro sea demasiado grande y cause corrupción de datos. Debido a la baja eficiencia de posicionamiento, Kafka adopta mecanismos de fragmentación e indexación. Divide cada partición en múltiples segmentos, y cada segmento corresponde a cuatro archivos: archivo de índice ".index", archivo de datos ".log", archivo de instantánea ".snapshot", archivo de instantánea ".snapshot", archivo de índice de tiempo ".timeindex ". Estos archivos están ubicados en la misma carpeta y la regla de nomenclatura de la carpeta es: nombre del tema - número de partición. Por ejemplo, si el servicio de informes de latidos del tema tiene tres particiones, las carpetas correspondientes son latido-0, latido-1 y latido-2.

Los archivos de índice, registro, instantánea y índice de tiempo reciben el nombre del desplazamiento del primer fragmento de información en la partición actual. El archivo .index "almacena una gran cantidad de información de índice y el archivo ".log" almacena una gran cantidad de datos. Los metadatos en el archivo de índice apuntan al desplazamiento físico de la información en el archivo de datos correspondiente.

La siguiente figura muestra la estructura de los archivos de índice y los archivos de registro:

Estructura de los archivos de índice y los archivos de registro

Para garantizar la seguridad de los datos, cada partición en kafka Se pueden configurar varias copias para cada partición. En este ejemplo, configuramos tres réplicas para las particiones 0, 1 y 2 (nota: configurar dos réplicas es más apropiado). Cada copia es un "rol". Elegirán una copia como copia líder y la otra como copia seguidora. Cuando nuestro Productor envía datos, solo puede enviarlos a la Partición líder, y luego la Partición seguidora se sincronizará con la. Cuando el lado del consumidor consume sus propios datos, los sincronizará con el lado del líder. Una vez que los datos se sincronizan con la partición líder, los consumidores solo pueden consumir datos de la partición líder cuando consumen datos.

Replicación del clúster Kafka

Replicación del clúster Kafka

El controlador Kafka es en realidad un Broker en el clúster Kafka Además del envío y consumo de mensajes del Broker normal. Además de la función de sincronización, es necesario realizar algunos trabajos adicionales. Kafka utiliza un método de elección justa para determinar el controlador. El primer corredor que cree con éxito un nodo/controlador temporal en ZooKeeper se convertirá en el controlador.

El consumidor puede experimentar cortes de energía y otras fallas durante el proceso de consumo. Cuando el consumidor se recupera, necesita continuar consumiendo desde la posición Offset antes de la falla. Por lo tanto, los consumidores deben realizar un seguimiento de qué compensación han consumido en tiempo real para poder seguir consumiendo después de la recuperación del fallo. Antes de Kafka 0.9, el consumidor guardaba el desplazamiento en ZooKeeper de forma predeterminada, pero a partir de 0.9, el consumidor guardaba el desplazamiento en el tema integrado llamado __consumer_offsets en Kafka para admitir una alta lectura y escritura simultáneas.

Arriba hemos discutido la introducción, el conocimiento básico y la arquitectura de clúster de Kafka. Discutiremos más a fondo los tres máximos de Kafka (alto rendimiento, alta disponibilidad y alta concurrencia) en el próximo artículo. Estén atentos...