Une connexion est un lien TCP physique entre votre application et ApsaraMQ for RabbitMQ. Un canal est une connexion virtuelle légère multiplexée sur ce lien TCP. Toutes les opérations du protocole AMQP (Advanced Message Queuing Protocol), telles que la déclaration de files d'attente, la publication ou la consommation de messages, s'effectuent sur des canaux et non directement sur la connexion.
Connexions
Une connexion gère les tâches réseau sous-jacentes : résolution des adresses IP, handshake TCP, négociation du protocole AMQP, authentification et routage. L'établissement d'une connexion nécessite environ 15 paquets TCP. Cette surcharge rend la création de connexions coûteuse en ressources ; elles doivent donc être persistantes.
Un grand nombre de connexions éphémères consomme d'importantes ressources réseau et serveur. À haut débit, la création fréquente de connexions peut déclencher la protection contre les inondations SYN (SYN flood), empêchant l'instance ApsaraMQ for RabbitMQ de répondre.

Canaux
Un canal est une connexion virtuelle établie au-dessus d'une connexion TCP physique. Chaque connexion peut transporter plusieurs canaux. La fermeture d'une connexion entraîne celle de tous ses canaux.
Pour connecter un grand nombre d'applications à ApsaraMQ for RabbitMQ afin d'envoyer et de recevoir des messages, établissez un nombre raisonnable de connexions et réutilisez plusieurs canaux pour chacune d'elles. Cette approche réduit l'utilisation des ressources système par rapport à l'ouverture d'une nouvelle connexion TCP pour chaque opération.

Remarques d'utilisation
Utiliser des connexions persistantes
Ouvrez les connexions au démarrage de l'application et conservez-les pendant tout son cycle de vie. N'ouvrez ni ne fermez les connexions pour chaque opération de publication ou de consommation.
Si votre charge de travail nécessite la création fréquente de canaux, réutilisez un ensemble stable de connexions et créez plusieurs canaux au sein de celles-ci. Pour connaître les limites relatives aux taux d'ouverture des connexions et des canaux, consultez la rubrique Limites.
Séparer les connexions producteur et consommateur
Utilisez au moins une connexion pour la production de messages et une connexion distincte pour la consommation. ApsaraMQ for RabbitMQ applique un contrôle de flux (back pressure) aux connexions qui publient plus rapidement que l'instance ne peut traiter les messages. Si les producteurs et les consommateurs partagent la même connexion, le contrôle de flux côté publication peut retarder les accusés de réception des consommateurs, ce qui dégrade le débit de consommation.
Utiliser un canal par thread
Plusieurs threads peuvent partager une connexion. Toutefois, les canaux ne sont pas thread-safe dans la plupart des bibliothèques clientes. Attribuez un canal dédié à chaque thread plutôt que de partager un canal entre plusieurs threads.
// Anti-pattern: sharing a channel across threads
Channel shared = connection.createChannel(); // Not thread-safe
// Recommended: one channel per thread
ExecutorService executor = Executors.newFixedThreadPool(4);
for (int i = 0; i < 4; i++) {
executor.submit(() -> {
Channel ch = connection.createChannel();
// Use ch for this thread's publish/consume operations
});
}
Lorsque plusieurs processus partagent une connexion, évitez de l'ouvrir et de la fermer fréquemment. Dans le cas contraire, une erreur ChannelNotFind peut survenir.
Prévenir le déséquilibre de consommation
Lorsque seul un petit nombre de connexions gère un volume important de messages, la consommation peut devenir inégalement répartie entre les consommateurs. Pour éviter cela :
Augmentez le nombre de connexions par consommateur ou ajoutez davantage de consommateurs.
Assurez-vous que chaque consommateur établit le même nombre de connexions.
Maintenez un total d'au moins 30 connexions de consommateurs à titre de recommandation.
Éviter la création et la fermeture fréquentes de canaux
Ne créez ni ne fermez fréquemment des canaux au sein d'une seule connexion. Maintenez la somme des TPS channelOpen et channelClose en dessous de 1 000. Le dépassement de ce seuil entraîne une charge excessive sur le broker.
Référence rapide
| Recommandation | Détails |
|---|---|
| Cycle de vie de la connexion | Persistante. Ouverte au démarrage, fermée à l'arrêt. |
| Cycle de vie du canal | Ouvert par thread ou par lot d'opérations. Fermé lorsqu'il n'est plus nécessaire. |
| Producteur vs consommateur | Séparez les connexions pour isoler le contrôle de flux. |
| Sécurité des threads | Partagez les connexions entre les threads. Ne partagez pas les canaux. |
| Nombre minimal de connexions de consommateurs | Au moins 30 au total pour éviter le déséquilibre de consommation. |
| Limites de débit | Consultez la rubrique Limites. |