Lapin MQ 4

AMQP 1.0 en tant que protocole de base : pour plus d'informations, voir Protocoles.

Pelles locales : les pelles supportent désormais un nouveau protocole appelé « local » en plus des protocoles AMQP 0-9-1 et AMQP 1.0. Les pelles locales sont basées en interne sur l'AMQP 1.0, mais au lieu d'utiliser des connexions TCP distinctes, elles utilisent des connexions intra-cluster entre les nœuds du cluster et des connexions internes APIs pour publier et consommer des messages. Cela ne peut être utilisé que pour la consommation et la publication au sein du même cluster et peut offrir un débit plus élevé tout en utilisant moins de ressources que les AMQP 0-9-1 et AMQP 1.0.

Les files d'attente de quorum prennent en charge les priorités des messages : les priorités des messages de la file d'attente de quorum sont toujours actives et ne nécessitent aucune politique pour fonctionner. Dès qu'une file d'attente de quorum reçoit un message avec une priorité définie, elle active la priorisation. Les files d'attente internes pour le quorum ne prennent en charge que deux priorités : haute et normale. Les messages sans définition de priorités seront mappés à la normale, tout comme les priorités 0 à 4. Les messages dont la priorité est supérieure à 4 seront mappés sur une priorité élevée. Les messages à priorité élevée seront privilégiés par rapport aux messages à priorité normale selon un ratio de 2:1, c'est-à-dire que pour 2 messages de priorité élevée, la file d'attente délivrera un message de priorité normale (si disponible). Par conséquent, les files d'attente pour le quorum mettent en œuvre une sorte de traitement prioritaire non strict et « équitable ». Cela garantit que des progrès sont toujours réalisés sur les messages prioritaires normaux, mais que les priorités élevées sont privilégiées dans un ratio de 2:1.

Khepri : Khepri est utilisé comme magasin de métadonnées par défaut pour les courtiers RabbitMQ 4

TLS mutuel (mTLS) : Amazon MQ prend en charge le protocole TLS mutuel (MTL) pour les courtiers RabbitMQ, permettant aux clients de s'authentifier à l'aide de certificats. Pour plus d'informations, consultez la section Configuration de mTLS.

Plug-in d'authentification par certificat SSL : le plug-in d'authentification SSL utilise des certificats clients issus de connexions mTLS pour authentifier les utilisateurs, permettant ainsi l'authentification à l'aide de certificats clients X.509 au lieu des informations d'identification par nom d'utilisateur et mot de passe. Pour plus d'informations, consultez la section Authentification par certificat SSL.

Plug-in d'authentification HTTP : Le plugin principal d'authentification HTTP permet de déléguer l'authentification et l'autorisation à un service HTTP externe. Pour plus d'informations, consultez Authentification et autorisation HTTP.

Mise en miroir des files d'attente classiques : les files d'attente classiques continuent d'être prises en charge sans aucune modification majeure pour les bibliothèques clientes et les applications, mais il s'agit désormais d'un type de file d'attente non répliqué. Les clients pourront se connecter à n'importe quel nœud pour publier et consommer depuis n'importe quelle file d'attente classique non répliquée. Les files d'attente de quorum sont recommandées pour la réplication et la sécurité des données.

Suppression de la QoS globale : il est recommandé aux clients de définir la QoS par consommateur (non globale) au lieu de la QoS globale, où un seul prefetch partagé est utilisé pour un canal entier.

Support pour les files d'attente transitoires et non exclusives : les files d'attente transitoires sont des files d'attente dont la durée de vie est liée au temps de disponibilité du nœud sur lequel elles sont déclarées. Dans un broker à instance unique, ils sont supprimés lorsque le nœud est redémarré. Dans un déploiement en cluster, ils sont supprimés lorsque le nœud sur lequel ils sont hébergés est redémarré. Nous vous recommandons d'utiliser le TTL de file d'attente pour supprimer automatiquement les files d'attente inutilisées et inactives après un certain temps d'inactivité. Les files d'attente exclusives continuent d'être prises en charge et sont supprimées une fois que toutes les connexions à la file d'attente ont été supprimées.

Type de file d'attente par défaut : Le type de file d'attente par défaut sur un broker RabbitMQ 4 est défini sur quorum. Si aucun argument de type de file d'attente n'est spécifié lors de la création de la file, une file d'attente quorum sera créée.

La limite de rediffusion par défaut pour les files d'attente du quorum est fixée à 20 : les messages redistribués 20 fois ou plus seront mis en échec ou supprimés (supprimés). Si 20 livraisons par message constituent un scénario courant pour une file d'attente, une cible de mise en attente ou une limite supérieure doit être configurée pour ces files d'attente afin d'éviter toute perte de données. La méthode recommandée pour ce faire est d'établir une politique.

amqplib : Les versions du client Node JS amqplib antérieures à 0.10.7 ou toute bibliothèque cliente AMQP utilisant frame_max < 8192 ne pourront pas se connecter à RabbitMQ

Limites de ressources par défaut : Amazon MQ pour RabbitMQ a introduit des limites d'utilisation des ressources par défaut pour les connexions, les canaux, les consommateurs par canal, les files d'attente, les hôtes virtuels, les pelles, les échanges et la taille maximale des messages. Ils servent de garde-fous pour protéger la disponibilité des courtiers et peuvent être personnalisés à l'aide de configurations adaptées à vos besoins spécifiques.

Échanges aléatoires locaux : les échanges aléatoires locaux ne sont pas pris en charge sur Amazon MQ car les nœuds Amazon MQ se trouvent derrière un équilibreur de charge réseau.

Intercepteur de messages : les intercepteurs de messages RabbitMQ ne sont pas pris en charge sur Amazon MQ.

Statistiques par file d'attente : Amazon MQ ne vendra pas les métriques de file d'attente de RabbitMQ aux courtiers de RabbitMQ 4 par l'intermédiaire de RabbitMQ 4. AWS CloudWatch Amazon MQ continuera de fournir des statistiques au niveau des courtiers via. AWS CloudWatch Vous pouvez interroger les métriques de file d'attente à l'aide de l'API de gestion RabbitMQ. Nous vous recommandons d'interroger les métriques relatives à des files d'attente spécifiques à une fréquence d'une minute ou à des intervalles plus longs.