RabbitMQ 4.2

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

Pelles locales : les pelles prennent désormais en charge un nouveau protocole appelé « local » en plus de l'AMQP 0-9-1 et de l'AMQP 1.0. Les pelles locales sont basées en interne sur 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 API internes pour publier et consommer des messages. Cela ne peut être utilisé que pour consommer et publier au sein du même cluster et peut offrir un débit plus élevé tout en utilisant moins de ressources qu'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. Lorsqu'une file d'attente de quorum reçoit un message dont la priorité est définie, elle active la hiérarchisation. Les files d'attente de quorum ne prennent en charge que deux niveaux de priorité internes : élevé et normal.

RabbitMQmappe les messages sans priorité et les messages dont la priorité est comprise entre 0 et 4 sur la valeur normale. Les messages dont la priorité est supérieure à 4 sont mappés à la priorité élevée. High-priority les messages sont privilégiés par rapport aux messages à priorité normale dans un ratio de 2:1. Pour 2 messages à priorité élevée, la file d'attente délivre 1 message à priorité normale, s'il y en a un disponible. Par conséquent, les files d'attente de quorum mettent en œuvre un modèle de traitement prioritaire non strict et équitable qui garantit la progression des messages à priorité normale.

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

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

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

Plugin d'authentification HTTP : le plug-in 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.

Support JMS : le broker prend désormais en charge les charges de travail JMS lorsque le plug-in d'échange de sujets JMS est activé, ce qui permet aux applications JMS de se connecter à l'aide du client JMS. RabbitMQ

Taille de stockage configurable : les courtiers RabbitMQ 4.x déployés en mode CLUSTER_MULTI_AZ prennent en charge des tailles de stockage EBS configurables. Pour plus d'informations, consultez la section Types d'instance mq.m7g.

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 à partir de 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 une QoS par consommateur (non globale) au lieu de la QoS globale, où une seule prélecture partagée est utilisée pour l'ensemble d'un canal.

Prise en charge des 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 à la disponibilité du nœud sur lequel elles sont déclarées. Dans un broker d'instance unique, ils sont supprimés lorsque le nœud est redémarré. Dans un déploiement de 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 d'attente, une file d'attente de quorum sera créée.

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

amqplib : Les versions amqplib du client Node JS 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 for 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.