¿Qué aplicación se utiliza normalmente para la cola de mensajes en aplicaciones PHP grandes?

1. Descripción general de Message Queue\x0d\ 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. \x0d\ En la actualidad, en el entorno de producción, las colas de mensajes más utilizadas incluyen ActiveMQ, RabbitMQ, ZeroMQ, Kafka, MetaMQ, RocketMQ, etc. \x0d\　2. Escenarios de aplicación de la cola de mensajes\x0d\　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. \x0d\ 2.1 Procesamiento asincrónico \x0d\ 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. \x0d\　 (1) Modo serie: después de que la información de registro se escribe correctamente en la base de datos, se envía un correo electrónico de registro y luego se envía un SMS de registro. Una vez completadas las tres tareas anteriores, regrese con el cliente. (Arquitectura KKQ: 466097527, bienvenido a unirse)\x0d\ (2) Método paralelo: después de escribir con éxito la información de registro 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. \x0d\ 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. \x0d\ Dado que la cantidad de solicitudes procesadas por la CPU en unidad de tiempo es cierta, suponga que el rendimiento de la CPU es 100 veces en 1 segundo. 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). \x0d\Resumen: Como se describe en el caso anterior, el rendimiento (simultaneidad, rendimiento, tiempo de respuesta) del sistema tradicional tendrá cuellos de botella. ¿Cómo solucionar este problema? \x0d\　La introducción de la cola de mensajes eliminará la lógica empresarial innecesaria y la procesará de forma asincrónica. La arquitectura modificada es la siguiente: \x0d\ 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. \x0d\ 2.2 Desacoplamiento de aplicaciones \x0d\ 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: \x0d\ Desventajas del modelo tradicional: \x0d\ 1) Si no se puede acceder al sistema de inventario, la reducción del pedido fallará, lo que resultará en una falla del pedido \x0d\ 2) El sistema de pedidos está acoplado con el inventario; system; \x0d\ ¿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: \x0d\ 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 exitoso del usuario. \x0d\　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. \x0d\　Qué pasa si: El sistema de inventario no se puede utilizar normalmente 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. \x0d\ 2.3 Reducción de tráfico \x0d\ La reducción de 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. \x0d\　Escenario de aplicación: las actividades de venta flash, generalmente debido a un tráfico excesivo, provocan un aumento repentino del tráfico 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. \x0d\　Puede controlar el número de personas activas;\x0d\　Puede aliviar la abrumadora aplicación de alto tráfico en un corto período de tiempo;\x0d\　Después de que el servidor recibe la solicitud del usuario, primero se escribe en el 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 \x0d\ El negocio de venta flash realizará un procesamiento posterior en función de la información de la solicitud en la cola de mensajes. \x0d\　2.4 Procesamiento de registros\x0d\　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: \x0d\ Cliente de recopilación de registros, responsable de la recopilación de datos de registro, escritura regular y escritura en la cola de Kafka; \x0d\ Cola de mensajes de Kafka, responsable de recibir, almacenar y reenviar datos de registro; aplicación de procesamiento: suscripción y consume los datos de registro en la cola de Kafka \x0d\ Los siguientes son casos de aplicación de procesamiento de registros de Sina Kafka: \x0d\ (1) Kafka: cola de mensajes para recibir registros de usuarios. \x0d\　(2)Logstash: analice el registro, unifíquelo en JSON y envíelo a Elasticsearch. \x0d\　(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. \x0d\　(4)Kibana: un componente de visualización de datos basado en Elasticsearch. Las capacidades de visualización de datos súper son una razón importante por la que muchas empresas eligen la pila ELK. \x0d\　2.5 Comunicación de mensajes\x0d\　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. \x0d\ Comunicación punto a punto: \x0d\ El cliente A y el cliente B utilizan la misma cola para la comunicación de mensajes. \x0d\ Comunicación en la sala de chat: \x0d\ 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. \x0d\　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. \x0d\ 3. Ejemplo de middleware de mensajes \x0d\ 3.1 Sistema de comercio electrónico \x0d\ 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 nuevamente, asegurando así la integridad del mensaje) \x0d\　 (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. \x0d\　 (3) Si bien los mensajes desacoplan las aplicaciones, también provocan problemas de coherencia de los datos, que pueden resolverse utilizando 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. \x0d\ 3.2 Sistema de recopilación de registros \x0d\ Está dividido en cuatro partes: centro de registro de Zookeeper, cliente de recopilación de registros, clúster Kafka y clúster Storm (OtherApp). \x0d\ El centro de registro de Zookeeper propone servicios de equilibrio de carga y búsqueda de direcciones; \x0d\ El cliente de recopilación de registros se utiliza para recopilar registros del sistema de aplicaciones y enviar datos a la cola de Kafka \x0d\ 4. Servicio de mensajes JMS \x0d\ Cuando se habla de mensajes; colas, 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. \x0d\　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. \x0d\ 4.1 Modelo de mensaje \x0d\ En el estándar JMS, hay dos modelos de mensaje: P2P (Punto a punto) y Publicación/Suscripción (Pub/Sub). \x0d\ 4.1.1 Modo P2P \x0d\ El modo P2P incluye tres roles: cola de mensajes (Cola), remitente (Remitente) y receptor (Receptor). 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. \x0d\ Características de P2P \x0d\ Cada mensaje tiene un solo consumidor (es decir, una vez consumido, el mensaje ya no está en la cola de mensajes) \x0d\ No existe dependencia temporal entre el remitente y el receptor, es decir digamos, después de que el remitente envía un mensaje, independientemente de si el receptor se está ejecutando o no, no afectará el mensaje que se envía a la cola\x0d\ Si cada mensaje enviado se procesará exitosamente, entonces se requiere el modo P2P. (Arquitectura KKQ: 466097527, bienvenido a unirse) \x0d\ 4.1.2 Modo Pub/sub \x0d\ Contiene tres roles: Tema, Publicador y Suscriptor. Varios editores envían mensajes a un tema y el sistema entrega estos mensajes a varios suscriptores. \x0d\ Características de Pub/Sub \x0d\ Cada mensaje puede tener múltiples consumidores \x0d\ Existe una dependencia de tiempo entre los publicadores y los suscriptores. Para un suscriptor de un tema determinado (Tema), debe crear un suscriptor antes de poder consumir los mensajes del editor. \x0d\ Para consumir mensajes, el suscriptor debe permanecer en ejecución. \x0d\ 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. \x0d\ Si desea enviar un mensaje sin ningún procesamiento, o solo ser procesado por un remitente del mensaje, o puede ser procesado por varios consumidores, entonces puede usar el modelo Pub/Sub. \x0d\ 4.2 Consumo de mensajes \x0d\ 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. \x0d\　 (1) Los suscriptores o receptores \x0d\  síncronos reciben mensajes 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). \x0d\  (2) Suscriptor \x0d\  asíncrono O el receptor; puede registrarse como oyente de mensajes. Cuando llega el mensaje, el sistema llama automáticamente al método onMessage del oyente. \x0d\　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. \x0d\　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)\x0d\ 4.3 Modelo de programación JMS\x0d\ (1) ConnectionFactory\x0d\ Cree una fábrica para objetos de conexión. Para dos modelos de mensajes jms diferentes, existen QueueConnectionFactory y TopicConnectionFactory. Los objetos ConnectionFactory se pueden encontrar a través de JNDI. \x0d\　(2) Destino\x0d\　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); \x0d\ Por lo tanto, el Destino son en realidad dos tipos de objetos: Cola y Tema que se pueden encontrar a través de JNDI. \x0d\　(3) Conexión\x0d\　La conexión representa el vínculo establecido entre el cliente y el sistema JMS (empaquetado de 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. \x0d\　(4) Session\x0d\　Session 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. \x0d\　(5) Productor de mensajes\x0d\　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. \x0d\　(6) Consumidor de mensajes\x0d\　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. \x0d\　(7) MessageListener\x0d\　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. \x0d\　El estudio en profundidad de JMS es muy útil para dominar la arquitectura JAVA y 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. \x0d\ 5. Colas de mensajes de uso común \x0d\ Los contenedores comerciales generales, como WebLogic y JBoss, admiten el estándar JMS, que 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. \x0d\　5.1 ActiveMQ\x0d\　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. \x0d\ Las características de ActiveMQ son las siguientes: \x0d\ ⒈ Escribe clientes en múltiples idiomas y protocolos. Idiomas: Java, C, C++, C#, Ruby, Perl, Python, PHP. Protocolos de aplicación: OpenWire, Stomp REST, WS Notification, XMPP, AMQP\x0d\　⒉ Totalmente compatible con las especificaciones JMS1.1 y J2EE 1.4 (persistencia, integrado en un sistema mediante Spring y también compatible con las funciones de Spring 2.0 Permite que ActiveMQ se active automáticamente implementado en cualquier servidor comercial compatible con J2EE 1.4\x0d\　⒌ Admite múltiples protocolos de transporte: in-VM, TCP, SSL, NIO, UDP, JGroups, JXTA\x0d\　⒍ Admite aprovisionamiento de alta velocidad a través de JDBC y diario Persistencia de mensajes\x0d \　⒎ Diseñado para garantizar un clúster de alto rendimiento, cliente-servidor, punto a punto\x0d\　⒏ Soporte Ajax\x0d\　⒐ Soporte de integración con Axis\x0d\　⒑ Se puede llamar fácilmente proveedor JMS integrado, para pruebas\x0d\ 5.2 RabbitMQ\x0d\ 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. \x0d\ Varios conceptos importantes: \x0d\ Broker: En pocas palabras, es la entidad del servidor de cola de mensajes. \x0d\　Exchange: cambio de mensajes, que especifica las reglas según qué mensajes se enrutan a qué cola. \x0d\　Cola: Portador de la cola de mensajes, cada mensaje se colocará en una o más colas. \x0d\Binding: Enlace, su función es vincular el intercambio y la cola de acuerdo con las reglas de enrutamiento. \x0d\　Clave de enrutamiento: palabra clave de enrutamiento, Exchange entrega mensajes según esta palabra clave. \x0d\ 　vhost: host virtual. Se pueden abrir varios vhosts en un intermediario para separar los permisos de diferentes usuarios. \x0d\　Productor: El productor de mensajes es el programa que entrega los mensajes. \x0d\　consumer: El consumidor de mensajes es el programa que acepta mensajes.

\x0d\　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. \x0d\ El proceso de uso de la cola de mensajes es el siguiente: \x0d\ (1) El cliente se conecta al servidor de la cola de mensajes y abre un canal. \x0d\　(2) El cliente declara un intercambio y establece atributos relacionados. \x0d\　(3) El cliente declara una cola y establece atributos relacionados. \x0d\　(4) El cliente utiliza la clave de enrutamiento para establecer una relación vinculante entre el intercambio y la cola. \x0d\　 (5) El cliente entrega el mensaje para intercambiar. \x0d\ Después de que Exchange reciba el mensaje, lo enrutará según la clave del mensaje y el enlace que se ha establecido, y entregará el mensaje a una o más colas. \x0d\ 5.3 ZeroMQ\x0d\ 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 tiene una relación de extremo a extremo (relación 1:1). ), mientras que ZMQ puede tener una relación N:M. La gente sabe más sobre los sockets BSD desde las conexiones punto a punto que necesitan establecer conexiones explícitamente, destruir conexiones y seleccionar protocolos (TCP/UDP). y manejar errores, etc., mientras que ZMQ protege estos detalles y simplifica la programación de su red. ZMQ se utiliza para la comunicación entre nodos. Un nodo puede ser un host o un proceso. \x0d\ Citando la declaración oficial: "ZMQ (en adelante ZeroMQ se denominará ZMQ) es una capa de transporte simple y fácil de usar, una biblioteca de sockets como un marco. Hace que la programación de Sockets sea más simple, más concisa y más eficaz. Es una biblioteca de cola de procesamiento de mensajes que se escala elásticamente a través de 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". Sin duda, es una capa de empaquetado muy prometedora y más necesaria en los sockets BSD "tradicionales". ZMQ hace que escribir aplicaciones de red de alto rendimiento sea extremadamente fácil y divertido. "\x0d\" Las características son: \x0d\ Alto rendimiento, no. -persistente; \x0d\ Multiplataforma: compatible con Linux, Windows, OS X, etc. \x0d\　Soporte multilingüe; más de 30 lenguajes de desarrollo como C, C, Java, .NET y Python. \x0d\　Se puede implementar por separado o integrarse en aplicaciones; \x0d\　Se puede utilizar como una biblioteca de comunicación Socket. \x0d\ 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, que es una capa por encima de la API de Socket. abstrae la comunicación de red, la comunicación de procesos 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". \x0d\ Puntos de diseño de alto rendimiento de ZeroMQ: \x0d\ 1. Modelo de cola sin bloqueo \x0d\ Para la canalización del canal de intercambio de datos entre interacciones entre subprocesos (cliente y sesión), se utiliza 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. \x0d\ 2. Algoritmo de procesamiento por lotes \x0d\ Para el procesamiento de mensajes tradicional, cada mensaje requiere llamadas al sistema al enviar y recibir, por lo que para una gran cantidad de mensajes, la sobrecarga del sistema es relativamente grande y zeroMQ es adecuado para lotes Los mensajes han sido Optimizado de forma adaptativa y puede recibir y enviar mensajes en lotes.

\x0d\ 3. Enlace de subprocesos en multinúcleo sin cambio de CPU \x0d\ 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 está obligado a ejecutar un subproceso de trabajo. para evitar la sobrecarga de conmutación de la CPU entre varios subprocesos. \x0d\　5.4 Kafka\x0d\　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. \x0d\ Kafka es un sistema de mensajería de publicación-suscripción distribuido de alto rendimiento con las siguientes características: \x0d\ Proporciona persistencia de mensajes a través de una estructura de datos de disco O(1), que puede manejar incluso terabytes de mensajes. El almacenamiento también es capaz de mantener. rendimiento estable durante largos períodos de tiempo. (Los datos se escriben añadiendo archivos y los datos caducados se eliminan periódicamente) \x0d\ Alto rendimiento: incluso el hardware Kafka más común puede admitir millones de mensajes por segundo. \x0d\　 Admite la partición de mensajes a través del servidor Kafka y clústeres de máquinas de consumo. \x0d\　 Admite la carga de datos paralelos de Hadoop. \x0d\ 　Conceptos relacionados con Kafka\x0d\ Broker\x0d\ Un clúster de Kafka contiene uno o más servidores, que se denominan brokers[5]\x0d\ Categoría, esta categoría se llama 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. ) \x0d \Partition\x0d\ La partición es un concepto físico. Cada tema contiene una o más particiones.\x0d\ Producer\x0d\ Responsable de publicar mensajes al agente Kafka\x0d\ Consumer\x0d\ Consumidor de mensajes, leyendo del agente Kafka. El cliente que recibe el mensaje. \x0d\　Grupo de Consumidores\x0d\　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). \x0d\　 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).