RabbitMQ y relación entre canal y conexión

Este equipo redactor ha pasado mucho tiempo buscando respuestas a tus búsquedas, te ofrecemos la solución por eso nuestro objetivo es serte de mucha apoyo.

Solución:

1. A Connection representa una conexión TCP real con el intermediario de mensajes, mientras que un Channel hay una conexión virtual (conexión AMQP) dentro de él. De esta manera, puede usar tantas conexiones (virtuales) como desee dentro de su aplicación sin sobrecargar al corredor con conexiones TCP.

2. Puedes usar uno Channel para todo. Sin embargo, si tiene varios subprocesos, se sugiere utilizar un Channel para cada hilo.

   Seguridad de subprocesos de canal en la Guía de API de cliente Java:

   Las instancias de canal son seguras para que las utilicen varios subprocesos. Las solicitudes en un canal se serializan, y solo un hilo puede ejecutar un comando en el canal a la vez. Aun así, las aplicaciones deberían preferir usar un canal por hilo en lugar de compartir el mismo canal en varios hilos.

   No existe una relación directa entre Channel y Queue. A Channel se utiliza para enviar comandos AMQP al corredor. Puede ser la creación de una cola o algo similar, pero estos conceptos no están vinculados.

3. Cada Consumer se ejecuta en su propio subproceso asignado desde el grupo de subprocesos del consumidor. Si varios consumidores están suscritos a la misma cola, el corredor utiliza la operación por turnos para distribuir los mensajes entre ellos por igual. Consulte el Tutorial dos: “Colas de trabajo”.

   También es posible adjuntar el mismo Consumer a varias colas. Puede entender a los consumidores como devoluciones de llamada. Estos se denominan cada vez que llega un mensaje a una cola a la que está vinculado el consumidor. 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 normalmente haces es subclase DefaultConsumer y anular handleDelivery(...). Nota: Si adjunta la misma instancia de consumidor a varias colas, diferentes subprocesos llamarán a este método. Así que ocúpate de la sincronización si es necesario.

Una buena comprensión conceptual de lo que hace el protocolo AMQP “bajo el 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í es una con la que muchas personas tienen que luchar.

TL; DR

A 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, compartible entre subprocesos.

A canal es una única sesión de aplicación en la conexión. Un hilo tendrá una o más de estas sesiones. La arquitectura AMQP 0.9.1 es que estos no deben compartirse entre subprocesos y deben cerrarse / destruirse cuando el subproceso que lo creó haya terminado con él. El servidor también las cierra cuando se producen diversas infracciones de protocolo.

A 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 corredor que envíe mensajes desde una cola en particular al punto final de ese canal.

Hechos de conexión

Primero, como otros han señalado correctamente, una conexión es el objeto que representa la conexión TCP real al servidor. Las conexiones se especifican a nivel de protocolo en AMQP y toda la comunicación con el intermediario se realiza a través de una o más conexiones.

• Dado que es una conexión TCP real, tiene una dirección IP y un 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 apretón de manos.
• Está diseñado para ser longevo; Hay pocos casos en los que el cierre de la conexión es parte del diseño del protocolo.
• Desde una perspectiva OSI, probablemente reside en algún lugar alrededor de la Capa 6
• Los latidos se pueden configurar para monitorear el estado de la conexión, ya que TCP no contiene nada en sí mismo para hacer esto.
• Es mejor tener un subproceso dedicado que administre 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.
• En términos relativos, las conexiones son “caras” de crear (debido al apretón de manos), pero en la práctica, esto realmente no importa. La mayoría de los procesos realmente solo necesitarán un objeto de conexión. Sin embargo, puede mantener conexiones en un grupo, si encuentra que necesita más rendimiento del que puede proporcionar un solo hilo / socket (poco probable con la tecnología informática actual).

Datos del canal

A Canal es la sesión de la aplicación que se abre para que cada parte de su aplicación se comunique con el corredor de RabbitMQ. Opera sobre un solo conexión, y representa un sesión con el corredor.

• Como representa una parte lógica de la lógica de la aplicación, cada canal suele existir en su propio hilo.
• Por lo general, todos los canales abiertos por su aplicación compartirán una sola conexión (son sesiones ligeras que operan en la parte superior de la conexión). Las conexiones son seguras para subprocesos, por lo que está bien.
• La mayoría de las operaciones de AMQP se realizan a través de canales.
• Desde la perspectiva de la capa OSI, los canales probablemente estén alrededor de la capa 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).
• Dado que son transitorios, su aplicación no debe agrupar los canales.
• El servidor usa un número entero para identificar un canal. Cuando el hilo que administra la conexión recibe un paquete para un canal en particular, usa este número para decirle al corredor 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 corredor, se necesita un nuevo canal.

Hechos del consumidor

Un consumidor es un objeto definido por el protocolo AMQP. No es un canal ni una conexión, sino que es algo que su aplicación particular usa como una especie de “buzón” para dejar mensajes.

• “Crear un consumidor” significa que le dice al corredor (usando un canal a través de conexión) que le gustaría recibir mensajes a través de ese canal. En respuesta, el corredor registrará que tiene un consumidor en el canal y comience a enviarle mensajes.
• Cada mensaje enviado a través de la conexión hará referencia a un numero de canal y un número de consumidor. De esa manera, el subproceso de administración de conexiones (en este caso, dentro de la API de Java) sabe qué hacer con el mensaje; entonces, el subproceso 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í derivar 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 hilos de tareas para cada mensaje entregado a través del consumidor.
• Cerrando un conexión cierra todos los canales de la conexión. Cerrando un canal cierra a todos los consumidores del 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.
• Normalmente, 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ódigo (incluida la publicación).

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

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

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

Algunas aplicaciones necesitan múltiples conexiones a un agente AMQP. Sin embargo, no es deseable mantener abiertas muchas conexiones TCP al mismo tiempo porque hacerlo consume recursos del sistema y dificulta la configuración de firewalls. Las conexiones AMQP 0-9-1 se multiplexan con canales que pueden considerarse como “conexiones ligeras que comparten una única conexión TCP”.

Para las aplicaciones que utilizan múltiples subprocesos / 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 usan para determinar para qué canal es el método (y, por lo tanto, qué controlador de eventos debe invocarse, por ejemplo). .

valoraciones y reseñas

Tienes la opción de corroborar nuestra publicación añadiendo un comentario o puntuándolo te estamos agradecidos.

---

---

Utiliza Nuestro Buscador