1. Resumen
Como sistema distribuido de mensajes de publicación y suscripción de alto rendimiento, Kafka se usa ampliamente en aplicaciones de mensajes, especialmente en escenarios que requieren procesamiento de datos en tiempo real y seguimiento de la actividad de la aplicación. Kafka se ha convertido en el servicio preferido; antes de Kafka2.8, Kafka era fuerte Depender de ZooKeeper para administrar los metadatos del clúster también hace que el rendimiento de Kafka se vea muy afectado cuando el rendimiento del clúster de ZooKeeper fluctúa. Después de la versión 2.8, kafka3.x comenzó a proporcionar el modo KRaft (Kafka Raft, basado en Java 8+) y comenzó a eliminar la dependencia de zookeeper. En la última versión 3.5, Kafka todavía es compatible con zookeeper Controller, pero el modo de metadatos Kafka Raft ya puede iniciar Kafka de forma independiente sin depender de zookeeper.
Ventajas del modo kraft:
1. Implementación y administración más sencillas: al instalar y administrar una sola aplicación, Kafka ahora tiene una huella operativa mucho menor. Esto también hace que sea más fácil utilizar Kafka en dispositivos pequeños en el borde
2. Mejorar la escalabilidad: el tiempo de recuperación de KRaft es un orden de magnitud más rápido que ZooKeeper. Esto nos permite escalar de manera eficiente a millones de particiones en un solo clúster. El límite efectivo de ZooKeeper es decenas de miles
3. Propagación de metadatos más eficiente: la propagación de metadatos basada en registros y basada en eventos puede mejorar el rendimiento de muchas funciones principales de Kafka. Además, admite la creación de instantáneas de temas de metadatos.
Enlace de datos: sitio web oficial kraft , kafka_jira
2. Topología
2.1 Topología temprana
El principio de la antigua elección del controlador: sólo un corredor puede ser elegido como controlador. Cuando el corredor donde se encuentra el controlador está inactivo, otros corredores pueden competir para ser elegido como controlador.
Kafka hace esto utilizando números de época (números de época, también conocidos como tokens de aislamiento). El número de época es simplemente un número que aumenta monótonamente. Cuando se selecciona el Controlador por primera vez, el valor del número de época es 1. Si se selecciona un nuevo Controlador nuevamente, el número de época será 2, lo que aumenta monótonamente.
Cada controlador recién seleccionado obtiene un número de época nuevo y mayor mediante la operación de incremento condicional de Zookeeper. Después de que otros Brokers conocen el número de época actual, si reciben mensajes que contienen números de época más antiguos (más pequeños) enviados por el controlador, los ignorarán, es decir, el Broker distingue el último controlador actual según el número de época más grande.
Hay varios estados de réplica comunes:
Nuevo: el estado de la réplica cuando el controlador acaba de crear la réplica. La réplica en este estado
solo puede convertirse en una réplica seguidora
. Después de que el intermediario esté inactivo, el estado de la réplica cambiará a Sin conexión
ReplicaDeletionStarted: cuando el clúster de Kafa habilita el tema eliminación y recibe un comando de eliminación para un tema, la réplica bajo el tema entrará en este estado. ReplicaDeletionSuccessful
: cuando la réplica se elimina correctamente, la réplica entrará en este estado.
ReplicaDeletionIneligible: cuando una réplica no se puede eliminar, la réplica entrará este estado, esperando a que el controlador vuelva a intentarlo.
No existente: cuando la réplica se elimina correctamente, la réplica entrará en este estado, o cuando la réplica acaba de crearse pero no se ha establecido. , la réplica está en este estado.
Cuando se acaba de crear el tema de Kafka, la copia del tema está en el estado No existente . En este momento, el controlador carga la información de copia de cada partición del tema en Zookeeper en la memoria y al mismo tiempo actualiza la copia a el estado Nuevo , y luego el controlador selecciona la primera copia de la partición. Actúa como la réplica líder y configura todas las réplicas en el ISR, luego persiste la decisión en Kafka.
Después de determinar la copia de la partición y el líder, el controlador enviará la información a cada copia y sincronizará el estado de la copia a todos los corredores al mismo tiempo. Una vez completadas las operaciones anteriores, la copia entrará en el estado En línea .
Cuando la operación de eliminación de tema está habilitada, el controlador detendrá todas las réplicas. Si es una réplica seguidora, dejará de recuperar datos de la réplica líder. Si es una réplica líder, el controlador establecerá el líder de la división en NO_LEADER y luego la réplica entrará en el estado Sin conexión . Inmediatamente después, el controlador cambiará el estado de la réplica a ReplicaDeletionStarted para indicar que se inició la eliminación del tema. El controlador enviará una solicitud de eliminación a todas las réplicas, solicitándoles que eliminen los datos de la réplica local. Cuando todas las réplicas se eliminen correctamente , entrará en el estado ReplicaDeletionSuccessful . Suponiendo que una de las réplicas no se puede eliminar durante el proceso de eliminación , ingresará al estado ReplicaDeletionIneligible y esperará a que el controlador vuelva a intentarlo. Al mismo tiempo, si está en el estado ReplicaDeletionSuccessful, cambiará automáticamente al estado No existente y la caché de contexto del controlador borrará la información de la réplica.
Aquí está el estado de la partición:
No existente: indica que la partición no existe o que se ha eliminado.
Nuevo: una vez creada la partición, la partición se encuentra en este estado. En este momento, Kafka ha determinado la lista de particiones, pero el líder y el ISR aún no han sido seleccionados.
En línea: una vez seleccionado el líder de la partición, ingresará a este estado, lo que indica que la partición puede funcionar normalmente.
Sin conexión: cuando el intermediario donde se encuentra el líder de la partición está inactivo, ingresará a este estado, lo que indica que la partición no puede funcionar normalmente.
Al crear un tema, el controlador es responsable de crear objetos de partición: primero, establece brevemente todas las particiones en el estado Inexistente , luego lee el plan de asignación de réplicas en Zookeeper y luego hace que las particiones entren en el estado Nuevo . Una partición en el estado Nuevo entrará en el estado En línea cuando se seleccione una copia líder e ISR .
Si el usuario inicia la operación de eliminación del tema, la partición entrará en el estado Inexistente y también se habilitará la operación de eliminación de réplicas en la partición. Si la operación del corredor se cierra o el sistema falla, el controlador juzgará si el corredor es el líder de la partición. Si es así, debe iniciar una nueva ronda de elección del líder de la partición y luego cambiar el estado de la partición nuevamente al estado En línea.
2.2 Topología del controlador kRaft
Clúster en modo Kafka Kraft: debe ser un número impar de nodos, 3 nodos tienen una tolerancia máxima a fallas de 1 y 5 nodos tienen una tolerancia máxima a fallas de 2
En un clúster de KRaft, todos los agentes del controlador mantienen una caché de metadatos en memoria actualizada para que cualquier controlador pueda asumir el control como controlador activo si es necesario. Todos los corredores se comunican con el controlador, donde el controlador activo El corredor se encargará de la comunicación cambios en los metadatos con otros intermediarios. KRaft se basa en el protocolo de consenso Raft , que se introdujo en Kafka como parte de KIP-500, con más detalles definidos en otros KIP relacionados. El controlador activo es el líder de una única partición del tema de metadatos dentro del clúster de Kafka Kraft, otros controladores son seguidores de réplicas y los intermediarios son observadores de réplicas. Entonces, en lugar de que los controladores transmitan cambios de metadatos a otros controladores o intermediarios, cada uno de ellos busca activamente los cambios. Esto hace que sea muy eficiente mantener sincronizados a todos los controladores y corredores y también reduce los tiempos de reinicio de los corredores y controladores.
En el modo KRaft, los metadatos del clúster (que reflejan el estado actual de todos los recursos administrados por el controlador) se almacenan en un tema llamado __cluster_metadata. KRaft utiliza este tema para sincronizar los cambios de estado del clúster entre los nodos del controlador y del agente. En modo KRaft, un clúster Kafka puede ejecutarse en modo dedicado o compartido. En el modo dedicado, algunos nodos tienen su configuración de funciones de proceso establecida en controlador, mientras que el resto de los nodos la configuran como intermediario. Para el modo compartido, estos nodos tendrán funciones de proceso configuradas como controlador, intermediario, es decir, algunos nodos realizarán una doble función. El nodo especial en este modo llamado "controlador" es responsable de gestionar el registro de agentes en el clúster, que suele ser el primer nodo en controlador.quorum.voters. La actividad del corredor tiene dos condiciones:
1. Los corredores deben mantener una sesión activa con el controlador para poder recibir actualizaciones periódicas de metadatos. La “sesión activa” depende de la configuración del clúster, una sesión activa se mantiene enviando latidos periódicos al controlador . Si el controlador no recibe un latido antes de que expire el tiempo de espera configurado por broker.session.timeout.ms , entonces el nodo se considera fuera de línea.
2. Los intermediarios que actúan como seguidores deben replicar las escrituras del líder y no quedarse “demasiado” atrás.
En el modo Kradt, los controladores almacenan los metadatos del clúster en el directorio especificado en metadata.log.dir/el primer directorio de registro. En particular, al agregar un nuevo nodo de controlador, debe esperar a que el controlador existente envíe todos los datos: el nuevo nodo de controlador no debe formatearse ni iniciarse hasta que la mayoría de los controladores tengan todos los datos confirmados. y confirme con el siguiente comando: kafka-metadata-quorum.sh --bootstrap-server broker_host:port describe --replication, sería mejor si el valor de Lag mostrado es 0, al menos asegúrese de que el valor de Lag sea lo suficientemente pequeño para los controladores, o si el desplazamiento final del líder no aumenta, puede esperar hasta que el retraso sea 0 para la mayoría; si no es 0, verifique Los dos valores de LastFetchTimestamp y LastCaughtUpTimestamp, los dos valores de todos los controladores deben estar lo más cerca posible, es decir, la lectura y el consumo deben ser consistentes; luego se puede ejecutar: formatee la ruta de almacenamiento de metadatos del nuevo controlador; tenga en cuenta que el bin/kafka-storage.sh format --cluster-id uuid --config server_propertiesmodo mixto En este caso, el formato de almacenamiento informará un error: Directorio de registro... ya está formateado, esta situación solo ocurre en modo mixto y el La ruta de registro del controlador original se pierde o daña, puede ejecutar: y no se recomienda usarlo en otros casos bin/kafka-storage.sh format --cluster-id uuid --ignore-formatted --config server_properties. Los controladores se utilizan para recibir solicitudes de otros controladores y trabajadores. Por lo tanto, incluso si el servidor no tiene habilitada la función de controlador (es decir, es solo un intermediario), aún debe definir el escucha del controlador y cualquier propiedad de seguridad necesaria para configurarlo. Ejemplo de referencia de configuración:
process.roles=broker
listeners=BROKER://localhost:9092 #broker does not expose the controller listener itself
inter.broker.listener.name=BROKER #区别于下面的controller.listener.names
controller.quorum.voters=0@localhost:9093
controller.listener.names=CONTROLLER #仅用于controller
listener.security.protocol.map=BROKER:SASL_SSL,CONTROLLER:SASL_SSL
#混合模式
process.roles=broker,controller
listeners=BROKER://localhost:9092,CONTROLLER://localhost:9093 #listeners独立配置用户kafka 客户端访问
inter.broker.listener.name=BROKER #配合上面的与kafka client交互，隔离开controller
controller.quorum.voters=0@localhost:9093
controller.listener.names=CONTROLLER #The controller will accept requests on all listeners defined by controller.listener.names，多个controller时，the first one in the list will be used for outbound requests.
listener.security.protocol.map=BROKER:SASL_SSL,CONTROLLER:SASL_SSL
Consulte KRaft Principal Forwarding para obtener más información . Nota: El modo mixto en modo kraft se usa principalmente en el entorno de desarrollo y no se recomienda para el entorno de producción. Un problema obvio en el modo híbrido es que el controlador estará menos aislado del resto del sistema, es decir, no se puede aislar del corredor. Un escenario típico es que el controlador no se puede expandir o revertir elásticamente y actualizar por separado. ; en el modo KRaft, un servidor Kafka específico será seleccionado como controlador; todos los controladores candidatos definidos participarán en la elección de metadatos, y para el controlador activo, otros controladores actuarán como roles de espera activa; por lo tanto, nuestra práctica común es para configurar Process.role como intermediario/controlador en lugar de Ambos están disponibles (modo mixto); se recomienda que un clúster Kafka use 3 controladores, y no se recomiendan más de 3 controladores. El controlador Kafka almacena todos los metadatos del cluster en la memoria y el disco. La recomendación oficial es asignar espacio 5G para que la memoria y el disco almacenen estos registros de metadatos, además, kraft también tiene algunas limitaciones, por ejemplo, las siguientes funciones no están en modo KRaft. Totalmente implementado en:
1. Configurar usuarios SCRAM a través de la API de administración
2. Admitir configuración JBOD con múltiples directorios de almacenamiento
3. Modificar algunas configuraciones dinámicas en controladores KRaft independientes
4. Delegar tokens
Proceso de replicación de metadatos de KRaft:
los metadatos del clúster se almacenan en temas de Kafka y el controlador activo es el líder de una única partición del tema de metadatos, que recibirá todos los datos y los escribirá. Otros controladores actúan como seguidores y recogerán activamente estos cambios. En comparación con la replicación de réplicas tradicional, cuando es necesario elegir un nuevo líder, se realiza mediante arbitraje en lugar de sincronizar conjuntos de réplicas. Por lo tanto, la replicación de metadatos no involucra ISR. Otra diferencia es que los registros de metadatos se vacían inmediatamente en el disco a medida que se escriben en el registro local de cada nodo.
Modo Kraft y configuración de autenticación de seguridad:
SASL/GSSAPI: método de autenticación Kerberos, generalmente utiliza el método de autenticación de tabla de claves con contraseña aleatoria, la contraseña está encriptada y también es el método de autenticación más utilizado en las empresas; SASL/PLAIN: este método es en realidad un método de autenticación de cuenta/contraseña, pero
Hay muchas fallas, como que el nombre de usuario y la contraseña se almacenan en el archivo, no se pueden agregar dinámicamente, la contraseña es texto sin formato, etc. La ventaja es que es bastante simple;
SASL/SCRAM: Otro método de autenticación proporcionado para la escasez del método SASL/PLAIN. El nombre de usuario/contraseña de esta manera se almacena en zookeeper, por lo que puede admitir la adición dinámica de usuarios. Este método de autenticación también utiliza sha256 o sha512 para cifrar la contraseña, que es relativamente más segura y se introdujo en la versión 0.10.2;
3. Configuración de implementación
wget https://archive.apache.org/dist/kafka/3.4.0/kafka_2.13-3.4.0.tgz
tar -zxvf kafka_2.13-3.4.0.tgz -C /opt/
mv /opt/kafka_2.13-3.4.0. /opt/kafka
chown kafka:kafka -R /opt/kafka
cd /opt/kafka/
mkdir data
vim /opt/kafka/config/kraftserver.properties //如下所示
# The role of this server. Setting this puts us in KRaft mode
process.roles=broker,controller #the server acts as both a broker and a controller
# The node id associated with this instance's roles
node.id=2
# The connect string for the controller quorum 集群选举控制器配置，默认走 PLAINTEXT协议除非显示定义其他协议
controller.quorum.voters=1@172.18.1.176:9093,[email protected]:9093,[email protected]:9093
############################# Socket Server Settings #############################
# The address the socket server listens on.
# Combined nodes (i.e. those with `process.roles=broker,controller`) must list the controller listener here at a minimum.
# If the broker listener is not defined, the default listener will use a host name that is equal to the value of java.net.InetAddress.getCanonicalHostName(),
# with PLAINTEXT listener name, and port 9092.
# FORMAT:
# listeners = listener_name://host_name:port
# EXAMPLE:
# listeners = PLAINTEXT://your.host.name:9092
listeners=PLAINTEXT://172.31.7.237:9092,CONTROLLER://172.18.1.217:9093
# Name of listener used for communication between brokers. it is used exclusively仅用于 for requests between brokers
inter.broker.listener.name=PLAINTEXT #注意与controller.listener.names不要冲突
# Listener name, hostname and port the broker will advertise to clients.
# If not set, it uses the value for "listeners".
#advertised.listeners=PLAINTEXT://172.18.1.217:9092
#完成后，生成整个集群有一个唯一的ID标志，使用uuid。可使用官方提供的 kafka-storage 工具生成
/opt/kafka/bin/kafka-storage.sh random-uuid
或
KAFKA_CLUSTER_ID="$(bin/kafka-storage.sh random-uuid)"
#用上述ID格式化存储路径
/opt/kafka/bin/kafka-storage.sh format -t clust_ID -c /opt/kafka/config/kraft/server.properties
或
bin/kafka-storage.sh format -t $KAFKA_CLUSTER_ID -c config/kraft/server.properties
#完成后以kraft模式启动服务
bin/kafka-server-start.sh -daemon ./config/kraft/server.properties
#创建topic
bin/kafka-topics.sh --create --topic First_Kafka_Topic --partitions 1 --replication-factor 3 --bootstrap-server 172.31.7.237:9092
#查看
bin/kafka-topics.sh --list --bootstrap-server 172.31.7.237:9092
2) script de inicio de Kafka
#!/bin/bash
#kafka集群启动脚本
case $1 in
"start"){
for i in 172.18.1.176,172.18.1.217,@172.18.1.150
do
echo "--------启动 $i kafka with kraft-------"
ssh $i "/home/kafka/bin/kafka-server-start.sh -daemon /home/kafka/config/kraft/server.properties"
done
};;
"stop"){
for i in 172.18.1.176,172.18.1.217,@172.18.1.150
do
echo "------停止 $i kafka--------"
ssh $i "/home/kafka/bin/kafka-server-stop.sh"
done
};;
esac
3) configuración de autenticación de seguridad kafka kRaft SASL/PLAIN:
Cree un nuevo archivo de configuración config/kafka_server_jaas.conf, de la siguiente manera:
KafkaServer {
org.apache.kafka.common.security.plain.PlainLoginModule required
serviceName="kafka"
username="admin"
password="admin"
user_admin="admin";
};
Copie una copia de kafka-server-start.sh, modifique el nombre del script de inicio kafka-server-start-sasl.sh, modifique el nombre e importe archivos cifrados:
……
if [ "x$KAFKA_HEAP_OPTS" = "x" ]; thenexport KAFKA_HEAP_OPTS="-Xmx1G -Xms1G -Djava.security.auth.login.config=/opt/kafka/kafka_2.13-3.4.0/config/kafka_server_jaas.conf"
fi
……
Copie una copia de server_sasl.properties y modifique el nombre a server_sasl.properties para separarlo de la autenticación que no es de seguridad, edite:
node.id=1
controller.quorum.voters=1@kraft1:9093
listeners=SASL_PLAINTEXT://172.31.7.237:9092,CONTROLLER:///172.18.1.217:9093
inter.broker.listener.name=SASL_PLAINTEXT
advertised.listeners=SASL_PLAINTEXT://172.31.7.237:9092
sasl.enabled.mechanisms=PLAIN
sasl.mechanism.inter.broker.protocol=PLAIN
Inicie Kafka cuando termine:sh ./bin/kafka-server-start-sasl.sh -daemon ./config/kraft/server_sasl.properties
4. Apéndice: Revisión de conocimientos
4.1, Comparación de colas de mensajes de uso común
1）ConejoMQ
RabbitMQ es una cola de mensajes de código abierto escrita en Erlang. Admite muchos protocolos: AMQP, XMPP, SMTP, STOMP, por lo que es muy pesado y más adecuado para el desarrollo a nivel empresarial. Al mismo tiempo, se implementa la arquitectura Broker, lo que significa que los mensajes se colocan primero en la cola central cuando se envían al cliente. Tiene buen soporte para enrutamiento, equilibrio de carga o persistencia de datos.
2）Redis
Redis es una base de datos NoSQL basada en pares clave-valor, y su desarrollo y mantenimiento son muy activos. Aunque es un sistema de almacenamiento de bases de datos Key-Value, él mismo admite la función MQ, por lo que puede usarse como un servicio de cola liviano. Para las operaciones de poner y quitar la cola de RabbitMQ y Redis, ejecútelas 1 millón de veces cada una y registre el tiempo de ejecución cada 100.000 veces. Los datos de prueba se dividen en cuatro tamaños diferentes de datos: 128Bytes, 512Bytes, 1K y 10K. Los experimentos muestran que cuando los datos son relativamente pequeños, el rendimiento de Redis al ingresar al equipo es mayor que el de RabbitMQ, y si el tamaño de los datos excede los 10K, Redis es insoportablemente lento; al salir del equipo, independientemente del tamaño de los datos , Redis muestra un muy buen rendimiento, mientras que el rendimiento de eliminación de cola de RabbitMQ es mucho menor que el de Redis.
3) CeroMQ
ZeroMQ es conocido como el sistema de cola de mensajes más rápido, especialmente para escenarios de demanda de alto rendimiento. ZeroMQ puede implementar colas avanzadas/complejas en las que RabbitMQ no es bueno, pero los desarrolladores necesitan combinar múltiples marcos técnicos por sí mismos. La complejidad técnica es un desafío para la aplicación exitosa de este MQ. ZeroMQ tiene un modelo único sin middleware, no necesita instalar ni ejecutar un servidor de mensajes o middleware, porque su aplicación desempeñará esta función de servidor. Simplemente necesita hacer referencia a la biblioteca ZeroMQ, que se puede instalar usando NuGet, y luego podrá enviar mensajes entre aplicaciones. Pero ZeroMQ solo proporciona colas no persistentes, lo que significa que si deja de funcionar, los datos se perderán. Entre ellos, la versión Storm de Twitter anterior a 0.9.0 usa ZeroMQ como transmisión de flujo de datos de forma predeterminada (Storm admite tanto ZeroMQ como Netty como módulos de transmisión desde la versión 0.9).
4）ActivoMQ
ActiveMQ es un subproyecto de Apache. Al igual que ZeroMQ, puede implementar colas con tecnología de intermediario y de igual a igual. Al mismo tiempo, al igual que RabbitMQ, puede implementar de manera eficiente escenarios de aplicaciones avanzadas con una pequeña cantidad de código.
5) Kafka/Jafka
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, y Jafka se incuba sobre Kafka, que es una versión mejorada de Kafka. Tiene las siguientes características: persistencia rápida, la persistencia de mensajes se puede realizar bajo la sobrecarga del sistema O (1); alto rendimiento, que puede alcanzar una tasa de rendimiento de 10 W/s en un servidor normal; sistema distribuido completo, Broker, Productor y Consumidor. todos admiten de forma nativa y automática el equilibrio de carga automático distribuido; admiten la carga paralela de datos de Hadoop, para datos de registro y sistemas de análisis fuera de línea como Hadoop, pero requieren restricciones de procesamiento en tiempo real, esta es una solución factible. Kafka unifica el procesamiento de mensajes en línea y fuera de línea a través del mecanismo de carga paralela de Hadoop. Apache Kafka es un sistema de mensajería muy ligero en comparación con ActiveMQ y, además de su muy buen rendimiento, también es un sistema distribuido que funciona bien. La implementación liviana de un solo proceso de Kafka3.0 no solo puede reemplazar las colas de mensajes tradicionales como ActiveMQ y RabbitMQ, sino que también es adecuada para escenarios de borde y escenarios que utilizan hardware liviano. Los datos muestran que en un clúster que puede gestionar 2 millones de particiones, el proceso de migración del Quorum Controller en la nueva versión de kafka3.0 se puede acortar de unos pocos minutos a 30 segundos, rompiendo el principal cuello de botella de la gestión de metadatos que limita El alcance del clúster Kafka, el apagado y el reinicio son más de diez veces más rápidos que Kafka2.8, ¡y el rendimiento está completamente aplastado!
4.2 El principio de Kafka
Un nuevo protocolo de replicación para Kafka, que se introdujo en Kafka 2.4. El objetivo del protocolo Kraft es mejorar la confiabilidad y la capacidad de mantenimiento de Kafka y satisfacer las necesidades del procesamiento de flujo distribuido; incluye principalmente los siguientes aspectos:
1. Descentralización : El protocolo Kraft descentraliza los nodos controladores de Kafka y cada copia puede convertirse en un controlador, mejorando así la confiabilidad y la tolerancia a fallas del sistema.
2. Atomicidad: el protocolo Kraft utiliza el protocolo de transmisión atómica para garantizar la atomicidad de los mensajes, es decir, todas las réplicas recibirán el mismo mensaje, lo que garantiza la coherencia de los datos. 3.
Escalabilidad: el protocolo Kraft admite la adición y eliminación dinámica de réplicas, por lo que mejorando la escalabilidad y mantenibilidad del sistema.
4. Confiabilidad: el protocolo Kraft utiliza el algoritmo Raft para garantizar la coherencia entre réplicas, mejorando así la confiabilidad y la tolerancia a fallas del sistema.
4.3 Herramienta de gestión DoctorKafka
Es un proyecto derivado de los productos de Pinterest. Para expandir la escala de operación y mantenimiento de los servicios de Kafka, Pinterest creó DoctorKafka para administrar la autorreparación y el equilibrio de carga de trabajo del clúster de Kafka; DoctorKafka puede detectar fallas del corredor Kafka y transferir automáticamente la carga de los corredores fallidos a los corredores sanos. Ahora, Pinterest ha abierto el proyecto en GitHub. DoctorKafka consta de tres partes, la arquitectura es la siguiente:
1. El recopilador de métricas implementado en cada corredor recopila periódicamente las métricas del proceso Kafka, las aloja y las publica en un tema de Kafka. Aquí, Kafka se utiliza como almacenamiento de estado del corredor. De esta manera, se puede simplificar el proceso de construcción de DoctorKafka y reducir la dependencia de otros sistemas; cada corredor ejecutará un recolector de indicadores, que recopilará las entradas y salidas. red de Kafka broker Métricas de tráfico y el estado de cada réplica.
2. El servicio centralizado DoctorKafka administrará múltiples clústeres, analizará los indicadores de estado del intermediario para detectar fallas del intermediario y ejecutará comandos de equilibrio de carga y autorreparación del clúster. DoctorKafka registrará los comandos ejecutados en otro tema llamado "Registro de acciones"
3. Página de interfaz de usuario web para explorar el estado del clúster de Kafka y el proceso de ejecución.
Una vez que se inicia el servicio DoctorKafka, primero leerá el estado del corredor durante las últimas 24 a 48 horas y, en base a esto, DoctorKafka inferirá los recursos necesarios para cada carga de trabajo de réplica. Debido a que las cargas de trabajo de Kafka requieren principalmente un uso intensivo de la red, DoctorKafka se centra principalmente en el uso del ancho de banda de la red por parte de las réplicas. Después de que se inicie DoctorKafka, comprobará periódicamente el estado de cada clúster. Cuando detecta una falla del corredor, transfiere la carga de trabajo del corredor fallido a un corredor con suficiente ancho de banda. Advierte si no hay suficientes recursos en el clúster para reasignarlos. De manera similar, cuando DoctorKafka realiza el equilibrio de carga de trabajo, identificará el corredor cuyo tráfico de red excede la configuración y transferirá la carga de trabajo al corredor con menos tráfico, o realizará un mejor esquema de elección de líder (elección de líder) para desviar el tráfico.
DoctorKafka lleva varios meses funcionando en Pinterest y ayuda a su personal de operaciones a gestionar más de 1000 clusters. Consulte la dirección del proyecto para obtener más información .
4.4、Kafka WebUI y Kowl
Kowl (Kafka Owl): Kafka WebUI para explorar mensajes, consumidores, configuraciones y más con un enfoque en una buena UI. Para obtener más información, consulte: Dirección del proyecto .
Además de lo anterior, existen 9 herramientas comunes de Kafka UI, además de LogiKM y kafka-console-ui, porque Kafka-UI es completamente funcional y gratuito, se recomienda.
1 AKHQ Gratis
2 Kowl Carga parcial
3 Kafdrop Gratis
4 UI para Apache Kafka Gratis
5 Lenses Gratis
6 CMAK Gratis
7 Confluent CC Charge
8 Conduktor Charge
9 LogiKM Gratis
10 kafka-console-ui Gratis
Por lo general, el programa se ejecuta a través de un contenedor acoplable y la mayor ventaja de Kowl es su excelente interfaz de usuario. Es conveniente, fácil de usar y fácil de usar; la interfaz después del lanzamiento es la siguiente:
Kowl proporciona exploración de mensajes, seguimiento en tiempo real y soporte para Protobuf, Avro y Amazon MSK IAM, pero sistemas de inicio de sesión (Google, GitHub, Okta) y permisos RBAC con sincronización de grupo. Solo disponible para planes pagos de Kowl Business. Kowl también carece de características como administración de múltiples clústeres, configuración dinámica de temas, adición de particiones, cambios de réplica, administración de Kafka Connect, registro de esquemas, integración de KSQL, topología de Kafka Streams, modo de solo lectura y visualización y gráficos de métricas JMX.