Archivo de índice RocketMQ

Recientemente, se completó la serie rocketmq, en primer lugar para poder aprender más y también para cambiar de trabajo a fin de año. Creo que todos han visto esta imagen al ver el documento de github de rocket mq:

Nos dice que hay dos formas de encontrar mensajes en el registro de confirmación de rocket mq, una es a través de ConsumerQueue y la otra es La primera es mediante clave (también puedes agregar un rango de tiempo).

Encontrar mensajes en ConsumerQueue es más fácil porque cada parte de ConsumerQueue es fija y cada parte consta de [compensación de CommitLog, tamaño, etiqueta de mensaje HashCode], por lo que si conocemos el desplazamiento de CommitLog en relación con el inicio dirección, sabemos dónde encontrar el mensaje.

Si tenemos el desplazamiento de CommitLog relativo a la dirección inicial, sabemos dónde buscar el mensaje (desplazamiento de baseOffSet CommitLog) y, combinado con el tamaño, podemos leer el mensaje completo.

Sin embargo, la descripción del documento oficial sobre cómo el índice encuentra mensajes es algo vaga; el documento solo menciona cómo construir una tabla hash basada en la clave, pero no explica cómo construirla. Por eso, hoy lo explicaremos basándonos en el código fuente y los diagramas oficiales.

IndexFile En primer lugar, es un archivo completo de tamaño fijo, que consta de encabezado, tabla de ranuras y lista vinculada de índice, que coexisten en términos de organización de archivos. Con respecto al área de la lista vinculada de índice, es donde realmente se almacena el índice, mientras que la tabla de ranuras es la tabla (ranura) donde se almacena el HashMap. Al ver esto, no podemos evitar preguntarnos, ¿cómo está organizado HashMap?

Antes de explicar, hablemos de la estructura de estas partes de IndexFile. El encabezado ocupa 40 Bytes

Tabla de ranuras Cada ranura ocupa 4 Bytes, un total de 500w, ***ocupa 4 * 500w Byte. slot pone un valor, que es la posición del último nodo en el slot del mapa hash actual (solo una imagen de la posición del nodo en el mapa hash). posición del nodo (solo una imagen de la posición, no en realidad una dirección, se calcula, el índice almacenado real es el último y el orden entre todos los índices es el primero).

Cada lista vinculada de índice ocupa 20 bytes, *** un total de 2000 bytes, *** ocupa 20 * 2000 bytes.

El valor almacenado en cada área de índice es:

El código fuente de putkey es:

El valor de encontrar el mensaje según el valor clave o más el intervalo de tiempo es:

Supongamos que nuestro IndexFile inicial se ve así:

Luego insertamos 2 claves en él y se ve así:

Supongamos que después de insertar la tercera clave, coincide con la conflicto de posición 2, entonces el tercer índice debe registrar el valor del segundo espacio, luego escribir después del segundo espacio y cambiar el valor del segundo espacio a 2:

Luego, cuando encontramos Para el tercero clave, primero encontramos la posición de la tercera clave, y luego encontramos que el código hash es el mismo, entonces lo agregamos, luego sacamos el valor de la ranura y calculamos la posición de la clave anterior, es decir:

Luego, cuando buscamos la tercera clave, primero encontramos la posición de la tercera clave y luego encontramos que el código hash es el mismo, así que lo agregamos, luego sacamos el valor de la ranura y calculamos la posición; de la clave anterior, es decir:

Luego, cuando buscamos la tercera clave, primero encontramos la ubicación de la tercera clave y luego encontramos que el hashCode es el mismo, entonces lo agregamos. Es decir, luego saque la posición de slotValue y encuentre que el valor es 0, es decir, no hay ningún índice al frente, y luego regrese directamente.

En resumen, un archivo de índice imita la implementación de una tabla hash y utiliza una lista vinculada para evitar colisiones hash. Sin embargo, la lista vinculada es lógica, en realidad es así.

Piensa más y compara más. Además, la prueba individual del proyecto es muy importante. Si no puede entenderlo, puede ejecutar la prueba individual.