Aquí es útil una buena comprensión conceptual de lo que hace el protocolo AMQP "bajo el capó". 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
Una conexión es el socket TCP físico negociado con el servidor AMQP. Los clientes implementados correctamente tendrán uno de estos por aplicación, seguro para subprocesos, 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. La arquitectura 0.9.1 de AMQP es que no deben compartirse entre los subprocesos, y deben cerrarse / destruirse cuando el subproceso que lo creó termina con él. El servidor también los cierra cuando se producen 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 intermediario que envíe mensajes desde una cola particular a ese punto final del canal.
Datos 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 comunicación con el intermediario se realiza a través de una o más conexiones.
- Como se trata de 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 protocolo de enlace) .
- Está diseñado para ser de larga duración ; 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 hilo 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.
- Relativamente hablando, las conexiones son "caras" 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 encuentra que necesita más rendimiento del que puede proporcionar un solo subproceso / socket (poco probable con la tecnología informática actual).
Datos del canal
Un 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 RabbitMQ. Funciona a través de 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 sobre 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).
- Como 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 gestiona la conexión recibe un paquete para un canal en particular, utiliza este número para decirle al agente 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.
Datos 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 utiliza como un "buzón" para colocar mensajes.
- "Crear un consumidor" significa que usted le dice al corredor (usando un canal a través de una conexión ) que desea que le envíen mensajes a través de ese canal. En respuesta, el corredor registrará que tiene un consumidor en el canal y comenzará a enviarle mensajes.
- Cada mensaje enviado a través de la conexión hará referencia tanto a un número de canal como a un número de consumidor . De esa manera, el hilo de gestión de la conexión (en este caso, dentro de la API de Java) sabe qué hacer con el mensaje; entonces, 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í desviar 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.
- Cerrar una conexión cierra todos los canales en la conexión. Cerrar un canal 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.
- Por lo general, 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 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).
