Análisis del principio de RocketMQ
Análisis de principios de RocketMQ
Nota:
NameServer no tiene estado, es decir, la información de estado del Broker y el tema en NameServer (obtenida a través de otros informes de roles) es almacenado en En la memoria, no se almacenará de forma persistente (se puede configurar mediante la configuración) y el clúster se puede expandir horizontalmente. Las funciones principales son las siguientes:
a. Recibir información de enrutamiento registrada cuando se inicia el Broker (maestro y esclavo);
Proporcionar servicios de enrutamiento para productores y consumidores, es decir:
c. Obtener la información de enrutamiento de temas de todos los corredores y obtener la información de enrutamiento de todos los corredores por nombre de tema
b. Información de enrutamiento de todos los Brokers;
c. Recibir información de latidos enviada por el Broker. Si la marca de tiempo del latido expira, NameServer cerrará la conexión con el Broker.
El corredor registra información de configuración del tema con NameServer en el siguiente formato:
Almacenamiento de mensajes del corredor
El almacenamiento de mensajes de Rocketmq se realiza con la ayuda de consumeQueue y commitLog Completado . commitLog guarda los datos físicos del mensaje, mientras que consumeQueue es la cola lógica del mensaje, similar a un índice, y guarda la dirección de almacenamiento físico. En el Broker, solo hay un commitLog y todos los consumerQueue**** comparten el mismo commitLog.
Si el nombre del tema es Topic-Lance y las colas de lectura/escritura configuradas son cola-1 y cola-2, entonces Topic-Lance y cola-1 forman una única cola de consumo.
Supongamos que Topic-Lance y queue-1 forman una cola de consumo, y Topic-Lance y queue-2 forman otra cola de consumo.
Supongamos que las dos máquinas del intermediario, el intermediario A (incluidas la cola 0, la cola 1 y la cola 2) y el intermediario B (incluidas la cola 0 y la cola 1), están configuradas con Topic-Lance, luego, cuando se inicia el broker, las rutas de Topic-Lance registradas en NameServer son broker-A-queue-0, broker-A-queue-1, broker-A-queue-2, broker-B-queue- 0, corredor-B -cola-1*** 5 colas de consumo.
Para mejorar el rendimiento de lectura y escritura, commitLog adopta escritura secuencial y lectura aleatoria (lectura por lotes del disco a la memoria a través del mecanismo de caché de paginación para acelerar la lectura posterior), mientras que consumerQueues lee principalmente la memoria (si volumeQueue se pierde debido a factores como el reinicio, se puede reconstruir a través de commitLog)
a.El productor envía un mensaje (debe expresarse como un tema), primero obtiene topic-gt de la colección del productor local; información de enrutamiento del agente, si no, obtenga la información de enrutamiento del servidor de nombres. De lo contrario, obtenga la información de enrutamiento del servidor de nombres y luego obtenga la información de enrutamiento de la colección del Productor local.
b. Obtener la información de enrutamiento de temas más reciente de nameServer a intervalos regulares
c. > d. El productor envía un mensaje al agente maestro y el mensaje se copia al agente esclavo a través de la replicación maestro-esclavo del agente.
Enviar el método de sondeo:
a. Registrar al consumidor en NameServer;
b. Obtener información de enrutamiento de temas de NameServer con regularidad. > c. Limpiar los corredores fuera de línea periódicamente;
d. Enviar latidos a todos los corredores
e. El servicio de equilibrio de carga se reinicia.
RocketMQ extrae mensajes según el modo de extracción. El consumidor realiza el equilibrio de carga y extrae los mensajes al intermediario mediante un sondeo largo. Después de que el sondeo largo extrae el mensaje, vuelve a llamar a MessageListener. El sondeo largo extrae mensajes y luego vuelve a llamar a la interfaz MessageListener para completar el consumo.
Para obtener más información sobre el sondeo largo de RocketMQ, consulte: /p/48dbc9eee890
RocketMQ tiene un valor predeterminado de 3 días y el intervalo de actualización del registro de confirmación es de 1 segundo.
...
El valor predeterminado es 3 reintentos después del error. Puede definir el número de reintentos con retryTimesWhenSendFailed
1. Excepciones, generalmente repetidas 16 veces durante 10 y 30 segundos, 1 minuto. , 2 minutos, 3 minutos, etc., puede configurar la configuración TransactionCheckMax
2. Situación de tiempo de espera (el lado del consumidor no devuelve CONSUME_SUCCESS ni RECONSUME_LATER), MQ enviará al lado del consumidor sin Límite, el tiempo de espera predeterminado es de 15 minutos.