He encontrado esto en el rabbitmq website está cerca de la parte inferior, así que he citado la parte correspondiente a continuación.
La versión de tl; dr es que debe tener 1 conexión por aplicación y 1 canal por subproceso. Espero que ayude.
Conexiones
conexiones AMQP son típicamente vivían largo. AMQP es un protocolo de nivel de aplicación que usa TCP para una entrega confiable. Las conexiones AMQP usan autenticación y se pueden proteger con TLS (SSL). Cuando una aplicación ya no necesita estar conectada a un intermediario AMQP, debe cerrar con gracia la conexión AMQP en lugar de abruptamente cerrar la conexión TCP subyacente.
Canales
Algunas aplicaciones necesitan múltiples conexiones a un corredor de AMQP. Sin embargo, no es aconsejable mantener abiertas muchas conexiones TCP en el al mismo tiempo porque hacerlo consume recursos del sistema y hace que sea más difícil configurar firewalls. Las conexiones AMQP 0-9-1 son multiplexadas con canales que pueden considerarse como "conexiones ligeras que comparten una única conexión TCP".
Para las aplicaciones que usan múltiples hilos/procesos para procesar, es muy común abrir un nuevo canal por subproceso/proceso y no compartir canales entre ellos.
comunicación en un canal particular está completamente separada de comunicación en otro canal, por lo tanto todos los métodos AMQP también lleva un número de canal que los clientes usan para averiguar qué canal el método es para (y por lo tanto, que necesita de controlador de eventos para ser invocado, por ejemplo).
Se recomienda que haya 1 canal por subproceso, aunque son seguros para subprocesos, por lo que podría enviar varios subprocesos a través de un canal. En términos de su aplicación, le sugiero que se quede con 1 canal por hilo.
Además, se recomienda tener solo 1 consumidor por canal.
Estas son solo pautas, por lo que tendrá que hacer algunas pruebas para ver qué funciona mejor para usted.
Este tema tiene algunas ideas here y here.
A pesar de todas estas pautas, this post sugiere que lo más probable es que no afecte el rendimiento al tener conexiones múltiples. Aunque no es específico si se trata del lado del lado del cliente o del servidor (rabbitmq). Con el único punto de que, por supuesto, utilizará más recursos de sistemas con más conexiones. Si esto no es un problema y desea tener más rendimiento, de hecho puede ser mejor tener múltiples conexiones, ya que this post sugiere conexiones múltiples que le permitirán un mayor rendimiento. La razón parece ser que incluso si hay múltiples canales, solo un mensaje pasa por la conexión a la vez. Por lo tanto, un mensaje grande bloqueará la conexión completa o muchos mensajes sin importancia en un canal pueden bloquear un mensaje importante en la misma conexión pero un canal diferente. Nuevamente los recursos son un problema. Si está utilizando todo el ancho de banda con una conexión, agregar una conexión adicional no tendrá un rendimiento mayor que tener dos canales en una conexión. Además, cada conexión utilizará más memoria, CPU y manejadores de archivos, pero eso puede no ser una preocupación, aunque podría ser un problema al escalar.
False - "Channel thread-safety Las instancias de canal son seguras para el uso de varios subprocesos.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 "por los documentos de la API. – djechlin
bien editado. Es extraño que escribí eso, ¿es posible que la documentación haya cambiado? Solo un error de mi parte, disculpas. La recomendación sigue siendo la misma: 1 consumidor, 1 canal, 1 hilo – robthewolf
Si los canales son seguros para subprocesos depende de la implementación. La implementación de Java es segura, mientras que la de .NET no es segura. . Consulte http://stackoverflow.com/a/17829906/709537 –