¿Qué aplicación se utiliza normalmente para aplicaciones PHP grandes?

1. Descripción general de Message Queue

El middleware de cola de mensajes es un componente importante en los sistemas distribuidos. Resuelve principalmente problemas como el acoplamiento de aplicaciones, los mensajes asincrónicos y la reducción del tráfico. Logre un alto rendimiento, alta disponibilidad, escalabilidad y, en última instancia, una arquitectura consistente. Es un middleware indispensable para sistemas distribuidos a gran escala.

Actualmente en entornos de producción, las colas de mensajes más utilizadas incluyen ActiveMQ, RabbitMQ, ZeroMQ, Kafka, MetaMQ, RocketMQ, etc.

2. Escenarios de aplicación de la cola de mensajes

A continuación se presentan los escenarios de uso comunes de la cola de mensajes en aplicaciones prácticas. Cuatro escenarios: procesamiento asincrónico, desacoplamiento de aplicaciones, corte de tráfico y comunicación de mensajes.

2.1 Procesamiento asincrónico

Descripción del escenario: después de que el usuario se registra, debe enviar un correo electrónico de registro y un SMS de registro. Existen dos métodos tradicionales: 1. Método en serie; 2. Método paralelo.

(1) Modo serie: después de escribir correctamente la información de registro en la base de datos, envíe un correo electrónico de registro y luego envíe un SMS de registro. Una vez completadas las tres tareas anteriores, regrese con el cliente. (Marco KKQ: 466097527, bienvenido a unirse)

(2) Método paralelo: después de que la información de registro se escribe correctamente en la base de datos, el correo electrónico de registro y el SMS de registro se envían al mismo tiempo. Una vez completadas las tres tareas anteriores, regrese con el cliente. La diferencia con el método serial es que el método paralelo puede mejorar el tiempo de procesamiento.

Suponiendo que cada uno de los tres nodos comerciales utiliza 50 milisegundos, sin considerar otros gastos generales como la red, el tiempo en serie es de 150 milisegundos y el tiempo en paralelo puede ser de 100 milisegundos.

Debido a que la cantidad de solicitudes procesadas por la CPU en una unidad de tiempo es cierta, suponga que el rendimiento de la CPU en 1 segundo es 100 veces. Entonces, la cantidad de solicitudes que la CPU puede manejar en 1 segundo en modo serie es 7 veces (1000/150). El número de solicitudes procesadas en paralelo es 10 veces (1000/100).

Resumen: Como se describe en el caso anterior, el rendimiento (concurrencia, rendimiento, tiempo de respuesta) del sistema tradicional tendrá cuellos de botella. ¿Cómo solucionar este problema?

La introducción de colas de mensajes elimina la lógica empresarial innecesaria y la procesa de forma asincrónica. La arquitectura modificada es la siguiente:

Según el acuerdo anterior, el tiempo de respuesta del usuario es equivalente al tiempo que tarda la información de registro en escribirse en la base de datos, que es de 50 milisegundos. Después de registrar un correo electrónico, enviar un mensaje de texto y escribirlo en la cola de mensajes, regresa directamente. Por lo tanto, la velocidad de escritura en la cola de mensajes es muy rápida y básicamente se puede ignorar, por lo que el tiempo de respuesta del usuario puede ser de 50 milisegundos. Por lo tanto, después del cambio de arquitectura, el rendimiento del sistema aumentó a 20 QPS por segundo. Es 3 veces mejor que el serial y 2 veces mejor que el paralelo.

2.2 Desacoplamiento de aplicaciones

Descripción del escenario: después de que el usuario realiza un pedido, el sistema de pedidos debe notificar al sistema de inventario. El enfoque tradicional es que el sistema de pedidos llama a la interfaz del sistema de inventario. Como se muestra a continuación:

Desventajas del modelo tradicional:

1) Si no se puede acceder al sistema de inventario, la reducción del pedido fallará, lo que provocará un error en el pedido;

2) El sistema de pedidos y el sistema de inventario están acoplados;

¿Cómo resolver los problemas anteriores? La solución después de introducir la cola de mensajes de la aplicación se muestra a continuación:

Sistema de pedidos: después de que el usuario realiza un pedido, el sistema de pedidos completa el procesamiento de persistencia, escribe el mensaje en la cola de mensajes y devuelve el pedido del usuario. éxito.

Sistema de inventario: suscríbase a la información del pedido y utilice métodos pull/push para obtener información del pedido. El sistema de inventario realiza operaciones de inventario basadas en la información del pedido.

Qué pasa si: El sistema de inventario no funciona correctamente al realizar un pedido. No afecta la realización normal del pedido, porque una vez realizado el pedido, el sistema de pedidos escribe en la cola de mensajes y ya no se preocupa por otras operaciones posteriores. Realice el desacoplamiento de la aplicación del sistema de pedidos y el sistema de inventario.

2.3 Reducción del tráfico

La reducción del tráfico también es un escenario común en las colas de mensajes y generalmente se usa ampliamente en ventas flash o capturas grupales.

Escenario de aplicación: las actividades de venta flash generalmente provocan un aumento repentino del tráfico debido al tráfico excesivo y la aplicación se cuelga. Para resolver este problema, generalmente es necesario agregar una cola de mensajes al front-end de la aplicación.

Puede controlar el número de personas activas;

Puede aliviar el alto tráfico en un corto período de tiempo que abruma la aplicación;

Después de que la solicitud del usuario es recibida por el servidor, primero escribe la cola de mensajes.

Si la longitud de la cola de mensajes excede el número máximo, la solicitud del usuario se descartará directamente o saltará a la página de error;

La empresa de venta flash realizará un procesamiento posterior en función de la información de la solicitud en la cola de mensajes. .

2.4 Procesamiento de registros

El procesamiento de registros se refiere al uso de colas de mensajes en el procesamiento de registros, como las aplicaciones Kafka, para resolver el problema de una gran cantidad de transmisiones de registros. La arquitectura se simplifica de la siguiente manera:

El cliente de recopilación de registros es responsable de recopilar datos de registro y escribirlos periódicamente en la cola de Kafka;

La cola de mensajes de Kafka es responsable de recibir, almacenar y reenviar datos de registro

Aplicación de procesamiento de registros: suscríbase y consuma datos de registro en la cola de Kafka;

Los siguientes son casos de aplicaciones de procesamiento de registros de Sina Kafka:

(1)Kafka: recibe cola de mensajes para registros de usuarios.

(2) Logstash: realiza análisis de registros, unifícalo en JSON y envíalo a Elasticsearch.

(3) Elasticsearch: la tecnología central del servicio de análisis de registros en tiempo real, un servicio de almacenamiento de datos en tiempo real y sin esquema, que organiza los datos mediante índices y tiene potentes funciones estadísticas y de búsqueda.

(4)Kibana: un componente de visualización de datos basado en Elasticsearch. Las súper capacidades de visualización de datos son una razón importante por la que muchas empresas eligen la pila ELK.

2.5 Comunicación de mensajes

La comunicación de mensajes significa que las colas de mensajes generalmente tienen mecanismos de comunicación eficientes incorporados, por lo que también se pueden utilizar para la comunicación pura de mensajes. Por ejemplo, implementar colas de mensajes punto a punto, o salas de chat, etc.

Comunicación punto a punto:

El cliente A y el cliente B utilizan la misma cola para la comunicación de mensajes.

Comunicación en la sala de chat:

El cliente A, el cliente B y el cliente N se suscriben al mismo tema para publicar y recibir mensajes. Logre un efecto similar al de una sala de chat.

Los anteriores son en realidad dos modos de mensaje de cola de mensajes, modo punto a punto o modo de publicación-suscripción. El modelo es un diagrama esquemático solo como referencia.

3. Ejemplo de middleware de mensajes

3.1 Sistema de comercio electrónico

La cola de mensajes utiliza middleware de mensajes duradero y de alta disponibilidad. Como Active MQ, Rabbit MQ, Rocket Mq. (1) Una vez que la aplicación completa el procesamiento lógico principal, escribe en la cola de mensajes. Si el mensaje se envía correctamente o no, puede habilitar el modo de confirmación del mensaje. (Después de que la cola de mensajes devuelve el estado de recepción exitosa del mensaje, la aplicación regresa, garantizando así la integridad del mensaje)

(2) Extienda el proceso (envío de mensajes de texto, procesamiento de entrega) para suscribirse a los mensajes de la cola . Utilice métodos push o pull para obtener mensajes y procesarlos.

(3) Si bien los mensajes desacoplan las aplicaciones, también generan problemas de coherencia de los datos, que pueden resolverse mediante la coherencia eventual. Por ejemplo, los datos principales se escriben en la base de datos y la aplicación extendida implementa un procesamiento posterior basado en la cola de mensajes y combinado con el método de la base de datos.

3.2 Sistema de recopilación de registros

Se divide en cuatro partes: centro de registro de Zookeeper, cliente de recopilación de registros, clúster Kafka y clúster Storm (OtherApp).

El centro de registro de Zookeeper proporciona servicios de equilibrio de carga y búsqueda de direcciones;

El cliente de recopilación de registros se utiliza para recopilar registros del sistema de aplicaciones y enviar datos a la cola de Kafka; 4. Servicio de mensajes JMS

Cuando hablamos de colas de mensajes, tenemos que mencionar JMS. La API JMS (Java Message Service, Java Message Service) es un estándar/especificación para servicios de mensajes que permite a los componentes de la aplicación crear, enviar, recibir y leer mensajes basados ​​en la plataforma JavaEE. Hace que la comunicación distribuida esté menos acoplada y los servicios de mensajes sean más confiables y asincrónicos.

En la arquitectura EJB, hay beans de mensajes que se pueden integrar perfectamente con el servicio de mensajes JM. En el modelo arquitectónico J2EE, existe el modelo de servidor de mensajes, que se utiliza para lograr el desacoplamiento directo de mensajes y aplicaciones.

4.1 Modelo de mensaje

En el estándar JMS, existen dos modelos de mensaje: P2P (Punto a punto) y Publicación/Suscripción (Pub/Sub).

4.1.1 Modo P2P

El modo P2P incluye tres roles: cola de mensajes (Queue), remitente (Sender) y receptor (Receiver). Cada mensaje se envía a una cola específica y el receptor recibe el mensaje de la cola. La cola retiene mensajes hasta que se consumen o se agotan.

Características del P2P

Cada mensaje tiene un solo consumidor (es decir, una vez consumido, el mensaje ya no está en la cola de mensajes)

Enviar Hay no hay dependencia temporal entre el remitente y el receptor, es decir, después de que el remitente envía el mensaje, independientemente de si el receptor se está ejecutando o no, no afectará el envío del mensaje a la cola

Recibir Después de recibir exitosamente el mensaje, el destinatario debe responder exitosamente a la cola.

Si desea que cada mensaje enviado se procese exitosamente, entonces se requiere el modo P2P. (Arquitectura KKQ: 466097527, bienvenido a unirse)

4.1.2 Modo Pub/sub

Contiene tres roles: Tema, Publicador y Suscriptor. Varios editores envían mensajes a un tema y el sistema entrega estos mensajes a varios suscriptores.

Características de Pub/Sub

Cada mensaje puede tener múltiples consumidores

Existe una dependencia temporal entre editores y suscriptores. Para un suscriptor de un tema determinado (Tema), debe crear un suscriptor antes de poder consumir los mensajes del editor.

Para poder consumir mensajes, el suscriptor debe permanecer en ejecución.

Para aliviar dependencias de tiempo tan estrictas, JMS permite a los suscriptores crear una suscripción duradera. De esta manera, incluso si el suscriptor no está activado (en ejecución), puede recibir mensajes del editor.

Si desea enviar un mensaje sin ningún procesamiento, o que solo lo procese un remitente del mensaje, o que lo puedan procesar varios consumidores, puede utilizar el modelo Pub/Sub.

4.2 Consumo de mensajes

En JMS, la generación y el consumo de mensajes son asíncronos. Para el consumo, los mensajeros JMS pueden consumir mensajes de dos formas.

(1) Sincronización

El suscriptor o receptor recibe el mensaje a través del método de recepción. El método de recepción se bloqueará hasta que se reciba el mensaje (o antes del tiempo de espera).

(2) Asíncrono

Un suscriptor o receptor puede registrarse como oyente de mensajes. Cuando llega el mensaje, el sistema llama automáticamente al método onMessage del oyente.

JNDI: Java Naming and Directory Interface, es una interfaz estándar del sistema de nombres Java. Los servicios se pueden encontrar y acceder a ellos en la web. Al especificar un nombre de recurso, el nombre corresponde a un registro en la base de datos o servicio de nombres y devuelve la información necesaria para establecer una conexión con el recurso.

JNDI desempeña el papel de encontrar y acceder al destino de envío o al origen del mensaje en JMS. (Arquitectura KKQ: 466097527, bienvenido a unirse)

Modelo de programación 4.3JMS

(1) ConnectionFactory

Cree una fábrica para objetos Connection, dirigida a dos jms diferentes Hay dos modelos de mensajes: QueueConnectionFactory y TopicConnectionFactory. Los objetos ConnectionFactory se pueden encontrar a través de JNDI.

(2) Destino

Destino significa el destino de envío del mensaje del productor del mensaje o el origen del mensaje del consumidor del mensaje. Para un productor de mensajes, su Destino es una determinada cola (Cola) o un determinado tema (Tema) para un consumidor de mensajes, su Destino también es una determinada cola o tema (es decir, el origen del mensaje);

Entonces, el destino son en realidad dos tipos de objetos: cola y tema que se pueden encontrar a través de JNDI.

(3) Conexión

La conexión representa el vínculo establecido entre el cliente y el sistema JMS (un contenedor para el socket TCP/IP). La conexión puede generar una o más sesiones. Al igual que ConnectionFactory, Connection también tiene dos tipos: QueueConnection y TopicConnection.

(4) Sesión

La sesión es la interfaz para operar mensajes. A través de sesiones se pueden crear productores, consumidores, mensajes, etc. La sesión proporciona funciones de transacción. Cuando necesite utilizar una sesión para enviar/recibir múltiples mensajes, puede poner estas acciones de envío/recibir en una transacción. De manera similar, también se divide en QueueSession y TopicSession.

(5) Productor de mensajes

El productor de mensajes lo crea la sesión y se utiliza para enviar mensajes al destino. De manera similar, existen dos tipos de productores de mensajes: QueueSender y TopicPublisher. Puede llamar al método del productor del mensaje (método de envío o publicación) para enviar el mensaje.

(6) Consumidor de mensajes

El consumidor de mensajes es creado por la sesión y se utiliza para recibir mensajes enviados al destino. Dos tipos: QueueReceiver y TopicSubscriber. Se puede crear mediante createReceiver(Queue) o createSubscriber(Topic) de la sesión respectivamente. Por supuesto, también puede crear suscriptores persistentes utilizando el método creatDurableSubscriber de la sesión.

(7) MessageListener

Escucha de mensajes. Si se registra un oyente de mensajes, se llamará automáticamente al método onMessage del oyente una vez que llegue el mensaje. MDB (Message-Driven Bean) en EJB es una especie de MessageListener.

El estudio en profundidad de JMS es muy útil para dominar la arquitectura JAVA y la arquitectura EJB. El middleware de mensajes también es un componente necesario de los sistemas distribuidos a gran escala. Este intercambio es principalmente una introducción general y la profundidad específica requiere que todos estudien, practiquen, resuman y comprendan.

5. Colas de mensajes de uso común

Los contenedores comerciales generales, como WebLogic y JBoss, admiten el estándar JMS, lo cual es muy conveniente para el desarrollo. Pero los gratuitos como Tomcat, Jetty, etc. requieren el uso de middleware de mensajes de terceros. Esta sección presenta el middleware de mensajes de uso común (Active MQ, Rabbit MQ, Zero MQ, Kafka) y sus características.

5.1 ActiveMQ

ActiveMQ es el bus de mensajes de código abierto más popular y potente producido por Apache. ActiveMQ es una implementación de proveedor JMS que es totalmente compatible con las especificaciones JMS1.1 y J2EE 1.4. Aunque la especificación JMS se lanzó hace mucho tiempo, JMS todavía desempeña una posición especial en las aplicaciones J2EE actuales.

Las características de ActiveMQ son las siguientes:

⒈ Los clientes se pueden escribir en múltiples idiomas y protocolos. Idioma: Java, C, C++, C#, Ruby, Perl, Python, PHP.

Protocolos de aplicación: OpenWire, Stomp REST, WS Notification, Support, ActiveMQ se pueden integrar fácilmente en sistemas que utilizan Spring y también admiten las funciones de Spring 2.0

⒋ Se aprobó el soporte de servidores J2EE comunes (como Geronimo , JBoss 4, GlassFish, WebLogic) Probando, mediante la configuración de adaptadores de recursos JCA 1.5, ActiveMQ se puede implementar automáticamente en cualquier servidor comercial compatible con J2EE 1.4

⒌ Soporta múltiples protocolos de transmisión: in-VM, TCP , SSL, NIO, UDP, JGroups, JXTA

⒍ Admite persistencia de mensajes de alta velocidad a través de JDBC y diario

⒎ Diseñado para garantizar una agrupación en clústeres de alto rendimiento, cliente-servidor, punto- to-point

⒏ Soporte Ajax

⒐ Soporte de integración con Axis

⒑ Puede llamar fácilmente al proveedor JMS integrado para realizar pruebas

5.2 RabbitMQ

RabbitMQ es un popular sistema de cola de mensajes de código abierto desarrollado en lenguaje erlang. RabbitMQ es una implementación estándar de AMQP (Protocolo avanzado de cola de mensajes). Admite una variedad de clientes, como: Python, Ruby, .NET, Java, JMS, C, PHP, ActionScript, XMPP, STOMP, etc., admite AJAX y persistencia. Se utiliza para almacenar y reenviar mensajes en sistemas distribuidos y tiene un buen rendimiento en términos de facilidad de uso, escalabilidad y alta disponibilidad.

Varios conceptos importantes:

Broker: En pocas palabras, es la entidad del servidor de la cola de mensajes.

Exchange: Intercambio de mensajes, que especifica las reglas según qué mensajes se enrutan a qué cola.

Cola: Portador de cola de mensajes, cada mensaje se colocará en una o más colas.

Enlace: Enlace, su función es vincular el intercambio y la cola de acuerdo con las reglas de enrutamiento.

Clave de enrutamiento: palabra clave de enrutamiento, Exchange entrega mensajes según esta palabra clave.

vhost: host virtual. Se pueden abrir múltiples vhosts en un broker para separar los permisos de diferentes usuarios.

Productor: Productor de mensajes es el programa que entrega los mensajes.

consumidor: Un consumidor de mensajes es un programa que acepta mensajes.

Canal: Canal de mensajes En cada conexión del cliente se pueden establecer múltiples canales, y cada canal representa una tarea de sesión.

El proceso de uso de la cola de mensajes es el siguiente:

(1) El cliente se conecta al servidor de la cola de mensajes y abre un canal.

(2) El cliente declara un intercambio y establece atributos relacionados.

(3) El cliente declara una cola y establece atributos relacionados.

(4) El cliente utiliza la clave de enrutamiento para establecer una relación vinculante entre el intercambio y la cola.

(5) El cliente entrega el mensaje a intercambiar.

Después de que Exchange recibe el mensaje, lo enruta según la clave del mensaje y el enlace que se ha establecido, y entrega el mensaje a una o más colas.

5.3 ZeroMQ

Conocida como la cola de mensajes más rápida de la historia, en realidad es similar a una serie de interfaces de Socket. La diferencia entre este y Socket es: el socket ordinario es final. a extremo (relación 1:1), pero ZMQ puede tener una relación N:M. La gente sabe más sobre los sockets BSD a partir de conexiones punto a punto que requieren el establecimiento explícito de conexiones, destrucción de conexiones. y selección de protocolos (TCP/UDP) y manejo de errores, etc., mientras que ZMQ blinda estos detalles, simplificando la programación de su red. ZMQ se utiliza para la comunicación entre nodos. Un nodo puede ser un host o un proceso.

Citando la declaración oficial: "ZMQ (en adelante, ZeroMQ, ZMQ) es una capa de transporte simple y fácil de usar, una biblioteca de sockets como un marco, lo que hace que la programación de Sockets sea más simple y concisa. y de mayor rendimiento. Es una biblioteca de colas de procesamiento de mensajes que se puede escalar elásticamente en múltiples subprocesos, núcleos y cuadros de host. El objetivo declarado de ZMQ es "convertirse en parte de la pila de protocolos de red estándar y luego ingresar al kernel de Linux". Aún no ha tenido éxito. Sin embargo, es sin duda una capa muy prometedora y muy necesaria además de los sockets BSD "tradicionales" que hace que escribir aplicaciones de red de alto rendimiento sea extremadamente fácil y divertido. >Las características son:

Alto rendimiento, no persistente;

Multiplataforma: admite Linux, Windows, OS X, etc.

Soporte multilingüe; más de 30 lenguajes de desarrollo como C, C++, Java, .NET y Python.

Se puede implementar por separado o integrar en aplicaciones;

Se puede utilizar como una biblioteca de comunicación Socket.

En comparación con RabbitMQ, ZMQ no es como un servidor de cola de mensajes en el sentido tradicional. De hecho, no es un servidor en absoluto, sino más bien una biblioteca de comunicación de red subyacente, además de la API de Socket. Se crea una capa de encapsulación para abstraer la comunicación de red, la comunicación de proceso y la comunicación de subprocesos en una interfaz API unificada. Admite tres modelos básicos y modelos extendidos: "Solicitud-Respuesta", "Editor-Suscriptor" y "Parallel Pipeline".

Puntos de diseño de alto rendimiento de ZeroMQ:

1. Modelo de cola sin bloqueo

Para datos entre interacciones entre subprocesos (cliente y sesión) El canal de intercambio pipe adopta el algoritmo de cola sin bloqueo CAS; los eventos asincrónicos se registran en ambos extremos de la tubería. Al leer o escribir mensajes en la tubería, los eventos de lectura y escritura se activarán automáticamente.

2. Algoritmo de procesamiento por lotes

Para el procesamiento de mensajes tradicional, cada mensaje requiere llamadas al sistema al enviar y recibir. De esta manera, para una gran cantidad de mensajes, el sistema La sobrecarga es. relativamente grande, ZeroMQ ha realizado optimizaciones adaptativas para mensajes por lotes y puede recibir y enviar mensajes por lotes.

3. Enlace de subprocesos en multinúcleo sin cambio de CPU

A diferencia del modo tradicional de concurrencia de subprocesos múltiples, semáforo o sección crítica, zeroMQ aprovecha al máximo el multinúcleo, cada núcleo. El enlace ejecuta un subproceso de trabajo para evitar la sobrecarga de la CPU al cambiar entre múltiples subprocesos.

5.4 Kafka

Kafka es un sistema de mensajería de publicación y suscripción distribuido de alto rendimiento que puede manejar todos los datos de transmisión de acciones en sitios web a escala de consumidor. Estas acciones (navegación web, búsquedas y otras acciones del usuario) son un factor clave en muchas funciones sociales en la web moderna. Estos datos normalmente se abordan mediante el procesamiento de registros y la agregación de registros debido a los requisitos de rendimiento. Para datos de registro y sistemas de análisis fuera de línea como Hadoop, pero que requieren restricciones de procesamiento en tiempo real, esta es una solución factible. El propósito de Kafka es unificar el procesamiento de mensajes en línea y fuera de línea a través del mecanismo de carga paralela de Hadoop y proporcionar consumo en tiempo real a través de máquinas en clúster.

Kafka es un sistema de mensajería de publicación-suscripción distribuida de alto rendimiento con las siguientes características:

Proporciona persistencia de mensajes a través de estructuras de datos de disco O(1) La estructura mantiene un rendimiento estable a lo largo del tiempo. incluso para almacenamiento de mensajes de varios terabytes. (Los datos se escriben añadiendo archivos y los datos caducados se eliminan periódicamente)

Alto rendimiento: incluso el hardware Kafka más común puede admitir millones de mensajes por segundo.

Admite la partición de mensajes a través del servidor Kafka y clústeres de máquinas de consumo.

Soporta carga de datos paralelos de Hadoop.

Conceptos relacionados con Kafka

Broker

Un clúster Kafka contiene uno o más servidores, que se denominan brokers[5]

Tema

Cada mensaje publicado en el clúster de Kafka tiene una categoría, y esta categoría se denomina Tema. (Físicamente, los mensajes de diferentes Temas se almacenan por separado. Lógicamente, aunque los mensajes de un Tema se almacenan en uno o más intermediarios, los usuarios solo necesitan especificar el Tema del mensaje para producir o consumir datos sin importar dónde se almacenan los datos. )

Partición

La partición es un concepto físico. Cada tema contiene una o más particiones.

El productor

es responsable de publicar los mensajes. al corredor Kafka

Consumidor

Consumidor de mensajes, un cliente que lee mensajes del corredor Kafka.

Grupo de Consumidores

Cada Consumidor pertenece a un Grupo de Consumidores específico (el nombre del grupo se puede especificar para cada Consumidor, si no se especifica el nombre del grupo, pertenece al grupo predeterminado) .

Generalmente se utiliza en el procesamiento de registros de big data o en escenarios con requisitos ligeramente menores de rendimiento en tiempo real (una pequeña cantidad de retraso) y confiabilidad (una pequeña cantidad de pérdida de datos).