Dado que las colas de mensajes distribuidos tienen requisitos relativamente altos de confiabilidad, es necesario asegurarse de que el mensaje no se pierda después de que el productor envía el mensaje al intermediario. Por lo tanto, la cola de mensajes tiene el requisito de un almacenamiento confiable.
A juzgar por los métodos de almacenamiento utilizados por varias colas de mensajes MQ convencionales, hay principalmente tres
- Almacenamiento KV distribuido,
- Este método de almacenamiento se puede utilizar cuando la capacidad de lectura y escritura de mensajes no es alta.
- Por ejemplo, levelDB y Redis usados en ActiveMQ,
- Almacenamiento del sistema de archivos,
- Esta solución es adecuada para middleware de mensajes con requisitos de alto rendimiento, ya que el flasheo de mensajes es un método de persistencia de alta eficiencia, alta confiabilidad y alto rendimiento. A menos que el disco falle, generalmente no habrá problemas insostenibles
- Los más comunes, como kafka, RocketMQ y RabbitMQ, utilizan mensajes que parpadean en el sistema de archivos en la máquina implementada para la persistencia.
- Base de datos relacional,
- El rendimiento de IO de la base de datos relacional sufrirá un cuello de botella cuando la cantidad de datos en una sola tabla alcance decenas de millones.
- Por ejemplo, ActiveMQ puede usar mysql como almacenamiento de mensajes, por lo que ActiveMQ no es adecuado para escenarios de cola de mensajes de alto rendimiento.
En general, para la eficiencia del almacenamiento, los sistemas de archivos son mejores que el almacenamiento KV distribuido, y el almacenamiento KV distribuido es mejor que las bases de datos relacionales.
1. La estructura general del almacenamiento de mensajes
El almacenamiento de mensajes de RocketMQ utiliza una estructura de almacenamiento híbrida, es decir, todas las colas en una sola instancia de Broker comparten un archivo de datos de registro CommitLog. Ésta es otra diferencia con Kafka.
¿Por qué no utilizar el diseño de Kafka para almacenar un archivo físico separado para diferentes particiones?
Esto se debe a que en el diseño de Kafka, una vez que el número de particiones de tema en Kafka es demasiado grande, habrá demasiados archivos de cola, lo que ejercerá mucha presión sobre la lectura y escritura de E / S del disco, lo que provocará un cuello de botella en el rendimiento. Por lo tanto, RocketMQ se ha optimizado y el asunto del mensaje se almacena uniformemente en CommitLog.
- ventaja:
- Dado que el asunto del mensaje se lee y escribe a través de CommitLog, solo una pequeña cantidad de datos se almacena en ConsumerQueue, por lo que la cola es más ligera.
- El acceso al disco se serializa para evitar la competencia del disco.
- Desventajas:
- Aunque el mensaje se escribe en el disco según la escritura secuencial , el proceso de lectura es de hecho una lectura aleatoria .
- La lectura de un mensaje leerá primero ConsumeQueue y luego CommitLog, lo que reducirá la eficiencia de la lectura del mensaje.
2. La estructura del archivo de almacenamiento del mensaje.
RocketMQ utiliza un sistema de archivos para almacenar mensajes, y el almacenamiento de mensajes se completa con la cooperación de ConsumeQueue y CommitLog.
- CommitLog es el archivo de almacenamiento físico real del mensaje.
- ConsumeQueue es una cola lógica de mensajes, un poco similar al archivo de índice de una base de datos, que almacena la dirección que apunta al almacenamiento de mensajes en el archivo CommitLog.
Los archivos de almacenamiento de RocketMQ están en el root/storedirectorio de forma predeterminada y puede ver un archivo tan estructurado.
Solo debemos preocuparnos por Commitlog, Consumequeue, Index
1.CommitLog
CommitLog es un archivo físico que se utiliza para almacenar mensajes. El commitLog de cada agente es compartido por todos los consumerQueues de la máquina actual sin ninguna distinción. Es decir, los datos de todos los temas existen juntos
-
Acerca del tamaño del archivo
- El tamaño predeterminado del archivo en CommitLog es 1G, que se puede configurar dinámicamente;
- Cuando un archivo está lleno, se generará un nuevo archivo de registro de confirmación. Todos los datos del tema se escriben secuencialmente en el archivo CommitLog.
-
Acerca de los nombres de archivo
-
La longitud del nombre del archivo es de 20 bits, el lado izquierdo se rellena con 0 y el desplazamiento restante sin iniciar
-
Por ejemplo, 00000000000000000000 significa el primer archivo,
Cuando el primer archivo está lleno, se genera el segundo archivo 000000000001073741824, el desplazamiento inicial es 1073741824
-
2.ConsumeQueue
El consumeQueue representa la cola lógica del consumo de mensajes, que contiene el desplazamiento de la posición física real fuera del conjunto de MessageQueue en el registro de confirmación, el tamaño del contenido de la entidad del mensaje y el valor hash de la etiqueta del mensaje.
-
Acerca del tamaño del archivo
Para el almacenamiento físico real, consumeQueue corresponde a los archivos de cada tema y ID de cola. Cada archivo de tipo consumeQueue también tiene un tamaño. El tamaño predeterminado de cada archivo es de aproximadamente 600 W bytes. Si el archivo está lleno, también generará uno. Nuevo archivo
-
Acerca de los nombres de archivo
Cada Cola de mensajes debajo de cada tema corresponde a un archivo ConsumeQueue. Por ejemplo, hay dos carpetas debajo del tema testCreateTopic3 en la figura anterior, que representan las colas de mensajes 0 y 1.
La dirección de archivo de cada cola de mensajes es:
root/store/consumequeue/{topicNmae}/{queueId}/{filename}
3.IndexFile
Archivo de índice, si un mensaje contiene un valor clave, IndexFile se utilizará para almacenar el índice del mensaje. El archivo de índice proporciona recuperación de datos para CommitLog y proporciona un método para encontrar mensajes en CommitLog por clave o intervalo de tiempo.
En el almacenamiento físico, el nombre del archivo se basa claramente en la marca de tiempo creada. El tamaño de un IndexFile único fijo es de aproximadamente 400M, y un IndexFile puede almacenar índices de 2000W.
4.abortar
Cuando el broker inicia, crea un archivo vacío llamado abort y lo borra cuando se apaga. Se usa para identificar si el proceso sale normalmente. Si sale anormalmente, realizará la recuperación de fallas al inicio.