Cómo resuelve Kafka el problema de la pérdida de mensajes

En toda la arquitectura de Kafka se puede concluir que el mensaje tiene tres procesos de entrega:

1. El lado del productor envía un mensaje al lado del corredor
2. Broker procesa mensajes y persiste datos
3. El Consumidor extrae y consume mensajes del Broker

La pérdida de datos puede ocurrir en cada uno de los tres pasos anteriores, entonces, ¿bajo qué circunstancias puede Kafka garantizar que los mensajes no se pierdan?

Lado del productor perdido

Para mejorar la eficiencia de envío y reducir las operaciones de IO en el lado del Productor, se envían varias solicitudes de forma asíncrona al enviar un mensaje, por lo que la pérdida de mensajes en el lado del Productor es mayor porque el mensaje no se envía al lado del Broker en absoluto.

Existen las siguientes razones por las que el Productor no envía el mensaje:

• Motivo de la red: debido a la fluctuación de la red, los datos no se envían al lado del corredor
• Motivo de los datos: el cuerpo del mensaje es demasiado grande para ser aceptado por el corredor, lo que hace que el corredor rechace el mensaje

solución

La pérdida de datos en el lado del Productor se debe a que se envía de manera asíncrona, por lo que si usa el método de envío y grabación en este momento, es decir, la llamada a Producer.send(msg) regresará de inmediato. devolución de llamada, el Broker puede fallar por razones de red.El mensaje no se recibe, se pierde en este momento.

Por lo tanto, el problema de pérdida de mensajes en el lado del Productor se puede resolver desde los siguientes aspectos:

• Use un método con una función de notificación de devolución de llamada para enviar un mensaje
• mecanismo de confirmación ACK
• número de reintentos

El Productor confirma si el mensaje se produce con éxito a través de la configuración de ACK, y los parámetros de configuración son los siguientes:

• 0: dado que la transmisión se considera exitosa después de la transmisión, si se produce fluctuación de la red en este momento, se producirá una pérdida de datos
• 1: El mensaje se envía a la partición líder y se recibe correctamente, lo que significa que el envío se realizó correctamente. Siempre que la partición líder no cuelgue, se puede garantizar que los datos no se perderán. Sin embargo, si la partición líder cuelga , la partición del seguidor aún no ha sincronizado datos y no tiene ACK. perderá datos
• -1 o todos: el envío del mensaje debe esperar a que la partición Líder y todas las particiones Seguidor en el ISR confirmen la recepción del mensaje antes de que el mensaje se envíe con éxito. La confiabilidad es la más alta, pero no hay garantía de que no se perderán datos Por ejemplo: cuando solo hay la partición Leader en el ISR, tal Se convierte en el caso de acks = 1

Lado del corredor perdido

Después de que el Broker reciba los datos, persistirá el mensaje en el almacenamiento del disco.Para mejorar el rendimiento y el rendimiento, adopta la estrategia de vaciado por lotes asíncrono, es decir, vaciando el disco de acuerdo con una cierta cantidad de mensajes. y tiempo de intervalo.

En primer lugar, los datos se almacenarán en PageCache. En cuanto a cuándo vaciar los datos en el caché, lo determina el sistema operativo de acuerdo con su propia política o llamando al comando fsync para forzar el vaciado del disco. Si el Broker falla antes de sincronizarse con la partición del Seguidor y se elige una nueva partición del Líder, los datos del mensaje atrasado se perderán.

Dado que el almacenamiento de mensajes en el lado del intermediario se vacía en lotes de forma asíncrona, existe la posibilidad de pérdida de datos. Dado que Kafka no proporciona una forma de sincronizar discos, es probable que un solo bróker pierda datos.

Kafka ha podido garantizar que los datos no se pierdan al máximo a través del mecanismo de múltiples particiones y múltiples copias.Si los datos se escribieron en PageCache pero no tuvieron tiempo de vaciarlos en el disco, si el El corredor donde se encuentra cuelga repentinamente o tiene un corte de energía, aún ocurrirán casos extremos que causan pérdida de datos.

solución

El motivo de la pérdida de mensajes en el lado del corredor es que a través de la estrategia de vaciado por lotes asíncrono, los datos se almacenan primero en PageCache y luego se vacían de forma asíncrona.

Por lo tanto, Kafka usa múltiples particiones y múltiples copias para garantizar que los datos no se pierdan en la mayor medida posible. Puede ser garantizado por los siguientes parámetros:

• unclean.leader.election.enable: este parámetro indica qué seguidores son elegibles para ser elegidos como líder. Si los datos de un seguidor están muy por detrás del líder, una vez que se elija como el nuevo líder, los datos se perderán, por lo que necesitamos Establecerlo en falso para evitar que esto suceda.
• replication.factor: Este parámetro indica el número de réplicas de partición. Se recomienda configurar replication.factor >=3, de modo que si la copia del líder falla, la copia del seguidor se elegirá como la nueva copia del líder para continuar brindando servicios.
• min.insync.replicas: este parámetro indica cuántas copias del mensaje se deben escribir con éxito en el ISR para que se considere "confirmado". Se recomienda configurar min.insync.replicas > 1 para mejorar la persistencia del mensaje y garantizar que los datos no se pierden.

Además, debe asegurarse de que replication.factor > min.insync.replicas, si son iguales, siempre que una réplica cuelgue, la partición completa no funcionará correctamente, por lo que se recomienda configurarla como: replicación. factor = min.insync.replicas +1, Maximizar la disponibilidad del sistema.

Lado del consumidor perdido

El proceso de consumo de mensajes se divide principalmente en dos etapas:

• Extraer datos de Broker
• Procesar el mensaje y enviar el registro de compensación

El consumidor debe enviar Offset después de extraer el mensaje, por lo que es posible que se pierdan datos aquí. Las causas de la pérdida son las siguientes:

• Posibles formas de enviar compensaciones automáticamente
• Envíe la Compensación primero después de extraer el mensaje y luego procese el mensaje. Si hay un tiempo de inactividad anormal al procesar el mensaje en este momento, dado que la Compensación ya se ha enviado, después de que el Consumidor reinicie, reanudará el consumo desde la siguiente posición de la Compensación enviada anteriormente. El mensaje procesado no se volverá a procesar y el mensaje se perderá para el Consumidor.
• Después de extraer el mensaje, primero se procesa el mensaje y se envía la compensación. Si se produce un tiempo de inactividad anormal antes del envío en este momento, porque la compensación no se ha enviado correctamente, el mensaje se volverá a extraer de la última compensación. después de que se reinicie el siguiente Consumidor En el caso de pérdida de mensaje, pero habrá consumo repetido, aquí solo el propio negocio puede garantizar la idempotencia.

solución

La pérdida de mensajes en el lado del consumidor se produce al enviar la compensación después de extraer el mensaje. Por lo tanto, para no perder datos, la forma correcta es: extraer datos, procesar la lógica comercial y enviar información de desplazamiento de compensación de consumo.

Al mismo tiempo, también es necesario establecer el parámetro enable.auto.commit = false y utilizar el método de envío manual del desplazamiento. Además, en el caso de mensajes de consumo repetido, el propio negocio garantiza la idempotencia, asegurando que solo un consumo exitoso es suficiente.