El papel del cuidador del zoológico en Kafka
Los productores se conectan directamente con los corredores.
El productor sube datos al agente. Los productores pueden especificar cuántas particiones y copias de seguridad de datos hay. En la imagen de arriba, los datos tienen dos particiones 0 y 1, cada una con su propia copia: 0' y 1'.
La partición amarilla es la líder y la partición blanca es la seguidora.
El nodo maestro maneja todas las solicitudes de lectura y escritura para la partición, mientras que el nodo esclavo replica pasivamente periódicamente los datos en el nodo maestro. Como se muestra en la imagen de abajo, los rojos son líderes y los verdes son seguidores. El líder se copia a sí mismo en otros corredores:
Las particiones de temas se colocan en diferentes corredores para garantizar que los productores y consumidores escalonen el acceso al corredor, eviten la presión excesiva de E/S causada por el acceso a un único corredor y equilibren la carga. .
Los agentes están distribuidos y son independientes entre sí, pero se necesita un sistema de registro para administrar los agentes en todo el clúster, por lo que en este momento se utiliza Zookeeper. En Zookeeper, habrá un nodo dedicado a registrar la lista de servidores proxy:
/Broker/ID card
Cada Broker se registrará en Zookeeper cuando se inicie, es decir, en / Cree su propio nodo en brokers/ids, como /brokers/ids/[0...n].
Kafka utiliza un número único global para referirse a cada servidor proxy. Diferentes corredores deben registrarse con diferentes ID de corredor. Una vez creado el nodo, cada agente registrará su propia dirección IP e información de puerto en el nodo. Entre ellos, el tipo de nodo creado por el Broker es un nodo temporal. Una vez que el Broker deja de funcionar, el nodo temporal correspondiente se eliminará automáticamente.
En Kafka, los mensajes sobre el mismo tema se dividen en varias particiones y se distribuyen en varios intermediarios. Zookeeper también mantiene esta información de partición y la relación correspondiente con el agente y la registra mediante nodos especiales, por ejemplo:
/weird/topic
Cada tema en Kafka se registrará en la forma de /brokers/topics/[tema], como /brokers/topics/login y /brokers/topics/search. Una vez iniciado el servidor proxy, registrará su propia ID de proxy en el nodo de tema correspondiente (/brokers/Topics) y escribirá el número total de particiones del tema, como /brokers/Topics/log in/3-gt; 2. Este nodo representa un servidor proxy con ID de proxy 3. Para el mensaje del tema "iniciar sesión", se proporcionan dos particiones para el almacenamiento de mensajes. Asimismo, este nodo de partición también es un nodo temporal.
Debido a que el mismo mensaje de tema se dividirá y distribuirá en varios corredores, los productores deben enviar mensajes a estos corredores distribuidos de manera razonable. Entonces, ¿cómo lograr el equilibrio de carga de los productores? Kafka admite el equilibrio de carga tradicional de cuatro capas y el modo Zookeeper para lograr el equilibrio de carga.
(1) El equilibrio de carga de cuatro capas determina el proxy asociado en función de la dirección IP y el puerto del productor. Por lo general, un productor corresponde a un solo corredor y luego todos los mensajes generados por el productor se envían al corredor. La lógica de este método es simple: cada productor no necesita establecer conexiones TCP adicionales con otros sistemas y solo necesita mantener una única conexión TCP con el Broker. Sin embargo, no puede lograr un verdadero equilibrio de carga porque la cantidad de mensajes generados por cada productor y la cantidad de mensajes almacenados por cada corredor son diferentes en el sistema real. Si algunos productores generan muchos más mensajes que otros, el número total de mensajes recibidos por diferentes corredores será muy diferente y los productores no podrán detectar la adición y eliminación de corredores en tiempo real.
(2) Utilice Zookeeper para equilibrar la carga, porque cada agente completará el proceso de registro del agente cuando se inicie, y el productor detectará dinámicamente los cambios en la lista de servidores proxy a través de cambios en los nodos, de modo que la carga dinámica mecanismo de equilibrio.
Al igual que los productores, los consumidores en Kafka también necesitan equilibrio de carga para permitir que varios consumidores reciban mensajes razonablemente de los servidores proxy correspondientes. Cada grupo de consumidores contiene varios consumidores y cada mensaje solo se enviará a un consumidor del grupo. Diferentes consumidores consumen mensajes sobre sus propios temas específicos sin interferir entre sí.
Grupo de consumidores:
Hay varios consumidores en el grupo de consumidores.
Para cada grupo de consumidores, Kafka le asignará un ID de grupo único global, que es compartido por todos los consumidores del grupo. Cada partición de un tema de suscripción solo se puede asignar a un consumidor de un determinado grupo (por supuesto, las particiones también se pueden asignar a otros grupos).
Al mismo tiempo, Kafka asigna un ID de consumidor a cada consumidor, generalmente expresado en forma de "Nombre de host: UUID".
En Kafka, se estipula que cada partición de mensaje solo puede ser consumida por un consumidor del mismo grupo. Por lo tanto, es necesario registrar la relación entre las particiones de mensajes y los consumidores en Zookeeper. Una vez que cada consumidor determina los derechos de consumo de una partición de mensajes, debe escribir su propio ID de consumidor en el nodo temporal de la partición de mensajes correspondiente en Zookeeper, por ejemplo:
/consumers/[group_id ]/owners /[topic]/[broker_id-partition_id]
Entre ellos, [broker_id-partition_id] es el identificador de una partición de mensajes y el contenido del nodo es la identificación del consumidor en la partición de mensajes.
En el proceso en el que el consumidor consume mensajes de la partición de mensajes especificada, el desplazamiento del progreso del consumo del mensaje de la partición debe registrarse periódicamente en Zookeeper para que cuando el consumidor se reinicie u otros consumidores tomen el control de la partición de mensajes. nuevamente Una vez consumido el mensaje, el consumo del mensaje puede continuar desde el progreso anterior. El desplazamiento se registra mediante un nodo especial en Zookeeper y su ruta de nodo es:
/consumers/[group _ id]/offsets/[topic]/[broker _ id-partition _ id]
El contenido del nodo es el valor de desplazamiento.
Los pasos para que el servidor consumidor se una al grupo de consumidores durante el inicio inicial son los siguientes
Regístrese en el grupo de consumidores. Cuando se inicia cada servidor de consumidor, creará su propio nodo de consumidor en el nodo designado en Zookeeper, como /consumers/[group_ID]/IDS/[consumer_ID]. Una vez creado el nodo, los consumidores escribirán la información del tema al que se suscribieron en el nodo temporal.
Regístrese para monitorear los cambios en su base de consumidores. Cada consumidor debe prestar atención a los cambios en el servidor de consumo de Watcher en su grupo de consumidores, es decir, monitorear los cambios en los subnodos registrados del nodo /consumers/[group_id]/ids una vez que haya un aumento o disminución en los consumidores. Si se encuentra, se activará el equilibrio de carga del consumidor.
Registro para seguimiento de cambios en el servidor proxy. Los consumidores deben monitorear los nodos en /Broker/ids/[0-N]. Si se encuentran cambios en la lista de servidores proxy, determine si se requiere equilibrio de carga del consumidor según las circunstancias específicas.
Realizar equilibrio de carga de usuarios. Para garantizar que varios consumidores consuman los mensajes en diferentes particiones bajo el mismo tema de la manera más uniforme posible, si el servidor de consumidores en un grupo de consumidores cambia o el servidor proxy cambia, el proceso de asignación de consumidores y mensajes por partición suele ser el siguiente sigue Este grupo de consumidores emite equilibrio de carga de consumidores.
El siguiente es el diagrama detallado de la estructura de almacenamiento de Kafka en zookeeper:
En las primeras versiones de Kafka, zk se usaba para almacenar metainformación, el estado de consumo del consumidor y la administración de grupos y el valor del desplazamiento t T, considerando algunos factores del propio zk y problemas de punto único en toda la arquitectura, el papel del cuidador del zoológico se ha debilitado gradualmente en la nueva versión. El nuevo consumidor utiliza el protocolo de coordinación de enjambres en Kafka, que también reduce la dependencia de ZooKeeper.