Kafka al final va a perder los datos (pérdida de datos)? Diciendo línea mucho, antes de responder a esta pregunta, tenemos que tener claro "límites de responsabilidad." La llamada responsabilidad es determinar los límites del mensaje en el proceso completo de producción y consumo es que es responsable de asegurarse de que no se pierde. Así que incluso si realmente se pierde un mensaje, puede ser claramente la responsabilidad del organismo, y llevar a cabo mejoras y ajustes.
Delineado sobre la responsabilidad, de hecho, el funcionario se le ha dado una respuesta muy clara:
Una vez que se cometa un mensaje publicado no se perderá el tiempo que un corredor que replica la partición a la que este mensaje fue escrito restos "vivo".
Si entendemos plenamente esta frase, entonces la pregunta "si se pierde el mensaje," el yo puede ser resuelto. Esta frase tiene dos puntos clave:
-
comprometido: Kafka hace solamente la entrega de garantía (garantía de entrega) se ha presentado al mensaje, el mensaje no se ha enviado correctamente Kafka no tiene ningún compromiso con su
-
viva: Siempre y cuando no es un artículo de noticias para salvar el corredor sigue vivo (vivo) el mensaje no se pierde
Kafka definir la forma de un corredor está vivo (vivo) que? Muy simple, pero también dos condiciones:
-
proceso de nodo debe sobrevivir, y ha mantenido una sesión con el cuidador del zoológico
-
Si el nodo es un seguidor, que es el número de nodos con el líder de la diferencia entre el mensaje no puede ser demasiado grande, que no se queda atrás nodo líder horario. Si de acuerdo con los términos de Kafka, es este nodo debe ser un (réplica en sincronización, es decir, sincronizada con el nodo líder réplica) seguidor ISR
Por supuesto, yo personalmente tengo ninguna duda de que, debido a que algunos de la configuración por defecto y fallo de funcionamiento y así todavía no han encontrado la causa para asegurar que el anterior Kafka no se tradujo en un cien por ciento se puede lograr, pero en la mayoría de los casos por la configuración de este artículo es para ayudarle a hacer ninguna noticia pérdida.
bien, Siria más preámbulos, directamente en la configuración. La siguiente lista de parámetros y las mejores prácticas pueden garantizar mejor los datos persistentes (por supuesto, disyuntiva, a expensas de rendimiento).
-
block.on.buffer.full = true
-
acks = all
-
reintentos = MAX_VALUE
-
max.in.flight.requests.per.connection = 1
-
使用 KafkaProducer.send (registro, devolución de llamada)
-
Si no hay mensaje está destinado únicamente a ser perdido, con el uso del método de envío de devolución de llamada, y si no el trastorno, sino también para asegurar problema, entonces el productor debe ser cerrada inmediatamente en caso de lógica de falta de devolución de llamada: close (0)
-
unclean.leader.election.enable = false
-
replication.factor = 3
-
min.insync.replicas = 2
-
replication.factor> min.insync.replicas
-
enable.auto.commit = false
-
Presentar el desplazamiento manual, el desplazamiento a continuación, presentó después de la finalización del procesamiento de mensajes
Así que, ¿por qué se perderán los datos:
1. Productor 端
En este artículo se analiza el productor después de la versión 0.9 Kafka - Kafka0.9 reemplazado oficialmente la versión antigua del productor Scala usando productor de la versión de Java.
La nueva versión utiliza un mecanismo de entrega asíncrona por defecto, así KafkaProducer.send acaba de poner el mensaje en una memoria intermedia (es decir RecordAccumulator, esencialmente usando la cola para registro de la memoria caché), mientras que el fondo del remitente IO hilo continúa barriendo la zona de amortiguación, la encapsulación de mensajes para satisfacer las condiciones de un lote y luego se transmite. Obviamente, este proceso tendrá una ventana de pérdida de datos: Si el proceso de IO antes de enviar al cliente final colgó, los datos acumulados en el acumulador TIENE se pueden perder. Pero está claro que esto no es Kafka hace dentro de los límites de la responsabilidad de garantizar que, después de todo, el mensaje no se ha enviado correctamente, que aún no ha sido tomada por Kafka. Sin embargo, algunos parámetros en la lista anterior todavía puede ayudar a evitar la pérdida de datos en este caso.
Otro problema es el Productor revueltos problema mensaje. Supongamos que el código de cliente ejecutar secuencialmente los siguientes dos declaraciones mensaje enviado a la misma partición
producer.send (record1); producer.send (RECORD2);
En este momento, si por alguna razón (por ejemplo, la fluctuación transitoria de red) resultados no RECORD1 sido enviado con éxito, mientras que Kafka y mecanismo de reintento y configurado mayor max.in.flight.requests.per.connection de 1 (el valor predeterminado es 5, originalmente después de mayor que 1), entonces el reintento RECORD1 éxito, record1 en la partición justo después RECORD2, resultando en mensaje codificado. Mucho más fuertes con ciertos requisitos para garantizar que el orden de las escenas no está permitido para esta situación.
Teniendo en cuenta estas dos preguntas productor, y cómo deberíamos evitarlo? ? Para obtener información problema de pérdida, es un programa fácil de pensar es la siguiente: Dado que los datos de transmisión asíncrona se puede perder, he cambiado de transmisión síncrona siempre puede ser correcto? De esta manera:
producer.send (registro) .get ();
Que así sea, pero el rendimiento será pobre, no se recomienda para dicho uso. Por lo tanto resume deliberadamente una lista de configuración. Personalmente creo que la lista de configuración debería estar en mejores condiciones para eludir el extremo productor a la pérdida de datos suceda :( presente explicar, una gran cantidad de la configuración del software de toma de decisiones son disyuntiva, la siguiente configuración no es una excepción: la aplicación de estas configuraciones, es posible que descubra su productor / consumidor rendimiento disminuirá, esto es normal, ya que a cambio de una mayor seguridad de los datos)
-
block.on.buffer.full = true parámetro 0.9.0.0 Aunque esto ha sido marcado como "obsoleta", pero en vista de su significado muy intuitiva, por lo que aquí se establece explícitamente en verdad, por lo que el productor tendrá que esperar hasta que el buffer que esté disponible. Si el productor o el agotamiento de la producción demasiado rápido de la zona de amortiguamiento, el productor se producirá una excepción
-
acks = todo bien entendida, y tenemos que responder a todos los seguidores son considerados envío de mensajes con éxito, que está "comprometida"
-
reintentos = MAX infinitas reintentos, hasta que te das cuenta hay un problema
-
max.in.flight.requests.per.connection = número de no restringir-respuesta a una petición del cliente puede ser transmitida a través de una sola conexión. Este valor está representado por un cliente intermediario kafka conjunto ya no puede el mismo corredor transmite una solicitud ante la petición de respuesta.
-
Uso KafkaProducer.send (registro, devolución de llamada) en lugar enviar (registro) método de devolución de personalizar el procesamiento de mensajes falla en la transmisión lógica
-
lógica Preferiblemente devolución de llamada explícita cerca producer.close (0) Nota: Este parámetro se proporciona para evitar el mensaje codificado
-
elección del líder unclean.leader.election.enable = false cerrado impuro, que no permite que no copia el ISR es elegido como el líder, con el fin de evitar la pérdida de datos
-
replication.factor> = 3 esto es totalmente una recomendación personal, se hace referencia a Hadoop y tres políticas de copia de seguridad de la industria de ancho
-
min.insync.replicas> 1 noticias al menos se pueda grabar en tantas copias para tener éxito, sino también mejorar un parámetro de datos persistentes. Utilizado conjuntamente con acks
-
Garantizar replication.factor> min.insync.replicas si los dos son iguales, y colgaron cuando una copia de la partición no funcionará correctamente. Por lo general se proporciona a replication.factor = min.insync.replicas + 1
