java - how - rabbitmq python

RabbitMQ y relación entre el canal y la conexión (3)

Una Connection representa una conexión TCP real al intermediario de mensajes, mientras que un Channel es una conexión virtual (conexión AMPQ) dentro de ella. De esta forma, puede usar tantas conexiones (virtuales) como desee dentro de su aplicación sin sobrecargar al intermediario con las conexiones TCP.
Puedes usar un Channel para todo. Sin embargo, si tiene varios hilos, se sugiere utilizar un Channel diferente para cada hilo.
Canal de seguridad de subprocesos en Java Client API Guide :
Las instancias de canal son seguras para su uso por múltiples hilos. Las solicitudes en un canal se serializan, con un solo subproceso que puede ejecutar un comando en el canal a la vez. Aun así, las aplicaciones deberían preferir usar un canal por subproceso en lugar de compartir el mismo canal en varios subprocesos.
No hay una relación directa entre Channel y Queue . Un Channel se usa para enviar comandos de AMQP al intermediario. Esto puede ser la creación de una cola o similar, pero estos conceptos no están vinculados.
Cada Consumer ejecuta su propio hilo asignado desde el grupo de subprocesos de consumidor. Si hay varios consumidores suscritos a la misma cola, el intermediario utiliza round-robin para distribuir los mensajes entre ellos por igual. Consulte el Tutorial dos: "Colas de trabajo" .
También es posible adjuntar el mismo Consumer a múltiples colas. Puede entender a los consumidores como devoluciones de llamada. Estos se llaman cada vez que llega un mensaje en una cola a la que el consumidor está obligado. Para el caso del Cliente Java, cada Consumidor tiene un método handleDelivery(...) , que representa el método de devolución de llamada. Lo que suele hacer es, subclase DefaultConsumer y anular handleDelivery(...) . Nota: Si adjunta la misma instancia de Consumer a varias colas, este método será llamado por diferentes subprocesos. Así que ten cuidado con la sincronización si es necesario.

El cliente RabbitMQ Java tiene los siguientes conceptos:

Connection : una conexión a una instancia del servidor RabbitMQ
Channel - ???
Grupo de subprocesos del consumidor: un conjunto de subprocesos que consumen mensajes de las colas del servidor RabbitMQ
Queue - una estructura que contiene mensajes en orden FIFO

Intento entender la relación, y más importante , las asociaciones entre ellos.

Todavía no estoy seguro de qué es un Channel , aparte del hecho de que esta es la estructura que publica y consume, y que se crea a partir de una conexión abierta. Si alguien pudiera explicarme qué representa el "Canal", podría ayudar a aclarar algunas cosas.
¿Cuál es la relación entre Channel y Queue? ¿Se puede usar el mismo canal para comunicarse con Colas múltiples, o tiene que ser 1: 1?
¿Cuál es la relación entre Queue y Consumer Pool? ¿Pueden suscribirse varios consumidores a la misma cola? ¿Pueden consumirse varias colas por el mismo consumidor? ¿O es la relación 1: 1?

Gracias de antemano por cualquier ayuda aquí!

Encontré este artículo que explica todos los aspectos del modelo AMQP, de los cuales, el canal es uno. Me pareció muy útil para completar mi comprensión

https://www.rabbitmq.com/tutorials/amqp-concepts.html

Algunas aplicaciones necesitan conexiones múltiples con un intermediario de AMQP. Sin embargo, no es aconsejable mantener abiertas muchas conexiones TCP al mismo tiempo porque al hacerlo consume recursos del sistema y hace que sea más difícil configurar firewalls. Las conexiones AMQP 0-9-1 se multiplexan con canales que pueden considerarse como "conexiones livianas que comparten una única conexión TCP".
Para las aplicaciones que usan múltiples hilos / procesos para el procesamiento, es muy común abrir un nuevo canal por subproceso / proceso y no compartir canales entre ellos.
La comunicación en un canal en particular está completamente separada de la comunicación en otro canal, por lo tanto, cada método AMQP también lleva un número de canal que los clientes utilizan para determinar para qué canal es el método (y por lo tanto, qué controlador de eventos necesita invocarse, por ejemplo) .

Una buena comprensión conceptual de lo que hace el protocolo AMQP "debajo del capó" es útil aquí. Yo ofrecería que la documentación y la API que AMQP 0.9.1 eligió implementar hace que esto sea particularmente confuso, por lo que la pregunta en sí misma es una con la que mucha gente tiene que luchar.

TL; DR

Una conexión es el socket TCP negociado físico con el servidor AMQP. Los clientes implementados correctamente tendrán uno de estos por aplicación, seguro para subprocesos y compartible entre subprocesos.

Un canal es una sesión de aplicación única en la conexión. Un hilo tendrá una o más de estas sesiones. AMQP architecture 0.9.1 es que estos no se deben compartir entre hilos, y deben cerrarse / destruirse cuando el hilo que lo creó haya terminado. También están cerrados por el servidor cuando ocurren varias violaciones de protocolo.

Un consumidor es una construcción virtual que representa la presencia de un "buzón" en un canal en particular. El uso de un consumidor le dice al agente que envíe los mensajes de una cola particular a ese punto final del canal.

Hechos de conexión

Primero, como otros señalaron correctamente, una conexión es el objeto que representa la conexión TCP real al servidor. Las conexiones se especifican en el nivel de protocolo en AMQP, y todas las comunicaciones con el intermediario ocurren en una o más conexiones.

Como es una conexión TCP real, tiene una dirección IP y número de puerto.
Los parámetros de protocolo se negocian por cliente como parte de la configuración de la conexión (un proceso conocido como handshake) .
Está diseñado para ser de larga duración ; hay pocos casos donde el cierre de la conexión es parte del diseño del protocolo.
Desde una perspectiva OSI, probablemente se encuentre en algún lugar alrededor de Layer 6
Los latidos del corazón se pueden configurar para monitorear el estado de la conexión, ya que TCP no contiene nada en sí mismo para hacer esto.
Lo mejor es tener un hilo dedicado administrar las lecturas y escrituras en el socket TCP subyacente. La mayoría, si no todos, los clientes de RabbitMQ hacen esto. En ese sentido, generalmente son seguros para subprocesos.
Relativamente hablando, las conexiones son "costosas" de crear (debido al apretón de manos), pero prácticamente hablando, esto realmente no importa. La mayoría de los procesos realmente solo necesitarán un objeto de conexión. Sin embargo, puede mantener las conexiones en un grupo, si cree que necesita más rendimiento que el que puede proporcionar un solo subproceso / socket (poco probable con la tecnología informática actual).

Hechos del canal

Un canal es la sesión de aplicación que se abre para cada parte de su aplicación para comunicarse con el intermediario RabbitMQ. Opera sobre una única conexión y representa una sesión con el intermediario.

Como representa una parte lógica de la lógica de la aplicación, cada canal generalmente existe en su propio hilo.
Por lo general, todos los canales abiertos por su aplicación compartirán una sola conexión (son sesiones livianas que operan en la parte superior de la conexión). Las conexiones son seguras para hilos, así que esto está bien.
La mayoría de las operaciones de AMQP se realizan a través de canales.
Desde la perspectiva de OSI Layer, los canales probablemente están alrededor de Layer 7 .
Los canales están diseñados para ser transitorios ; Parte del diseño de AMQP es que el canal normalmente se cierra en respuesta a un error (por ejemplo, volver a declarar una cola con diferentes parámetros antes de eliminar la cola existente).
Debido a que son transitorios, tu aplicación no debe agrupar los canales.
El servidor usa un número entero para identificar un canal. Cuando el hilo que gestiona la conexión recibe un paquete para un canal en particular, utiliza este número para decirle al intermediario a qué canal / sesión pertenece el paquete.
Los canales generalmente no son seguros para subprocesos, ya que no tendría sentido compartirlos entre subprocesos. Si tiene otro hilo que necesita usar el intermediario, se necesita un nuevo canal.

Datos del consumidor

Un consumidor es un objeto definido por el protocolo AMQP. No es ni un canal ni una conexión, sino que es algo que su aplicación particular utiliza como un "buzón" de tipos para soltar mensajes.

"Crear un consumidor" significa que le dices al intermediario (utilizando un canal a través de una conexión ) que deseas que te envíen mensajes por ese canal. En respuesta, el intermediario registrará que tiene un consumidor en el canal y comenzará a enviarle mensajes.
Cada mensaje enviado sobre la conexión hará referencia tanto a un número de canal como a un número de consumidor . De esta forma, el hilo de gestión de conexión (en este caso, dentro de la API de Java) sabe qué hacer con el mensaje; luego, el hilo de manejo de canales también sabe qué hacer con el mensaje.
La implementación del consumidor tiene la mayor cantidad de variación, porque es literalmente específica de la aplicación. En mi implementación, elegí separar una tarea cada vez que llegaba un mensaje a través del consumidor; por lo tanto, tenía un hilo que administraba la conexión, un hilo que administraba el canal (y por extensión, el consumidor) y uno o más subprocesos de tareas para cada mensaje entregado a través del consumidor.
Al cerrar una conexión, se cierran todos los canales de la conexión. Al cerrar un canal, se cierra a todos los consumidores en el canal. También es posible cancelar un consumidor (sin cerrar el canal). Hay varios casos en los que tiene sentido hacer cualquiera de las tres cosas.
Típicamente, la implementación de un consumidor en un cliente AMQP asignará un canal dedicado al consumidor para evitar conflictos con las actividades de otros hilos o códigos (incluida la publicación).

En términos de lo que quiere decir con grupo de subprocesos de consumidor, sospecho que el cliente de Java está haciendo algo similar a lo que programé a mi cliente (el mío se basó en el cliente .Net, pero muy modificado).