Cómo garantizar la fiabilidad de la información enviada por los productores de Kafka
Específicamente, las características de distribución de Kafka: las particiones de los mensajes de Kafka se distribuyen en algunos servidores en el clúster de Kafka. Cada partición tiene un servidor como líder y cero o más como seguidores. El líder maneja todas las solicitudes de lectura y escritura para la partición, mientras que los esclavos sincronizan pasivamente los datos del líder. Si el líder deja de ser saludable, otros seguidores elegirán automáticamente un nuevo líder. Cada servidor puede actuar como líder para algunas particiones y seguidor de otras particiones, de modo que la carga del clúster esté bien equilibrada y se logre la tolerancia a fallos.
El factor de réplica predeterminado de Kafka es 3, es decir, cada partición tiene solo 1 réplica líder y 2 réplicas seguidoras.
Dado que Kafka es un sistema distribuido, existe el riesgo de que los seguidores no puedan sincronizarse con el líder en tiempo real. ¿Bajo qué condiciones se puede sincronizar una copia seguidora con el líder? El mecanismo de replicación síncrona ISR resuelve este problema.
La réplica sincronizada (ISR) se denomina réplica sincrónica y las réplicas en la ISR están sincronizadas con el líder. ¿Qué copias hay en el ISR? En primer lugar, está claro que la copia líder siempre existe en el ISR, y que la copia seguidora esté en el ISR depende de si la copia seguidora está "sincronizada" con la copia líder.
El servidor broker de Kafka tiene un parámetro replica.lag.time.max.ms, que indica el intervalo de tiempo máximo entre la copia seguidora y la copia líder. El valor predeterminado es 10 segundos. Siempre que el intervalo de tiempo entre la copia seguidora y la copia líder no exceda los 10 segundos, la copia seguidora y la copia líder se consideran sincronizadas. Incluso si la copia del seguidor está unos pocos mensajes detrás de la copia del líder, no será expulsada siempre que alcance a la copia del líder en 10 segundos. Si la copia seguidora es expulsada de la lista ISR, cuando alcance a la copia líder, se agregará nuevamente a la lista ISR, por lo que ISR es una lista dinámica, no una lista estática.
El parámetro ack determina principalmente si la copia de la partición líder del clúster Kafka responde exitosamente después de recibir el mensaje, o si la partición compañera responde exitosamente después de sincronizarse con el líder. Este parámetro juega un papel importante a la hora de determinar si el mensaje se pierde:
1) ack = 0, el generador no esperará ninguna respuesta del servidor antes de escribir el mensaje con éxito. Como no es necesario esperar una respuesta del servidor, los mensajes se pueden enviar a la velocidad máxima admitida por la red, lo que genera un alto rendimiento.
2)ack = 1. Siempre que la réplica de la partición primaria del clúster reciba el mensaje, responderá exitosamente al productor. Una vez que el mensaje no se puede escribir en la copia de la partición líder (por ejemplo, debido a razones de red, el nodo líder falla), el productor recibirá una respuesta de error y reenviará el mensaje. El rendimiento de este método depende de si se utiliza transmisión asíncrona o síncrona.
3) ack = all, siempre que el número de réplicas sincronizadas del ISR sea mayor o igual al número mínimo de réplicas sincronizadas min.insync.replicas (recordatorio: ISR es dinámico), el El productor recibirá una respuesta exitosa del servidor. Este modo es el de mayor nivel y más seguro, lo que garantiza que más de un corredor reciba el mensaje. La latencia en este modo será alta.
Cuando acks = all, las respuestas al productor tendrán éxito siempre que todas las réplicas activas y en espera en la réplica de sincronización ISR estén sincronizadas. De hecho, hay un problema aquí: la copia de sincronización ISR es dinámica y solo puede contener una copia líder (equivalente a ack = 1) o todas las copias (esto no es necesario, siempre que más de la mitad de las copias en el general El escenario bizantino se sincroniza normalmente. Requiere un parámetro para determinar al menos cuántas réplicas deben sincronizarse correctamente para que el generador responda correctamente.
Para solucionar este problema, el broker de Kafka proporciona un parámetro **min.insync.replicas**, que al menos controla el número de réplicas a escribir. El valor predeterminado es 1. En un entorno de producción, varios nodos pueden satisfacer el escenario general bizantino, dependiendo de si se implementa con un solo nodo o con varios nodos. Tomemos como ejemplo el escenario de 3 nodos.
Escenario 1 de 3 nodos: cuando min.insync.replicas = 2, acks = all, si la lista ISR es solo 3, siempre que las dos réplicas estén sincronizadas, el productor recibirá una respuesta exitosa.
Escenario 2 de 3 nodos: cuando min.insync.replicas=2, si solo hay una lista de ISR, 3 se elimina de la lista de ISR. Cuando acks = all, la respuesta falla (el productor necesita reenviar el mensaje hasta que la respuesta sea exitosa; cuando acks = 0 o ack = 1, los datos se escriben correctamente);
Ps: En este escenario, acks = all, ¿el clúster de Kafka responderá directamente al error una vez que falle la sincronización? ¿Todavía hay una pausa? El generador ha enviado el mensaje a la partición primaria. ¿Cómo procesa Kafka esta información? ¿Unirse a un clúster es persistente? ¿Qué debo hacer con el mensaje enviado después de volver a intentarlo?
Escenario 3 de 3 nodos: si min.insync.replicas=2, acks = all y la lista ISR lo es, solo se deben sincronizar exitosamente 2 réplicas antes de enviar una respuesta exitosa al productor, o debería espere hasta que todas las réplicas estén sincronizadas ¿Enviar después del éxito? Debido a que min.insync.replicas=2 es solo un límite mínimo, si la cantidad de réplicas sincronizadas es menor que este valor de configuración, se generará una excepción y acks = all, debe asegurarse de que todas las réplicas en la lista ISR sean sincronizado antes de enviar una respuesta exitosa.
1) La confiabilidad de un sistema nunca puede ser determinada por una sola parte. La confiabilidad de los mensajes enviados por los productores de Kafka está determinada principalmente por la lista de réplicas de sincronización dinámica ISR del servidor Kafka, el número mínimo de réplicas de sincronización min.insync.replicas y el parámetro del productor ack=all.
El número mínimo de réplicas de sincronización del servidor Kafka es min.insync.replicas, que está determinado por el número de clústeres y nodos implementados y satisface el escenario bizantino general (más de la mitad de los nodos son suficientes) .
3) El número de réplicas del productor está determinado por el número de clústeres y nodos implementados, lo que satisface el escenario bizantino general (más de la mitad de los nodos son suficientes). Si se tratara de un solo libro, la discusión de este artículo no tendría sentido.
4) En el escenario de un solo nodo de Kafka, la lista de réplicas de sincronización dinámica ISR y el número mínimo de réplicas de sincronización min.insync.replicas del servidor Kafka son 1, y el número de réplicas de el productor es 1 (si es mayor que 1, se espera que falle). El efecto de ack=all es el mismo que el de ack=1.
5) En el escenario de 3 nodos de Kafka, la lista de réplicas de sincronización dinámica ISR del servidor Kafka es 3, el número mínimo de réplicas de sincronización min.insync.replicas es 2, el número de réplicas de productor es 2 y ack=all .
6) En el escenario de n nodos de número impar de Kafka, la lista de réplicas de sincronización dinámica ISR del servidor Kafka es n, el número mínimo de réplicas de sincronización min.insync.replicas es (n 1)/2 y el número de copias del productor es (n 1)/2, ack=all.
Análisis del mecanismo de confirmación del productor de Kafka
Parámetros de configuración del productor de Kafka proporcionados por el sitio web oficial de Kafka