El mecanismo de almacenamiento de mensajes de Pulsar y el principio del mecanismo GC de Bookie

Este artículo es parte de la serie de tecnología Pulsar y resume brevemente el mecanismo de limpieza del almacenamiento de mensajes de Pulsar y los archivos de almacenamiento de BookKeeper. BookKeeper puede entenderse como un sistema de almacenamiento NoSQL que utiliza RocksDB de forma predeterminada para almacenar datos de índice.

Los mensajes de Pulsar se almacenan en BookKeeper, un sistema de cliente pesado donde la parte del cliente se llama BookKeeper y cada nodo de almacenamiento en el clúster del lado del servidor se llama bookie. El agente del sistema Pulsar actúa como cliente del sistema de almacenamiento BookKeeper y utiliza el cliente proporcionado por BookKeeper para limpiar archivos. El agente del sistema Pulsar actúa como cliente del sistema de almacenamiento BookKeeper y almacena los mensajes Pulsar en el clúster Bookies a través del SDK del cliente proporcionado por BookKeeper.

Cada partición de un tema en Pulsar (los temas no particionados pueden entenderse como la partición 0 y el número de temas particionados comienza desde 0) corresponde a una serie de libros de contabilidad, y cada libro de contabilidad solo almacena mensajes en la partición correspondiente. Cada libro mayor solo almacena mensajes en la partición correspondiente. Para cada partición, solo se puede abrir y escribir en un libro mayor al mismo tiempo.

Cuando Pulsar genera y almacena un mensaje, primero encuentra el libro mayor utilizado por la partición actual, luego genera una ID de entrada para el mensaje actual y lo incrementa en el mismo libro mayor. En el caso de producción no por lotes (el productor puede configurar este parámetro, el valor predeterminado es por lotes), una entrada contiene una pieza de información. En el modo por lotes, una entrada puede contener varios datos. Los contables escriben, buscan y obtienen basándose únicamente en la dimensión de entrada.

Por lo tanto, el msgID de cada pieza de información en Pulsar debe tener cuatro partes (la versión anterior tiene tres), a saber (ledgerID, EntryID, índice de partición, índice de lote), donde índice de partición es para temas no particionados es -1, el índice por lotes es -1 para temas no particionados, el índice por lotes es -1 para temas no particionados.

Cuando la longitud de existencia de cada libro mayor o el número de entradas que contiene excede un umbral, el libro mayor se cambia y la nueva información bajo la misma partición se almacena en el siguiente libro mayor.

Ledger es solo un concepto lógico, una combinación lógica de datos y no tiene una entidad correspondiente. Ledger es solo un concepto lógico, una combinación lógica de datos y no tiene una entidad correspondiente.

Después de que cada nodo de contabilidad en el clúster BookKeeper recibe la información, almacena y procesa los datos en tres partes: archivos de diario, archivos de registro de entradas y archivos de índice.

El archivo de registro, es decir, los datos de entrada, se escriben en el archivo de registro en forma de billetera. Cada archivo de registro tiene un límite de tamaño. Cuando se excede el límite de tamaño de un solo archivo, pasará al siguiente archivo para continuar escribiendo, porque el archivo de registro se vacía en tiempo real. Debido a que los archivos de registro se vacían en tiempo real, para mejorar el rendimiento y evitar lecturas, escrituras e interacciones de E/S mutuas, se recomienda separar el directorio de almacenamiento del directorio donde se almacenan los registros de entrada. Se monta el directorio de almacenamiento de cada archivo de registro. en un disco duro separado (se recomienda utilizar un disco duro ssd). Los archivos de registro están diseñados para garantizar que no se pierda información.

Como se muestra en la figura siguiente, cuando cada libro de cuentas recibe una solicitud para agregar una entrada, se asignará al directorio de diario y al directorio de registro de entradas de acuerdo con la identificación del libro de cuentas, y los datos de entrada se ser almacenado en el directorio correspondiente. Actualmente, bookie no admite cambiar el directorio de almacenamiento en tiempo de ejecución (agregar o reducir directorios durante el uso hará que no se encuentren algunos datos).

Como se muestra en la figura siguiente, cuando la casa de apuestas recibe una solicitud de escritura para una entrada, la escribirá en el archivo de registro y la guardará en la caché de escritura. La caché de escritura se divide en dos partes: la. entrada que se está escribiendo La caché de escritura y la caché de escritura de la entrada que se está actualizando se utilizan alternativamente.

El caché de escritura tiene una estructura de datos de índice, por lo que la entrada correspondiente se puede encontrar a través del índice. El índice en el caché de escritura se encuentra en el nivel de la memoria y se implementa en función de la estructura ConcurrentLongLongPairHashMap definida por el propio corredor de apuestas.

Además, cada directorio de almacenamiento de registro de entrada corresponde a un objeto de instancia de clase SingleDirectoryDbLedgerStorage, y cada objeto SingleDirectoryDbLedgerStorage tiene una estructura de índice basada en la implementación de RocksDB. Este índice le permite encontrar rápidamente en qué archivo de registro de entrada está almacenada cada entrada. Cada caché de escritura se ordena cuando se agregan entradas. En la misma caché de escritura, los datos bajo el mismo libro mayor son adyacentes y están ordenados, de modo que cuando los datos en la caché de escritura se vacían en el archivo de registro de entradas, se escriben los datos para el. El archivo de registro de entrada también se ordena localmente. Este diseño puede mejorar en gran medida la eficiencia de las lecturas posteriores.

Cuando se actualiza una entrada, los datos del índice en SingleDirectoryDbLedgerStorage también se actualizan en el archivo de índice. Cuando el libro mayor deja de funcionar y se reinicia, los datos se pueden recuperar a través de archivos de registro y archivos de registro de entrada para garantizar que no se pierdan datos.

Los consumidores de Pulsar realizarán una aceleración de almacenamiento en caché multicapa cuando consuman datos, como se muestra en la siguiente figura:

El orden de obtención de datos es el siguiente:

Para cada uno de los pasos anteriores, si se pueden obtener los datos, regresará directamente y omitirá los pasos siguientes. Si los datos se obtienen de un archivo de disco, los datos se almacenarán en la caché de lectura al regresar. Además, si los datos se leen desde el disco, los datos se leerán desde una parte del disco. Debido a que existe un proceso de clasificación local durante el almacenamiento, la probabilidad de obtener datos adyacentes es muy alta. eficiencia de la posterior adquisición de datos.

Durante su uso debemos intentar evitar o reducir el consumo de datos antiguos que desencadenen la lectura de mensajes en archivos de disco, para no afectar el rendimiento de todo el sistema.

Cada bloc de notas en BookKeeper limpiará los datos periódicamente. El proceso de verificación predeterminado es de 15 minutos. El proceso de limpieza principal es el siguiente:

A través del proceso anterior, podemos entender el bloc de notas. El proceso general al limpiar el archivo de registro de entrada.

Es importante tener en cuenta que la posibilidad de eliminar un libro mayor lo determina completamente el cliente, mientras que en Pulsar lo activa el agente.

El broker tiene un hilo de procesamiento periódico (2 minutos por defecto) que es responsable de limpiar los mensajes consumidos en el mecanismo del libro mayor, obtener el último mensaje reconocido del cursor contenido en el tema y eliminar Todos. libros de contabilidad (nota, excluyendo la identificación del libro mayor actual) en la lista de libros de contabilidad contenidos en el tema que tienen una identificación antes de este libro mayor (incluidos los metadatos en zk y la identificación del libro mayor actual). Esto incluye los metadatos en zk y notifica al corredor de apuestas que elimine el libro mayor correspondiente).

En el proceso de uso de Book Manager, nos hemos encontrado con varias situaciones en las que Book Manager se quedó sin espacio en disco y tenía una gran cantidad de archivos de registro de entradas almacenados en Book Manager. Generalmente hay dos razones para esto.

Razón 1:

La generación de mensajes está demasiado fragmentada. Por ejemplo, en el caso extremo, hay 10.000 temas, cada tema produce un mensaje y 1.000 temas se producen en secuencia. De esta manera, por razones de tiempo o espacio de almacenamiento, el libro mayor correspondiente a cada tema no se cambiará en un corto período de tiempo y los ID del libro mayor activo se encuentran dispersos en una gran cantidad de archivos de registro de entrada. Estos archivos de registro de entrada no se pueden eliminar ni comprimir de manera oportuna.

Si te encuentras con esta situación, puedes solucionarla reiniciando y forzando un cambio de libro mayor. Por supuesto, si no se mantiene al día con el consumo, el último reconocimiento consumido por el libro mayor sigue activo y no se puede eliminar.

Razón 2:

Durante el proceso de tiempo de GC, si hay muchos archivos enrylog existentes y una gran cantidad de ellos alcanzan el umbral de gc menor o mayor, el tiempo de un solo menor gc o major gc serán demasiado largos, los archivos de registro de entrada caducados no se pueden limpiar durante este tiempo.

Esto se debe a que un único proceso de limpieza se ejecuta en secuencia y la siguiente ronda solo se ejecutará después de que se complete la ronda de ejecución anterior. Actualmente, esta sección también habla de optimizar el proceso para evitar que la ejecución del subproceso demore demasiado y afecte el proceso general.