Escenarios de uso de la cola de mensajes
El middleware de cola de mensajes es un componente importante en los sistemas distribuidos y resuelve principalmente problemas como el acoplamiento de aplicaciones, la mensajería asincrónica, la reducción de picos y el llenado de valles. Logre un alto rendimiento, alta disponibilidad, escalabilidad y, en última instancia, una arquitectura consistente.
- Desacoplamiento: varios servicios monitorean y procesan el mismo mensaje para evitar múltiples llamadas RPC.
- Mensajes asincrónicos: el editor del mensaje no tiene que esperar el resultado del procesamiento del mensaje.
- Reducción de picos y llenado de valles: escenarios de escritura y tráfico grande para resistir el tráfico de servicios de E/S descendentes. Por supuesto, cuando hay mucho tráfico, es necesario utilizar otras soluciones.
- Marco basado en mensajes: en el bus de eventos, los servicios controlan los servicios escuchando los mensajes de eventos para completar las acciones correspondientes.
Patrón de cola de mensajes
Modo punto a punto, sin consumo repetido
Varios productores pueden enviar mensajes a la misma cola de mensajes. Una vez que un productor de mensajes consume con éxito un mensaje, el mensaje se eliminará y otros consumidores no podrán procesarlo. Si el consumidor no puede procesar un mensaje, el mensaje se consumirá nuevamente.
modelo de publicación/suscripción
El modelo de publicación-suscripción requiere registro y suscripción, y los mensajes correspondientes se consumen según el registro. Varios productores pueden escribir mensajes sobre el mismo tema y el mismo consumidor puede consumir varios mensajes. Los mensajes producidos por un productor también pueden ser consumidos por varios consumidores, siempre que se hayan suscrito al mensaje.
Referencia de selección
- Orden de los mensajes: si se puede garantizar el orden de consumo de los mensajes enviados a la cola cuando se consumen;
- Escalado: cuando hay un problema con el rendimiento de la cola de mensajes, como un consumo demasiado lento, si puede admitir la expansión rápidamente; cuando hay demasiadas colas de consumo, lo que desperdicia recursos del sistema, si puede admitir la reducción.
- Retención de mensajes: una vez que el mensaje se consume con éxito, se continuará reteniendo en la cola de mensajes;
- Tolerancia a fallos: cuando un mensaje no se consume, ¿existe algún mecanismo para garantizar que el mensaje se realice correctamente? Por ejemplo, un mensaje de reembolso asincrónico de terceros debe garantizar que el mensaje se consuma antes de que se pueda realizar el reembolso al usuario. Se determina que tiene éxito, por lo que se debe garantizar La precisión del consumo exitoso de este mensaje;
- Fiabilidad del mensaje: ¿se perderá algún mensaje? Por ejemplo, si hay dos mensajes A/B, solo se puede consumir el mensaje B y se pierde el mensaje A;
- Temporización del mensaje: incluye principalmente "tiempo de supervivencia del mensaje" y "mensaje retrasado";
- Rendimiento: el número máximo de concurrencias admitidas;
- Enrutamiento de mensajes: de acuerdo con las reglas de enrutamiento, suscríbase solo a los mensajes que coincidan con las reglas de enrutamiento. Por ejemplo, si hay mensajes con ambas reglas A/B, los consumidores solo pueden suscribirse a los mensajes A y los mensajes B no se consumirán.
kafka
Kafka es una plataforma de procesamiento de flujos de código abierto desarrollada por Apache Software Foundation y escrita en Scala y Java. El objetivo de este proyecto es proporcionar una plataforma unificada, de alto rendimiento y baja latencia para procesar datos en tiempo real. Su capa de persistencia es esencialmente una "cola de mensajes de publicación/suscripción a gran escala basada en una arquitectura de registro de transacciones distribuidas", lo que la hace valiosa como infraestructura de nivel empresarial para procesar datos en streaming. (Wikipedia)
terminología básica
Productor : productor de mensajes. Normalmente, se envía un mensaje a un tema específico. Normalmente, los mensajes escritos se escriben en cada partición mediante sondeo. El productor también puede escribir mensajes en la partición especificada estableciendo el valor de la clave del mensaje. Cuanto más uniformemente sean los datos escritos en las particiones, mejor será el rendimiento de Kafka.
Tema : El tema es un concepto virtual abstracto. Un grupo puede tener varios temas, que sirven como identificador de un tipo de mensaje. Un productor envía mensajes a un tema y los consumidores obtienen mensajes particionados suscribiéndose al tema.
Partición : la partición es un concepto físico y un tema corresponde a una o más particiones. Los mensajes nuevos se escribirán en la partición de forma adjunta y los mensajes en la misma partición se ordenarán. Kafka logra redundancia y escalabilidad de mensajes a través de la partición y admite lectura y escritura físicas simultáneas, lo que mejora enormemente el rendimiento.
Réplicas : una partición tiene múltiples réplicas. Estas copias se almacenan en el corredor. Cada corredor almacena cientos o miles de copias de diferentes temas y particiones. El contenido almacenado se divide en dos tipos: copia maestra. Cada partición tiene una copia maestra y todo el contenido se escribe y consume. Todo pasará por la copia maestra; la copia seguidora no procesa ninguna solicitud del cliente y solo sincroniza el contenido de la copia maestra para la replicación. Si ocurre una excepción en el maestro, un seguidor pronto se convertirá en el nuevo maestro.
Consumidor : lector de mensajes. Los consumidores se suscriben a temas y leen mensajes en un orden determinado. Kafka garantiza que cada partición solo puede ser utilizada por un consumidor.
Desplazamiento : el desplazamiento es un tipo de metadato, que es un número entero creciente. Kafka lo añade al mensaje tal como está escrito. Las compensaciones son únicas dentro de una partición. Durante el proceso de consumo, el último offset leído se almacenará en Kafka. El offset no se perderá cuando el consumidor cierre. El reinicio continuará con el consumo desde la última posición.
Broker : servidor Kafka independiente. Un tema tiene N particiones y un clúster tiene N corredores. Luego, cada corredor almacenará una partición de este tema. Si un tema tiene N particiones y el clúster tiene (N+M) intermediarios, entonces N intermediarios almacenan una partición del tema y los M intermediarios restantes no almacenan datos de partición del tema. Si un tema tiene N particiones y el número de intermediarios en el clúster es menor que N, entonces un intermediario almacena una o más particiones del tema. En entornos de producción reales, intente evitar esta situación, que puede provocar fácilmente un desequilibrio en los datos del clúster Kafka.
marco del sistema
El primer tema tiene dos producciones: los mensajes nuevos se escriben en la partición 1 o en la partición 2. Ambas particiones tienen copias de seguridad en broker1 y broker2. Después de escribir nuevos mensajes, las dos particiones seguidoras sincronizarán los cambios de las dos particiones maestras. El consumidor correspondiente obtendrá mensajes de las dos particiones maestras en función del desplazamiento actual y actualizará el desplazamiento. El segundo tema tiene un solo productor, que también corresponde a dos particiones y se distribuye en los dos intermediarios del clúster de Kafka. Cuando se escriben nuevos mensajes, las dos particiones seguidoras sincronizarán los cambios maestros. Los dos consumidores obtienen mensajes de diferentes particiones maestras.
ventaja
Alto rendimiento, baja latencia : Kafka puede procesar cientos de miles de mensajes por segundo y su latencia es tan baja como unos pocos milisegundos;
Escalabilidad : el clúster Kafka admite la expansión en caliente;
Durabilidad y confiabilidad : los mensajes se conservan en el disco local y se admite la copia de seguridad de datos para evitar la pérdida de datos;
Tolerancia a fallas : permite fallas de nodos en el clúster, múltiples copias de un dato y algunas máquinas fallan sin perder datos;
Alta concurrencia : admite miles de clientes leyendo y escribiendo al mismo tiempo.
defecto
Orden de partición : el orden solo se garantiza dentro de la misma partición y no se puede lograr el orden global;
Sin mensajes retrasados : el orden de consumo está en el orden de escritura y no se admiten mensajes retrasados
Consumo repetido : el sistema de consumo está inactivo o reiniciado, lo que hace que no se envíe la compensación;
Reequilibrio : durante el proceso de reequilibrio, todas las instancias de consumidores del grupo de consumidores dejarán de funcionar y esperarán a que se complete el proceso de reequilibrio.
escenas a utilizar
Recopilación de registros : Primero se escribe una gran cantidad de mensajes de registro en Kafka y el servicio de datos almacena los datos consumiendo mensajes de Kafka;
Sistema de mensajes : desacoplamiento de productores y consumidores, almacenamiento en caché de mensajes, etc.;
Seguimiento de la actividad del usuario : Kafka se utiliza a menudo para registrar diversas actividades de los usuarios de la web o de la aplicación, como navegar por la web, buscar, hacer clic y otras actividades. Esta información de actividad es publicada por varios servidores en temas de Kafka y luego los consumidores se suscriben a estos. temas Se puede utilizar para monitoreo y análisis en tiempo real, y también se puede guardar en la base de datos;
Indicadores de operación : registra datos de operación y monitoreo, incluida la recopilación de datos de varias aplicaciones distribuidas y la producción de retroalimentación centralizada para diversas operaciones, como alarmas e informes;
Procesamiento de transmisión : como transmisión por chispa.
ConejoMQ
RabbitMQ es un software de intermediario de mensajes de código abierto (también conocido como middleware orientado a mensajes) que implementa el protocolo avanzado de cola de mensajes (AMQP). El servidor RabbitMQ está escrito en el lenguaje Erlang y la agrupación en clústeres y la conmutación por error se basan en Open Marco de plataforma de telecomunicaciones. Todos los principales lenguajes de programación tienen bibliotecas de cliente para comunicarse con la interfaz del agente (Wikipedia).
terminología básica
Broker : recibe entidades de enlace de cliente e implementa funciones de enrutamiento y cola de mensajes AMQP;
Host virtual : es un concepto virtual y la unidad más pequeña de control de permisos. Un host virtual contiene múltiples intercambios y colas;
Exchange : recibe mensajes de productores de mensajes y los reenvía a colas. Al enviar mensajes, las reglas de enrutamiento se determinan de acuerdo con diferentes ExchangeTypes. Los ExchangeTypes más utilizados son: directo, fanout y topic;
Cola de mensajes : cola de mensajes, almacenada como mensajes consumidos;
Mensaje : consta de encabezado y cuerpo. El encabezado son varios atributos agregados por el productor, incluido si el mensaje persiste, qué MessageQueue lo recibe y la prioridad. El cuerpo es el contenido específico del mensaje;
Enlace : el enlace conecta Exchange y Message Queue. Cuando el servidor se está ejecutando, se generará una tabla de enrutamiento que registra las condiciones de MessageQueue y el valor BindingKey. Cuando Exchange recibe el mensaje, analizará el encabezado del mensaje para obtener BindingKey y enviará el mensaje al MessageQueue correspondiente según la tabla de enrutamiento y ExchangeType. El modo de coincidencia final está determinado por ExchangeType;
Conexión : Conexión TCP entre el Broker y el cliente;
Canal : canal. El Broker y el cliente no pueden enviar mensajes si solo tienen una conexión tcp y se debe crear un canal. El protocolo AMQP estipula que los comandos AMQP solo se pueden ejecutar a través del Canal. Una conexión puede contener varios canales. La razón por la que es necesario establecer un canal es porque cada conexión TCP es valiosa. Si cada cliente y cada hilo necesita interactuar con el Broker y mantener una conexión TCP, la máquina consumirá recursos, generalmente se recomienda compartir la Conexión. RabbitMQ no recomienda que los hilos del cliente compartan canales antes, al menos asegúrese de que se atraviesen los mensajes pequeños enviados en el mismo canal;
Comando : comando AMQP. El cliente utiliza el comando para completar la interacción con el servidor AMQP.
Information Direct: ruta de aprendizaje de tecnología del código fuente del kernel de Linux + video tutorial sobre el código fuente del kernel
Learning Express: Código fuente del kernel de Linux Ajuste de memoria Sistema de archivos Gestión de procesos Controlador de dispositivo/Pila de protocolo de red
marco del sistema
Un mensaje llega al Exchange correspondiente a través del canal. Después de recibir el mensaje, Exchange analiza el contenido del encabezado del mensaje, obtiene el mensaje BindingKey y reenvía el mensaje al MessageQueue correspondiente según Binding y ExchangeType, y finalmente transmite el mensaje al cliente a través del canal. Conexión.
Tipo de intercambio
Directo: coincidencia exacta
- Solo cuando RoutingKey y BindingKey coinciden completamente, la cola de mensajes puede obtener el mensaje;
- El Broker proporciona un Exchange de forma predeterminada. El tipo es Directo y el nombre es una cadena vacía. Está vinculado a todas las colas (que se distinguen aquí por los nombres de las colas).
Fanout: suscripción, transmisión
- Este modo reenviará el mensaje a todas las colas de enrutamiento.
Tema: patrón comodín
- RoutingKey es una cadena separada por puntos "." (cada cadena independiente separada por puntos "." se llama palabra), como "quick.orange.rabbit". BindingKey es lo mismo que RoutingKey;
- Los dos caracteres especiales "#" y "_" en Bindingkey se usan para coincidencias aproximadas, "#" se usa para hacer coincidir varias palabras individuales y "_" se usa para hacer coincidir una sola palabra (incluido el cero).
ventaja
- Basado en el protocolo AMQP: además de Qpid, RabbitMQ es el único servidor de mensajes que implementa el estándar AMQP;
- Robusto, estable y fácil de usar;
- Comunidad activa y documentación completa;
- Admite mensajes programados;
- Autenticación conectable, autorización, soporte para TLS y LDAP;
- Admite la consulta de mensajes según identificadores de mensajes y la consulta de mensajes según el contenido del mensaje.
defecto
- El código fuente de desarrollo de Erlang es difícil de entender, lo que no favorece el desarrollo y mantenimiento secundarios;
- Las interfaces y protocolos son complejos y los costos de aprendizaje y mantenimiento son altos.
Resumir
- Erlang tiene ventajas de concurrencia y mejor rendimiento. Aunque el código fuente es complejo, la comunidad es muy activa y puede resolver los problemas encontrados durante el desarrollo;
- Si el tráfico empresarial no es grande, puede elegir RabbitMQ, que tiene funciones relativamente completas.
Púlsar
Apache Pulsar es el proyecto principal de Apache Software Foundation. Es una plataforma de flujo de mensajes distribuidos nativa de la nube de próxima generación que integra mensajería, almacenamiento y computación funcional liviana. Adopta un diseño de arquitectura de separación de computación y almacenamiento y admite multiinquilino. , almacenamiento persistente, replicación de datos interregionales en salas de máquinas múltiples, tiene características de almacenamiento de datos en tiempo real, como gran consistencia, alto rendimiento, baja latencia y alta escalabilidad, y se considera la mejor solución para la transmisión, el almacenamiento y la computación en tiempo real de mensajes en tiempo real. en la era nativa de la nube. Pulsar es un sistema de cola de mensajes modelo pub-sub (publicación-suscripción). (enciclopedia)
terminología básica
Propiedad : representa al inquilino. Cada propiedad puede representar un equipo, una función y una línea de productos. Una propiedad puede contener varios espacios de nombres. El arrendamiento múltiple es un método de aislamiento de recursos que puede mejorar la utilización de los recursos;
Espacio de nombres : La unidad de gestión básica de Pulsar. Los permisos, TTL de mensajes, políticas de retención, etc. se pueden configurar en el nivel de espacio de nombres. Todos los temas de un espacio de nombres heredan la misma configuración. Hay dos tipos de espacios de nombres: el espacio de nombres local, que sólo es visible dentro del clúster, y el espacio de nombres global, que es visible para varios clústeres.
Productor : Productor de datos, responsable de crear mensajes y entregarlos a Pulsar;
Consumidor : Consumidor de datos, conectado a Pulsar para recibir mensajes y procesarlos en consecuencia;
Broker : Servicio de proxy sin estado, responsable de operaciones como recibir mensajes, entregar mensajes y equilibrar la carga del clúster, protege al cliente de la complejidad del proceso de lectura y escritura del lado del servidor y desempeña un papel importante para garantizar la coherencia de los datos. balanceo de carga. El corredor no conserva los metadatos. Se puede ampliar pero no reducir;
BookKeeper : con estado, responsable del almacenamiento persistente de mensajes. Cuando se expande el clúster, Pulsar agregará BookKeeper y Segment (es decir, Bookeeper's Ledger), y no es necesario realizar un reequilibrio durante la expansión como Kafka. El resultado de la expansión es que los fragmentos se distribuyen en tiras entre varias casas de apuestas. Los fragmentos del mismo libro mayor se distribuyen en varias casas de apuestas, lo que hace que las lecturas y escrituras salten entre varias casas de apuestas;
ZooKeeper : almacena metadatos de Pulsar y BookKeeper, configuración del clúster y otra información, y es responsable de la coordinación entre clústeres, descubrimiento de servicios, etc.;
Tema : se utiliza para transmitir mensajes del productor al consumidor. Pulsar tiene un corredor líder a nivel de tema, que se dice que es propietario del tema. Todo el R/W para este tema se completa a través de este corredor. Los metadatos, como la relación de mapeo entre el libro mayor del tema y el fragmento, se almacenan en Zookeeper, y Pulsar Broker necesita rastrear estas relaciones en tiempo real para los procesos de lectura y escritura;
Libro mayor : segmento, los datos subyacentes de Pulsar se almacenan en BookKeeper en forma de libro mayor. Es la unidad más pequeña eliminada por Pulsar;
Fragmento : cada libro mayor consta de varios fragmentos.
marco del sistema
El diagrama de marco anterior demuestra las dos situaciones de expansión de capacidad y conmutación por error, respectivamente. Expansión: debido al aumento en el volumen de negocios, se agrega un nuevo corredor de apuestas N, y los datos escritos posteriormente, el segmento x y el segmento y se escriben en el corredor de apuestas recién agregado. Para mantener un resultado de expansión de capacidad equilibrado, el resultado se muestra en verde módulo en la figura anterior. Conmutación por error: si el segmento 4 de Bookie 2 falla, el tema de Pulasr volverá a seleccionar inmediatamente Bookie 1 como el servicio para manejar la lectura y la escritura.
Broker es un servicio sin estado que solo sirve para cálculo de datos y no para almacenamiento, por lo que Pulsar puede considerarse un sistema distribuido basado en Proxy.
ventaja
- Expansión flexible
- Recuperación de fallos sin problemas
- Admite mensajes retrasados
- Función de replicación incorporada para replicación interregional, como recuperación ante desastres
- Soporta dos modelos de consumo: stream (modo exclusivo) y cola (modo compartido)
cohetemq
RocketMQ es una plataforma distribuida de mensajería y transmisión de datos con baja latencia, alto rendimiento, alta confiabilidad, capacidad de un billón de niveles y escalabilidad flexible. RocketMQ es el middleware de mensajería distribuida de tercera generación de código abierto de Alibaba en 2012. (Wikipedia)
terminología básica
Tema : Un tema puede tener 0, 1 o varios productores que le envíen mensajes. Un productor también puede enviar mensajes a diferentes temas al mismo tiempo. Un tema también puede ser suscrito por 0, 1 o varios consumidores;
Etiqueta : un tipo secundario de mensaje, que puede proporcionar a los usuarios flexibilidad adicional. Un mensaje no puede tener etiqueta;
Productor : productor de mensajes;
Broker : almacena mensajes, una cola liviana con el Tema como latitud, reenvía mensajes, un solo nodo Broker mantiene conexiones largas y latidos con todos los nodos de NameServer y registra regularmente información de Tema en NameServer;
Consumidor : Consumidor de mensajes, responsable de recibir y consumir mensajes;
MessageQueue : la unidad de gestión física de mensajes. Un tema puede tener varias colas. La introducción de colas permite capacidades de expansión horizontal;
NameServer : Responsable de la gestión de los datos originales, incluido el tema y la información de enrutamiento.No hay comunicación entre cada NameServer;
Grupo : Un grupo puede suscribirse a múltiples temas. ProducerGroup y ConsumerGroup son un tipo de productor y un tipo de consumidor respectivamente;
Offset : acceda a la unidad de almacenamiento a través de Offset.Todos los mensajes en RocketMQ son persistentes y la unidad de almacenamiento tiene una longitud fija. Offset es un tipo Java Long y, en teoría, no se desbordará en 100 años, por lo que Message Queue se considera datos infinitamente largos y Offset es un subíndice;
Consumidor : Admite dos modos de consumo: PUSH y PULL, y admite consumo de clúster y consumo de transmisión.
marco del sistema
ventaja
Admite modelos de mensajería de publicación/suscripción (Pub/Sub) y punto a punto (P2P):
- Cola secuencial: primero en entrar, primero en salir (FIFO) confiable y entrega secuencial estricta en una cola; admite modos de mensajes pull y push;
- La capacidad de acumular millones de mensajes en una sola cola;
- Admite múltiples protocolos de mensajería, como JMS, MQTT, etc.;
- Arquitectura distribuida de escalamiento horizontal;
- Satisfacer al menos una vez la semántica de entrega de mensajes;
- Proporciona un panel completo, que incluye configuración, indicadores y monitoreo;
- Los clientes admitidos actualmente son java, c++ y golang.
defecto
- La actividad comunitaria es promedio;
- Mensaje retrasado: la versión de código abierto no admite precisión de tiempo arbitraria, solo niveles específicos.
escenas a utilizar
- Nació para el campo de Internet financiero y escenarios que requieren alta confiabilidad.
Autor original: Renacimiento Geek
