Mecanismo de indexación en Kafka

En Kafka, cada archivo de segmento de registro corresponde a dos archivos de índice: el archivo de índice de compensación y el archivo de índice de marca de tiempo (hay otros archivos de índice, como los archivos de índice de registro de transacciones, que no enumeraré en detalle) , se utilizan principalmente para mejorar la eficiencia de la búsqueda de mensajes.

El archivo de índice de desplazamiento se utiliza para establecer una asignación entre el desplazamiento del correo electrónico y la dirección física para localizar rápidamente el archivo físico donde se encuentra el correo electrónico; el archivo de índice de marca de tiempo encuentra el desplazamiento según lo especificado; información de marca de tiempo.

El archivo de índice en Kafka utiliza un índice disperso para crear un índice de mensajes, lo que no garantiza que cada mensaje tenga una entrada de índice correspondiente en el archivo de índice.

Siempre que se escriba una cierta cantidad de mensajes (especificados por el parámetro del lado del agente log.index.interval.bytes, el valor predeterminado es 4096 (4 KB)), los archivos de índice de desplazamiento y marca de tiempo se escribirán cada uno. se incrementa en una entrada de índice de compensación y una entrada de índice de marca de tiempo, y el valor de log.index.interval.bytes aumentará o disminuirá, lo que en consecuencia disminuirá o aumentará la densidad de las entradas de índice.

Los índices dispersos utilizan MappedByteBuffer para asignar archivos de índice a la memoria para acelerar las consultas de índice.

Desplazamiento El desplazamiento en el archivo de índice aumenta monótonamente. Al consultar un desplazamiento específico, se utilizará una búsqueda binaria para localizar rápidamente el desplazamiento. Si el desplazamiento especificado no está en el archivo de índice, se devolverá el desplazamiento más grande y menor que el desplazamiento especificado.

Las marcas de tiempo en el archivo de índice de marcas de tiempo también aumentan de manera estrictamente monótona. Al consultar una marca de tiempo específica, la búsqueda binaria también se utiliza para encontrar el desplazamiento máximo que no es mayor que la marca de tiempo, y luego la ubicación del archivo físico correspondiente debe ubicarse nuevamente según el archivo de índice de desplazamiento.

Los índices dispersos son un compromiso entre el espacio en disco, el espacio de memoria y el tiempo de búsqueda.

Tome el archivo de índice de compensación como ejemplo para un análisis detallado. El formato de una entrada de índice de compensación es el siguiente.

Cada entrada de índice ocupa 8 bytes y se divide en dos partes:

(1) relativoOffset: relativoOffset: relativoOffset representa el desplazamiento del mensaje con respecto a baseOffset, y representa 4 bytes. el nombre del archivo de índice actual es el valor de baseOffset.

(2) posición: la dirección física, es decir, la ubicación física del mensaje en el archivo de segmento de registro, ocupa 4 bytes.

El desplazamiento del mensaje es de 8 bytes, que también se puede denominar desplazamiento absoluto.

El elemento de índice no utiliza directamente desplazamientos absolutos, sino que utiliza desplazamientos relativos que solo ocupan 4 bytes (relativeOffset = offset - baseOffset), lo que reduce el espacio ocupado por el archivo de índice.

Por ejemplo, si el desplazamiento base del segmento de registro es 32, el nombre del archivo es 000000000000000000032.log y el mensaje en el desplazamiento 35 tiene un desplazamiento relativo de 35-32=3 en el archivo de índice.

¿Qué debemos hacer si queremos encontrar el mensaje en el desplazamiento 23?

¿Qué pasa si queremos encontrar el mensaje en el desplazamiento 23? Primero, busque la entrada de índice más grande en el archivo de índice de desplazamiento que no sea mayor que 23, divídala en dos, es decir, [22, 656], y luego comience desde la posición física 656 en el archivo de segmento de registro y busque el desplazamiento en secuencia.

El anterior es el caso más sencillo.

Con referencia a la figura anterior, ¿qué sucede si desea encontrar el paquete con desplazamiento 268?

Lo primero que debe hacer es encontrar el segmento de registro con un desplazamiento base de 251, luego calcular el desplazamiento relativo relativoOffset = 268 - 251 = 17, y luego buscar en el archivo de índice correspondiente no mayor que 17 Entrada del índice y, finalmente, según la posición en la entrada del índice, busque el archivo de segmento de registro específico y comience a buscar el mensaje de destino.

Entonces, ¿cómo encontrar el segmento de registro con baseOffset de 251?

Utilizamos una estructura de tabla de salto en lugar de búsqueda secuencial.

Kafka utiliza un ConcurrentSkipListMap para cada objeto de registro para almacenar segmentos. El baseOffset de cada segmento es la clave, por lo que puede ubicar rápidamente el segmento donde se encuentra el mensaje según el desplazamiento especificado.

Para ubicar el mensaje en Kafka, primero busque el archivo de índice del segmento de registro correspondiente (baseOffset) de ConcurrentSkipListMap de acuerdo con el desplazamiento, luego lea el archivo de índice de desplazamiento y luego use el método de dicotomía en el offset Encuentre el archivo de índice más grande que no sea mayor que el desplazamiento - baseOffset z en el archivo de índice, luego lea el archivo de segmento de registro y busque el mensaje correspondiente a relativoOffset en el archivo de segmento de registro en orden.

Todo el proceso de consulta de mensajes a través de compensaciones en Kafka se puede simplificar de la siguiente manera:

En Kafka, el desplazamiento de un mensaje se puede comparar con la clave primaria en InnoDB, a través del offset Recupera el registro completo cuantitativamente y recupera el registro completo por clave principal.

Se recomienda simplificar todo el proceso de consulta del contenido de los datos por clave primaria en InnoDB como se muestra en la siguiente figura (parte inferior).

La forma en que se recuperan los mensajes a través de archivos de índice de marca de tiempo en Kafka se puede comparar con la forma en que se recuperan los mensajes a través de índices secundarios en InnoDB:

El primero busca compensaciones a través de marcas de tiempo, y el último El primero es encontrar la clave principal a través del índice, y el proceso de los dos últimos es el mismo que el de la declaración anterior.

En Kafka, ConcurrentSkipListMap se actualiza cuando se crea un nuevo archivo de índice en lugar de cada vez que se escriben datos, lo cual es básicamente insignificante.

Al leer del árbol B Al insertar, Al actualizar o eliminar datos, es necesario actualizar el índice. Cuando se insertan, actualizan o eliminan datos en el árbol B, es necesario actualizar el índice, lo que puede resultar en operaciones que consumen relativamente mucho tiempo, como "paginación", etc. La indexación de archivos en Kafka también es una operación de adición secuencial de archivos, que requiere mucho menos trabajo que en un árbol B.

En el análisis final, son los diferentes escenarios de aplicación los que determinan la frecuencia con la que MySQL necesita realizar operaciones CRUD. Este es también el trabajo principal de MySQL. Para admitir esto, es necesario utilizarlo. un árbol B con un mayor volumen de mantenimiento.

Los mensajes en Kafka generalmente se escriben en el disco en secuencia y luego se leen desde el disco en secuencia (sin profundizar en el caché de la página, etc.). Su trabajo principal es escribir y leer, y la carga de trabajo de. las consultas de recuperación son muy pequeñas

En otras palabras, las consultas de recuperación son solo una función auxiliar de Kafka y el costo de mantenerla no es alto. No es necesario gastar mucho dinero manteniendo índices avanzados para lograr esta funcionalidad.

Como se mencionó anteriormente, este enfoque en Kafka es un compromiso entre espacio en disco, espacio de memoria y tiempo de búsqueda.