Otra URL
El mensaje esta perdido
Mensaje perdido del productor
¿Cuándo se perderá el mensaje?
Escenario 1: el tamaño del mensaje supera el valor de message.max.bytes del Broker. En este momento, el Broker devolverá un error directamente;
Escenario 2: después de que el productor envía un mensaje, la red se interrumpe repentinamente, lo que hace que el mensaje no se envíe al corredor
Escenario 3: El formato del mensaje es incorrecto; (este escenario debe excluirse durante el desarrollo de la autocomprobación)
solución
Especifique el tamaño del mensaje (correspondencia: escenario 3)
El tamaño máximo de solicitudes del productor representa el valor máximo de un solo mensaje enviado por el productor, y también puede referirse al tamaño total de todos los mensajes en una sola solicitud. Este valor debe ser menor que message.max.bytes del Broker.
Enviar de forma asincrónica, proporcionar el método de devolución de llamada (correspondiente: escenario 2)
Conclusión : use la API con devolución de llamada para procesar cuando el envío falla (como almacenar en otros medios para una compensación posterior)
Detallado:
En producción, usaremos el envío asincrónico del productor de Kafka, con las siguientes dos API:
productor.send (msg) sin método de
devolución de llamada productor.send (msg, devolución de llamada) con método de devolución de llamada
Reintentar mensaje (correspondiente: escenario 2)
- Establezca el número de reintentos: reintentos // Valor de experiencia: 3.
- Establezca el intervalo de reintento: retry.backoff.ms // Valor de experiencia: 20000 El
valor predeterminado es 1000, que es 1 segundo.
Configure esta opción para que vuelva a intentarlo después de un período de tiempo determinado. En este momento, es posible que la red esté lista. De lo contrario, si el intervalo de reintentos es demasiado corto, la red no mejorará en poco tiempo y se desperdiciará el número de reintentos. Si
configura esta opción, la secuencia de mensajes cambiará. La forma de garantizar que el pedido se mantenga sin cambios: configure max.in.flight.requests.per.connection = 1 (Función: limitar el número de solicitudes que no responden que el cliente puede enviar en una sola conexión. Establecer en 1 para indicar que el kafka el corredor está respondiendo a las solicitudes Antes, el cliente ya no podía enviar solicitudes al mismo corredor).- Establezca el intervalo de reconexión: reconnect.backoff.ms // Valor de experiencia: 20000
Número de respuestas (correspondencia: escenario 2)
En conclusión
Establecer acks = all
Detalle
El parámetro acks tiene tres valores: 0, 1, -1 (todos).
acks es un parámetro de Producer, que representa su definición del mensaje "comprometido".
- 0: El productor considera que el mensaje se envió con éxito después de enviar el mensaje.
Puede causar pérdida de datos: la red está inactiva, el corredor no puede guardar el mensaje- 1: El productor envía el mensaje al servidor, y después de que la copia de réplica líder del servidor se escribe con éxito, regresa al productor para enviar el mensaje con éxito.
Puede causar pérdida de datos: es posible que los datos se escriban en la réplica del líder y luego se devuelva una respuesta exitosa al productor. Si hay un problema con el servidor donde se encuentra la réplica del líder en este momento y la réplica del seguidor no ha tenido tiempo de sincronizar los datos, se perderán.- all: después de que todas las réplicas se escriban correctamente, se devolverá una respuesta satisfactoria al productor.
Suponiendo que hay tres réplicas de la partición (una réplica de líder, dos réplicas de seguidor), entonces acks = -1 significa que el mensaje se escribe en la réplica de líder y las dos réplicas de seguidor sincronizan con éxito los datos de la réplica de líder y el servidor Solo entonces el productor enviará una respuesta exitosa al mensaje. Para asegurarse de que los datos no se pierdan, entonces el valor de acks se establece en -1, y también es necesario asegurarse de que haya más de una copia
Retraso de envío (correspondiente: escenario 2)
En conclusión
Establecer linger.ms. // Experiencia: 50. Valor predeterminado: 0
Detalle
Esta configuración puede retrasar el envío de mensajes del productor, reduciendo así la posibilidad de problemas de red hasta cierto punto.
Para obtener más información, consulte: https://kafka.apachecn.org/documentation.html
Mensaje perdido del corredor
¿Cuándo se perderá el mensaje?
Escenario 1: Si el corredor donde se encuentra la copia del líder cae repentinamente, entonces un líder debe ser reelegido de la copia del seguidor, pero si hay algunos datos del líder que no han sido sincronizados por la copia del seguidor, el mensaje será perdió.
Descripción: Kafka presenta un mecanismo de copia múltiple (réplica) para la partición (partición). Habrá un tipo llamado líder entre varias réplicas en una partición, y las otras réplicas se llamarán seguidores. El mensaje que enviamos se enviará a la réplica del líder, y luego la réplica del seguidor puede extraer el mensaje de la réplica del líder para sincronizarlo. Los productores y consumidores solo interactúan con la réplica del líder. Puede comprender que otras réplicas son solo copias de la réplica líder y su existencia es solo para garantizar la seguridad del almacenamiento de mensajes.
solución
Elegibilidad para la elección de líder
En conclusión
Establezca unclean.leader.election.enable en false
Detallado
Este parámetro controla la elegibilidad de la réplica del seguidor para ejecutar la réplica del líder después de que la réplica del líder tenga un problema.
Establecido en falso, lo que significa que si la réplica del seguidor está muy por detrás de la réplica del líder, no podrá participar en la elección.
Número de copias
En conclusión
Establezca replication.factor en un número mayor que 1 // Valor de experiencia: 3
Detallado
Este parámetro establece el número de copias de la partición. Si queremos asegurarnos de que no se pierdan datos, el número de copias debe establecerse en más de 1.
Número mínimo de copias
En conclusión
Establezca min.insync.replicas en un número mayor que 1, y debe ser menor que replication.factor
Detallado
El parámetro min.insync.replicas mayor que 1 debe usarse junto con el parámetro acks en el productor Cuando el productor acks = all, todas las copias del servidor se han escrito exitosamente antes de devolver una respuesta exitosa al productor.
min.insync.replicas es controlar cuántas réplicas se debe escribir un mensaje antes de que se considere "confirmado". Suponiendo que min.insync.replicas = 1, significa que solo puede haber una réplica. Esta réplica es la réplica del líder. En este momento, incluso si acks está configurado en todos, el mensaje en realidad solo se envía a la réplica del líder y una respuesta exitosa se devolverá más tarde.- min.insync.replicas es más pequeño que replication.factor
Para garantizar la alta disponibilidad de todo el servicio de Kafka, es necesario asegurarse de que replication.factor> min.insync.replicas. ¿Por qué? Si los dos son iguales, siempre que falle una copia, la partición completa no funcionará normalmente, lo cual es una violación obvia de la alta disponibilidad. Generalmente se recomienda establecer replication.factor = min.insync.replicas + 1.
Los consumidores pierden mensajes
¿Cuándo se perderá el mensaje?
Escenario 1 : envíe el desplazamiento primero y luego procese el mensaje. Cuando el procesamiento del mensaje falla, el mensaje se pierde.
Primero se procesa el mensaje y luego se envía el desplazamiento. Cuando el desplazamiento no se envía, el mensaje se repetirá. La repetición de mensajes solo necesita lidiar con la idempotencia, y la repetición de mensajes no es el tema central de este artículo.
solución
Envíe la compensación manualmente
En conclusión
Establezca enable.auto.commit en falso. Después de procesar el mensaje, envíelo manualmente. Hay varias formas de enviarlo:
- Envíe de forma asincrónica
consumer.commitAsync (), consumer.commitAsync (nuevo OffsetCommitCallBack ())- Envío sincrónico
consumer.commitSync ()Detallado
El envío síncrono continuará reintentando hasta que se realice correctamente, lo que requiere una respuesta del corredor, y el envío asíncrono puede mejorar el rendimiento.
Configuración de cero pérdida de mensajes
Si se logran todas las condiciones anteriores, se puede lograr una pérdida de mensaje cero.
Al mirar muchos blogs, una vez realizada la configuración anterior, no se pueden perder mensajes en la producción.
Las siguientes situaciones también pueden dar lugar a mensajes modificados, pero puede ignorarlo
Los datos de Kafka se escriben primero en la caché del sistema operativo. Si usamos el esquema de configuración anterior, los datos se escriben correctamente pero aún no en el disco, pero el clúster está apagado y los datos se perderán en este momento. Si está configurado para escribir en el disco inmediatamente, reducirá el rendimiento y, por lo general, no se configura así.
Mensaje duplicado
Otra URL
Escenarios de pérdida y duplicación de mensajes de Kafka y análisis de soluciones_blog de ZhangCheng-blog de CSDN
notas de kafka: Los productores entregan mensajes exactamente una vez (la idempotencia resuelve la entrega repetida de mensajes) -comunidad en la nube -Los
mensajes de Kafka en la nube de Huawei se perderán ¿Y se repetirán? ——Cómo realizar la transmisión precisa de Kafka una vez que la semántica es
extremadamente simple series-producción kafka-preguntas repetitivas_aprendidas, interrogadas, cuidadosamente pensadas, distinguidas y practicadas-blog de CSDN
Mensaje de productor duplicado
¿Cuándo se repetirá?
Escenario 1 : El mensaje enviado por el productor no recibe la respuesta de ruptura correcta, lo que hace que el productor vuelva a intentarlo.
Explicación detallada: después de que el productor envía un mensaje, después de que el corredor se coloca en el mercado, debido a la red y otras razones, el remitente recibe una respuesta de falla de envío o interrupción de la red, y luego el productor recibe un mensaje de reintento de excepción recuperable, lo que causa el mensaje que se repetirá.
solución
Comienza la idempotencia de Kafka
En conclusión
enable.idempotence = true // En este momento, acks = all
acks = all retries
> 1 se activará de forma predeterminadaDetallado
Después de la versión Kafka 0.11.0.0, se lanzó oficialmente el productor idempotente para apoyar la idempotencia de los productores.
Cada productor tiene una identificación única, y cada vez que el productor envía un dato, traerá una secuencia. Cuando el mensaje se coloca en el disco, la secuencia se incrementa en 1. Simplemente juzgue si la secuencia del mensaje actual es mayor que la secuencia máxima actual, mayor que eso significa que los datos no se han colocado en el pedido y se pueden consumir normalmente; no mayor que eso significa que se ha realizado el pedido, y el mensaje retransmitido en este momento será rechazado por el servidor para evitarlo, el mensaje se repite.
limitación
Durante la inicialización, Kafka generará un ID único para el productor llamado Producer ID o PID. El PID y el número de serie se incluyen con el mensaje y luego se envían al corredor. Dado que el número de secuencia comienza desde cero y aumenta monótonamente, el corredor solo aceptará el mensaje cuando el número de secuencia del mensaje sea exactamente uno mayor que el último mensaje enviado en el par PID / TopicPartition. Si este no es el caso, el corredor asume que el productor reenvía el mensaje.
Mensaje de consumidor duplicado
¿Cuándo se repetirá?
Escenario 1 : El consumidor utiliza el modo de compensación de envío automático. Cuando el consumidor recibe el mensaje y no lo ha consumido, envía la compensación y comienza a consumir el mensaje. Como resultado, la red es anormal, el envío de compensación falla y el mensaje de consumo es exitoso.
Escenario 2 : el consumidor utiliza el modo de envío de compensación manual. Una vez que el consumidor consume el mensaje, cuelga y aún no se ha enviado la compensación.
Solucion 1
Procesamiento en código comercial.
En conclusión
Establecer en modo de envío manual; el juicio manual es idempotente
Detallado
En realidad, existen dos métodos para la idempotencia:
(1) Almacenar la clave única en un medio de terceros. Cuando desee manipular datos, primero determine si el medio de terceros (base de datos o caché) tiene esta clave única.(2) Almacene el número de versión (desplazamiento) en los datos y luego use este número de versión como un bloqueo optimista cuando desee manipular los datos, y la operación solo se puede realizar cuando el número de versión es mayor que el original.
Solucion 2
Utilice el motor de procesamiento de flujo de Kafka: Kafka Streams (este método se usa raramente)
En conclusión
Establezca processing.guarantee = exact_once, puede lograr fácilmente exactamente una vez.