Durante la entrevista, descubrí que a muchos entrevistadores les gusta especialmente hacer preguntas relacionadas con Kafka. No es difícil entender quién hace de Kafka el único rey de las colas de mensajes en el campo del big data , con un rendimiento de una sola máquina de 100.000 y un retraso de milisegundos. ¿Quién no puede amar este tipo de cola de mensajes distribuidos de forma natural?
En una entrevista reciente, un entrevistador vio que Kafka estaba escrito en el artículo del currículum, por lo que le preguntó directamente a Kafka y básicamente no hizo otras preguntas. Echemos un vistazo a las ocho preguntas consecutivas de Kafka del entrevistador:
(Las siguientes respuestas se compilan después de la entrevista, y solo alrededor de un tercio de las respuestas se respondieron durante la entrevista real)
1. ¿Por qué utilizar Kafka?
Almacenamiento en búfer y recorte de picos: cuando hay una ráfaga de datos ascendentes, es posible que el flujo descendente no pueda manejarlos o que no haya suficientes máquinas en el flujo descendente para garantizar la redundancia. Kafka puede actuar como un búfer en el medio, almacenando temporalmente mensajes en Kafka y descendente El servicio se puede procesar lentamente a su propio ritmo.
Desacoplamiento y escalabilidad: al comienzo del proyecto, no se pueden determinar requisitos específicos. La cola de mensajes se puede utilizar como capa de interfaz para desacoplar procesos comerciales importantes. Solo necesita cumplir con las convenciones y puede obtener capacidades de expansión para la programación de datos.
Redundancia: se puede utilizar un enfoque de uno a varios. Un productor publica un mensaje, que puede ser consumido por varios servicios de temas de suscripción para su uso por varias empresas no relacionadas.
Robustez: la cola de mensajes puede acumular solicitudes, por lo que incluso si el negocio de consumo muere en poco tiempo, no afectará el funcionamiento normal del negocio principal.
Comunicación asincrónica: en muchos casos, los usuarios no quieren ni necesitan procesar mensajes de inmediato. La cola de mensajes proporciona un mecanismo de procesamiento asincrónico que permite a los usuarios poner un mensaje en la cola, pero no lo procesa inmediatamente. Coloque todos los mensajes que desee en la cola y luego procéselos cuando sea necesario.
2. ¿Cómo consumir los mensajes consumidos por Kafka?
El desplazamiento de los mensajes de consumo de Kafka se define en zookeeper. Si desea consumir mensajes de Kafka repetidamente, puede registrar los puntos de control de desplazamiento (n) en redis. Cuando desee consumir mensajes repetidamente, lea los puntos de control en redis. Restablezca la compensación del cuidador del zoológico, para que pueda lograr el propósito de consumo repetido de mensajes
3. ¿Se almacenan los datos de Kafka en el disco o en la memoria, por qué la velocidad es más rápida?
Kafka usa almacenamiento en disco.
La velocidad es rápida porque:
- Escritura secuencial: debido a que el disco duro es una estructura mecánica, cada lectura y escritura se direccionará -> escritura, en la que el direccionamiento es una "acción mecánica", requiere mucho tiempo. Por tanto, los discos duros "odian" la E / S aleatoria y prefieren la E / S secuencial. Para aumentar la velocidad de lectura y escritura de discos duros, Kafka utiliza E / S secuenciales.
- Archivos asignados en memoria: un sistema operativo de 64 bits generalmente puede representar archivos de datos de 20 G. Su principio de funcionamiento es utilizar directamente la página del sistema operativo para implementar la asignación directa de archivos a la memoria física. Una vez finalizada la asignación, sus operaciones en la memoria física se sincronizarán con el disco duro.
- Diseño de almacenamiento de archivos eficiente de Kafka: Kafka divide un archivo de partición grande en un tema en varios segmentos de archivos pequeños. A través de varios segmentos de archivos pequeños, es fácil borrar o eliminar periódicamente los archivos que se han consumido y reducir el uso del disco. La información del índice puede localizar rápidamente el
mensaje y determinar el tamaño de la respuesta. Al mapear todos los metadatos de índice a la memoria (archivo mapeado en memoria),
se pueden evitar las operaciones del disco de E / S del archivo de segmento. A través del almacenamiento escaso de archivos de índice, el espacio ocupado por los metadatos del archivo de índice se puede reducir considerablemente.
Nota:
- Uno de los métodos de Kafka para resolver la eficiencia de las consultas es segmentar archivos de datos. Por ejemplo, hay 100 mensajes y su desplazamiento es de 0 a 99. Suponga que el archivo de datos está dividido en 5 segmentos, el primer segmento es 0-19, el segundo segmento es 20-39, y así sucesivamente, cada segmento se coloca en un archivo de datos separado y el archivo de datos recibe el nombre del pequeño desplazamiento en el segmento. De esta manera, al buscar un
mensaje con un desplazamiento especificado , la búsqueda binaria se puede utilizar para localizar en qué segmento se encuentra el mensaje.- La construcción de un índice para la segmentación del archivo de datos del archivo de datos hace posible encontrar el Mensaje correspondiente al desplazamiento en un archivo de datos más pequeño, pero esto aún requiere un escaneo secuencial para encontrar el Mensaje correspondiente al desplazamiento.
Para mejorar aún más la eficiencia de la búsqueda, Kafka crea un archivo de índice para cada archivo de datos segmentado. El nombre del archivo es el mismo que el nombre del archivo de datos, pero la extensión del archivo es .index.
4. ¿Cómo no se pueden perder los datos de Kafka?
En tres puntos, uno es el lado del productor, el lado del consumidor y el lado del corredor.
- Sin pérdida de datos del productor
Mecanismo de confirmación de Kafka: cuando Kafka envía datos, habrá un mecanismo de retroalimentación de confirmación cada vez que se envíe un mensaje para garantizar que el mensaje se pueda recibir normalmente, y el estado es 0, 1, -1.
Si está en modo síncrono:
ack se establece en 0, lo cual es muy arriesgado. Generalmente, no se recomienda establecerlo en 0. Incluso si se establece en 1, los datos se perderán a medida que el líder descienda. Entonces, si desea asegurarse estrictamente de que los datos finales de producción no se pierdan, puede configurarlo en -1.
Si es modo asíncrono:
también se tendrá en cuenta el estado de ack. Además, hay un búfer en modo asíncrono. Los datos de control se envían a través del búfer. Hay dos valores para el control, el umbral de tiempo y el número de mensajes. Si el búfer está lleno y los datos no se han enviado, existe una opción para configurar si se borra el búfer inmediatamente. Se puede establecer en -1 para bloquear permanentemente, lo que significa que ya no se producen datos. En modo asincrónico, incluso si se establece en -1. También es posible que los datos de la operación se pierdan debido a operaciones no científicas del programador, como kill -9, pero esta es una excepción especial.
Nota:
ack = 0: El productor no espera la confirmación de la finalización de la sincronización del intermediario y continúa enviando el siguiente mensaje (lote).
ack = 1 (predeterminado): el productor espera a que el líder reciba correctamente los datos y obtenga la confirmación antes de enviar el siguiente mensaje.
ack = -1: El productor enviará el siguiente dato solo después de recibir la confirmación del seguidor.
- Sin pérdida de datos del consumidor
El compromiso de compensación se utiliza para garantizar que los datos no se pierdan. Kafka registra el valor de compensación de cada consumo. Cuando continúe consumiendo la próxima vez, seguirá consumiendo con la última compensación.
La información de compensación se guarda en zookeeper antes de la versión 0.8 de kafka y se guarda en el tema después de la versión 0.8.Incluso si el consumidor cuelga durante la operación, el valor de compensación se encontrará al reiniciar y se encontrará el mensaje de consumo anterior. Ubicación, luego consumo, porque cuando se escribe la información de compensación, no todos los mensajes se escriben una vez finalizado el consumo, por lo que esta situación puede provocar un consumo repetido, pero el mensaje no se perderá.
La única excepción es cuando configuramos
KafkaSpoutConfig.bulider.setGroupid en el mismo groupid cuando configuramos KafkaSpoutConfig.bulider.setGroupid en dos grupos de consumidores que originalmente realizaban funciones diferentes en el programa . Esta situación hará que los dos grupos compartan los mismos datos. El grupo A consumirá mensajes en la partición 1 y la partición 2, y el grupo B consumirá mensajes en la partición 3. De esta forma, los mensajes consumidos por cada grupo se perderán y quedarán incompletos. Para garantizar que cada grupo tenga una parte exclusiva de los datos del mensaje, el ID de grupo no debe repetirse.
- Los datos de los corredores en el clúster de Kafka no se pierden
Generalmente establecemos el número de réplicas (réplicas) para cada partición en el broker.Cuando el productor lo escribe, primero escríbalo en el líder según la estrategia de distribución (partición por partición, clave por clave, sin sondeo). , El seguidor (réplica) sincroniza los datos con el líder, de modo que con una copia de seguridad, también puede garantizar que los datos del mensaje no se pierdan.
5. ¿Por qué elegir kafka para la recopilación de datos?
La capa de adquisición puede utilizar principalmente Flume, Kafka y otras tecnologías.
Flume: Flume es un método de flujo de tubería, que proporciona muchas implementaciones predeterminadas, lo que permite a los usuarios implementar a través de parámetros y extender la API.
Kafka: Kafka es una cola de mensajes distribuidos persistentes. Kafka es un sistema muy versátil. Puede tener muchos productores y muchos consumidores compartiendo múltiples temas.
Por el contrario, Flume es una herramienta especial diseñada para enviar datos a HDFS y HBase. Tiene optimizaciones especiales para HDFS e integra las funciones de seguridad de Hadoop.
Por lo tanto, Cloudera recomienda usar Kafka si los datos son consumidos por varios sistemas; si los datos están diseñados para ser usados por Hadoop, use Flume.
6. ¿Reiniciar Kafka provocará la pérdida de datos?
- Kafka escribe datos en el disco y, por lo general, los datos no se perderán.
- Pero en el proceso de reinicio de Kafka, si hay consumidores consumiendo mensajes, si Kafka no tiene tiempo para enviar la compensación, puede causar datos inexactos (pérdida o consumo repetido).
7. ¿Cómo resolver si Kafka está caído?
- Primero considere si el negocio se ve afectado
Kafka está inactivo. La primera pregunta que debemos considerar es si el servicio proporcionado se ve afectado por la máquina inactiva. Si el servicio se proporciona, si se implementa el mecanismo de tolerancia a desastres del clúster, entonces no hay necesidad de preocuparse por esto. .
- Solución de problemas y recuperación de nodos
Para restaurar los nodos del clúster, el paso principal es verificar la causa del tiempo de inactividad del nodo a través del análisis de registros, para resolver el problema y restaurar el nodo nuevamente.
8. ¿Por qué Kafka no admite la separación de lectura y escritura?
En Kafka, las operaciones de los productores que escriben mensajes y los consumidores que leen mensajes interactúan con la copia líder, logrando así un modelo de producción y consumo de escritura y lectura maestra .
Kafka no admite la lectura maestro-escritura-esclavo , porque la lectura maestro-escritura-esclavo tiene dos desventajas obvias:
Problema de consistencia de datos: habrá una ventana de tiempo de retardo para los datos del nodo maestro al nodo esclavo, esta ventana de tiempo causará la inconsistencia de datos entre los nodos maestro y esclavo. En un momento determinado, el valor de los datos A tanto en el nodo maestro como en el esclavo es X, y luego el valor de A en el nodo maestro se modifica a Y, luego, antes de notificar el cambio al nodo esclavo, la aplicación lee los datos A en el nodo esclavo. El valor de no es la última Y, lo que crea un problema de inconsistencia de datos.
Problema de retardo: para componentes como Redis, el proceso de escritura de datos desde el nodo maestro hasta la sincronización con el nodo esclavo debe pasar por las etapas de red → memoria del nodo maestro → red → memoria del nodo esclavo. Todo el proceso llevará una cierta cantidad de tiempo. En Kafka, la sincronización maestro-esclavo consume más tiempo que Redis. Necesita pasar por las etapas de red → memoria del nodo maestro → disco del nodo maestro → red → memoria del nodo esclavo → disco del nodo esclavo. Para aplicaciones sensibles al retardo, la función de escritura maestra y lectura esclava no es muy adecuada.
Y las ventajas de la escritura principal y la lectura principal de kafka son muchas:
- Puede simplificar la lógica de implementación del código y reducir la posibilidad de errores;
- La granularidad de la carga se refina y se distribuye uniformemente, en comparación con la escritura maestra y la lectura esclava, no solo el rendimiento de la carga es mejor, sino que también el usuario es controlable;
- No hay efecto de retardo;
- Cuando la copia es estable, no habrá incoherencia de datos.