Funciones funciones)

1 Suscríbete y publica

La publicación de mensajes se refiere a un productor que envía un mensaje a un tema; la suscripción de mensajes se refiere a un consumidor que sigue un mensaje con una determinada etiqueta en un tema y luego consume datos de ese tema.

2 Secuencia de mensajes

Orden de mensajes significa que cuando se consume un tipo de mensaje, se puede consumir en el orden en que se envía. Por ejemplo: un pedido genera tres mensajes: creación del pedido, pago del pedido y finalización del pedido. Es significativo consumir en este orden al consumir, pero al mismo tiempo, los pedidos se pueden consumir en paralelo. RocketMQ puede garantizar estrictamente el orden de los mensajes.

Los mensajes de secuencia se dividen en mensajes de secuencia global y mensajes de secuencia de partición. La secuencia global significa que todos los mensajes de un tema deben estar en orden; los mensajes de secuencia parcial solo necesitan garantizar que cada grupo de mensajes se consuma secuencialmente.

Orden global Para un tema específico, todos los mensajes se publican y consumen en un estricto orden de primero en entrar, primero en salir (FIFO). Escenarios aplicables: los requisitos de rendimiento no son altos y todos los mensajes se publican y consumen estrictamente de acuerdo con el principio FIFO
Orden de partición Para un tema específico, todos los mensajes se particionan según la clave de partición. Los mensajes de la misma partición se publican y consumen en estricto orden FIFO. La clave de fragmentación es un campo clave que se utiliza para distinguir diferentes particiones en mensajes secuenciales. Es un concepto completamente diferente de la clave de los mensajes ordinarios. Escenarios aplicables: requisitos de alto rendimiento, use la clave de fragmentación como campo de partición y siga estrictamente el principio FIFO en el mismo bloque para la publicación y el consumo de mensajes.

3 filtrado de mensajes

Los consumidores de RocketMQ pueden filtrar mensajes según la etiqueta y también admitir el filtrado de atributos personalizados. El filtrado de mensajes se implementa actualmente en el lado del Broker. La ventaja es que reduce la transmisión de mensajes inútiles por la red al Consumidor. La desventaja es que aumenta la carga para el Broker y la implementación es relativamente complicada.

4 Confiabilidad de mensajes

RocketMQ admite una alta confiabilidad de los mensajes y varias situaciones que afectan la confiabilidad de los mensajes:

Broker cerrado anormalmente
Broker Crash anormal
Bloqueo del sistema operativo
La máquina pierde energía, pero la fuente de energía se puede restaurar inmediatamente
La máquina no se puede encender (tal vez la CPU, la placa base, la memoria y otros equipos clave estén dañados)
El dispositivo de disco está dañado

1), 2), 3), 4) Las cuatro situaciones son todos los recursos de hardware que se pueden recuperar inmediatamente. RocketMQ puede garantizar que los mensajes no se pierdan o que se pierda una pequeña cantidad de datos en estas cuatro situaciones (dependiendo de si el método de flasheo es síncrono o asincrónico) .

5), 6) Es un solo punto de falla y no se puede recuperar. Una vez que ocurre, todos los mensajes en este único punto se pierden. En estos dos casos, RocketMQ puede garantizar que el 99% de los mensajes no se perderán mediante la replicación asincrónica, pero es posible que se pierda una cantidad muy pequeña de mensajes. Los puntos únicos se pueden evitar por completo mediante la tecnología de escritura dual síncrona La escritura dual síncrona está destinada a afectar el rendimiento y es adecuada para ocasiones que requieren una confiabilidad de mensaje extremadamente alta, como las aplicaciones relacionadas con el dinero. Nota: RocketMQ admite escritura doble síncrona desde la versión 3.0.

5 al menos una vez

Al menos una vez significa que cada mensaje debe enviarse una vez. El consumidor envía el mensaje al local primero y devuelve la confirmación al servidor después de que se completa el consumo. Si no hay consumo, no habrá ningún mensaje de confirmación, por lo que RocketMQ puede admitir esta función.

6 Consumo retrospectivo

El consumo retrospectivo se refiere al mensaje que el Consumidor ha consumido con éxito. Debido a las necesidades comerciales, es necesario volver a consumirlo. Para admitir esta función, el corredor aún debe conservar el mensaje después de que el mensaje correcto se haya entregado al Consumidor. Y el re-consumo generalmente se basa en la dimensión de tiempo. Por ejemplo, debido a la falla del sistema del Consumidor, los datos deben volver a consumirse hace 1 hora después de la recuperación, luego el Broker debe proporcionar un mecanismo para revertir el progreso del consumo en la dimensión de tiempo. RocketMQ admite el consumo de acuerdo con la retrospectiva del tiempo y la dimensión del tiempo tiene una precisión de milisegundos.

7 Mensaje de transacción

El mensaje transaccional de RocketMQ (mensaje transaccional) se refiere a la aplicación de transacciones locales y las operaciones de envío de mensajes se pueden definir en la transacción global, ya sea exitosa o fallida al mismo tiempo. El mensaje de transacción de RocketMQ proporciona una función de transacción distribuida similar a X / Open XA, y la consistencia final de las transacciones distribuidas se puede lograr mediante mensajes de transacción.

8 mensajes cronometrados

Mensaje temporizado (cola retrasada) significa que después de que el mensaje se envía al corredor, no se consumirá inmediatamente, esperando a que se entregue un tiempo específico al tema real. El corredor tiene un elemento de configuración messageDelayLevel, el valor predeterminado es "1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h", 18 niveles. Puede configurar messageDelayLevel personalizado. Tenga en cuenta que messageDelayLevel es un atributo del corredor y no pertenece a un tema. Al enviar un mensaje, simplemente establezca el nivel delayLevel: msg.setDelayLevel (nivel). El nivel tiene las siguientes tres situaciones:

nivel == 0, el mensaje no se retrasa
1 <= nivel <= maxLevel, el mensaje se retrasa por un tiempo específico, por ejemplo, nivel == 1, el retraso es 1s
level> maxLevel, luego level == maxLevel, por ejemplo, nivel == 20, retraso 2h

Los mensajes temporizados se almacenarán temporalmente en un tema llamado SCHEDULE_TOPIC_XXXX y se almacenarán en una cola específica de acuerdo con delayTimeLevel, queueId = delayTimeLevel - 1, es decir, solo los mensajes con el mismo retraso se almacenan en una cola, lo que garantiza que los mensajes con el mismo retraso de transmisión se puedan consumir secuencialmente. El corredor consumirá SCHEDULE_TOPIC_XXXX de forma programada y escribirá el mensaje en el tema real.

Cabe señalar que los mensajes de tiempo se contarán tanto cuando se escriban por primera vez como cuando estén programados para escribirse en el tema real, por lo que aumentará el número de envíos y tps.

9 reintento de mensaje

Después de que el consumidor no consuma un mensaje, se debe proporcionar un mecanismo de reintento para que el mensaje se consuma nuevamente. La falla del consumidor para consumir mensajes generalmente se puede considerar como las siguientes situaciones:

Debido a las razones del mensaje en sí, como una falla de deserialización, los datos del mensaje en sí no se pueden procesar (por ejemplo, la factura del teléfono se recarga, el número de teléfono móvil del mensaje actual se cancela y la recarga no se puede recargar). Este tipo de error generalmente requiere omitir este mensaje y consumir otros mensajes. Incluso si este mensaje fallido se vuelve a intentar inmediatamente, el 99% no se realizará correctamente. Por lo tanto, es mejor proporcionar un mecanismo de reintento cronometrado, es decir, después de 10 segundos Inténtalo de nuevo.
Debido a que los servicios de aplicaciones descendentes dependientes no están disponibles, por ejemplo, la conexión de base de datos no está disponible y la red del sistema externo no está disponible. Encontró este tipo de error, incluso si se omite el mensaje fallido actual, el consumo de otros mensajes también informará un error. En este caso, se recomienda aplicar la suspensión 30 segundos antes de consumir el siguiente mensaje, lo que puede reducir la presión del Broker para reintentar el mensaje.

RocketMQ configurará una cola de reintentos con el nombre de tema "% RETRY% + consumerGroup" para cada grupo de consumidores (debe tenerse en cuenta aquí que la cola de reintentos de este tema es para el grupo de consumidores, no para cada tema. ), que se utiliza para guardar temporalmente mensajes que no se pueden consumir en el lado del consumidor debido a varias excepciones. Teniendo en cuenta que la recuperación de la excepción lleva algún tiempo, se establecerán varios niveles de reintento para la cola de reintentos. Cada nivel de reintento tiene un retraso de reenvío correspondiente. Cuantos más reintentos, mayor será el retraso de entrega. El procesamiento de los mensajes de reintento de RocketMQ se guarda primero en la cola de retardo con el nombre de tema "SCHEDULE_TOPIC_XXXX", y las tareas de tiempo en segundo plano se retrasan según el tiempo correspondiente y luego se guardan en la cola de reintentos de "% RETRY% + consumerGroup".

10 Reenvío de mensajes

Cuando el productor envía un mensaje, el mensaje síncrono se retransmitirá si falla y se reintentará el mensaje asíncrono Oneway no tiene ninguna garantía. La refundición del mensaje garantiza que el mensaje se envíe con el mayor éxito posible sin perderse, pero puede causar la duplicación del mensaje, que es un problema inevitable en RocketMQ. La repetición de mensajes no ocurre en circunstancias normales. Cuando hay una gran cantidad de mensajes y fluctuación de la red, la repetición de mensajes será un evento de alta probabilidad. Además, la retransmisión proactiva por parte del productor y los cambios en la carga del consumidor también pueden causar mensajes duplicados. Los siguientes métodos pueden establecer la estrategia de reintento del mensaje:

retryTimesWhenSendFailed: el número de reintentos cuando falla el envío síncrono, el valor predeterminado es 2, por lo que el productor intentará enviar retryTimesWhenSendFailed + 1 veces como máximo. No elegirá al corredor que falló la última vez e intentará enviarlo a otros corredores para asegurarse de que el mensaje no se pierda en la mayor medida posible. Si se excede el número de reposiciones, se lanza una excepción y el cliente se asegura de que el mensaje no se pierda. Cuando se produzcan RemotingException, MQClientException y alguna MQBrokerException, se refundirán.
retryTimesWhenSendAsyncFailed: el número de reintentos por fallas de envío asincrónico. Los reintentos asincrónicos no seleccionarán otros corredores y solo reintentarán en el mismo corredor. No hay garantía de que los mensajes no se pierdan.
retryAnotherBrokerWhenNotStoreOK: el mensaje parpadeante (primario o en espera) agotó el tiempo de espera o el esclavo no está disponible (el estado de retorno no es SEND_OK), ya sea para intentar enviar a otros corredores, el valor predeterminado es falso. Se pueden abrir noticias muy importantes.

11 Control de flujo

Control de flujo del productor, porque la capacidad de procesamiento del intermediario llega al cuello de botella; control del flujo del consumidor, porque la capacidad de consumo llega al cuello de botella.

Control de flujo del productor:

Cuando el archivo commitLog está bloqueado durante más tiempo que osPageCacheBusyTimeOutMills, el parámetro predeterminado es 1000ms y se devuelve el control de flujo.
Si transientStorePoolEnable == true está habilitado, y el intermediario es el host para el disco flash asíncrono y los recursos en transientStorePool son insuficientes, se rechaza la solicitud de envío actual y se devuelve el control de flujo.
El corredor verifica el tiempo de espera de la solicitud en la cabecera de la cola de solicitudes de envío cada 10 ms. Si excede waitTimeMillsInSendQueue, el valor predeterminado es 200 ms, la solicitud de envío actual se rechaza y se devuelve el control de flujo.
El corredor implementa el control de flujo al rechazar las solicitudes de envío.

Tenga en cuenta que el control de flujo del productor no intentará retransmitir mensajes.

Control de flujo del consumidor:

Cuando la cantidad de mensajes almacenados en caché localmente por el consumidor excede pullThresholdForQueue, el valor predeterminado es 1000.
Cuando el tamaño del mensaje de la memoria caché local del consumidor excede pullThresholdSizeForQueue, el valor predeterminado es 100 MB.
Cuando el intervalo de mensajes de la memoria caché local del consumidor excede consumeConcurrentlyMaxSpan, el valor predeterminado es 2000.

El resultado del control de flujo del consumidor es reducir la frecuencia de atracción.

12 Cola de mensajes no entregados

La cola de mensajes no entregados se utiliza para procesar mensajes que no se pueden consumir normalmente. Cuando un mensaje no se consume por primera vez, la cola de mensajes reintentará automáticamente el mensaje; una vez alcanzado el número máximo de reintentos, si el consumo aún falla, significa que el consumidor no puede consumir el mensaje correctamente en circunstancias normales. En este momento, la cola de mensajes no Descarte el mensaje inmediatamente, pero envíelo a la cola especial correspondiente al consumidor.

RocketMQ se refiere a los mensajes que no se pueden consumir en circunstancias normales como mensajes no entregados, y la cola especial que almacena mensajes no entregados como colas de mensajes no entregados. En RocketMQ, puede usar la consola para reenviar los mensajes en la cola de mensajes no entregados para que las instancias del consumidor vuelvan a consumir.

13 Enlace original

注释：来源于GitHub
https://github.com/apache/rocketmq/blob/master/docs/cn/README.md

Características de RocketMQ (2)