Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Bonnes pratiques Amazon MQ for RabbitMQ

Utilisez cela comme référence pour trouver rapidement les recommandations relatives à l'optimisation des performances et à la réduction des coûts de débit lors de l'utilisation des agents ActiveMQ sur Amazon MQ.

Activer les mises à niveau automatiques des versions mineures

Utilisation de la dernière version du broker, correction de bogues et amélioration des performances. Vous pouvez activer les mises à niveau automatiques des versions mineures pour Amazon MQ afin de gérer les mises à niveau vers la dernière version du correctif.

Utilisation de fonctionnalités obsolètes

Si vous utilisez la version 3.13 pour RabbitMQ sur Amazon MQ, vous verrez une bannière dans l'interface utilisateur de gestion de RabbitMQ indiquant : Deprecated features are being used.

Cela est dû au fait que RabbitMQ sur Amazon MQ utilise les fonctionnalités suivantes qui ne sont plus proposées sur RabbitMQ ou qui sont automatiquement configurées pour RabbitMQ sur Amazon MQ :

Il s'agit d'une bannière d'information pour la version 3.13 qui ne nécessite aucune action. Votre courtier Amazon MQ continuera à utiliser ces fonctionnalités.

Choisissez le type d'instance de courtier approprié pour obtenir le meilleur débit

Le débit de messages d'un type d'instance de courtier dépend du cas d'utilisation de votre application. Les types d'instances de broker plus petits comme celui-ci ne t3.micro doivent être utilisés que pour tester les performances des applications. L'utilisation de ces micro-instances avant d'utiliser des instances plus grandes en production peut améliorer les performances des applications et vous aider à réduire les coûts de développement. Sur les types d'instance m5.large et supérieurs, vous pouvez utiliser des déploiements de clusters pour garantir une haute disponibilité et une durabilité des messages. Les types d'instances de broker de plus grande taille peuvent gérer les niveaux de production des clients et des files d'attente, le haut débit, les messages en mémoire et les messages redondants. Pour plus d'informations sur le choix du type d'instance approprié, consultez les directives de dimensionnement.

Utiliser plusieurs canaux

Pour éviter toute perte de connexion, utilisez plusieurs canaux sur une seule connexion. Les applications doivent éviter un rapport connexion/canal 1:1. Nous recommandons d'utiliser une connexion par processus, puis un canal par thread. Évitez l'utilisation excessive des canaux pour éviter les fuites.

Activer les files d'attente paresseuses

Si vous travaillez avec de très longues files d'attente qui traitent de gros volumes de messages, l'activation des files d'attente latentes peut améliorer les performances des courtiers.

Le comportement par défaut de RabbitMQ consiste à mettre en cache les messages en mémoire et à les déplacer sur le disque uniquement lorsque l'agent a besoin de plus de mémoire disponible. Le transfert de messages de la mémoire vers le disque prend du temps et interrompt le traitement des messages. Les files d'attente latentes accélèrent considérablement le processus mémoire-disque en stockant les messages sur le disque dès que possible, ce qui réduit le nombre de messages mis en cache en mémoire.

Vous pouvez activer les files d'attente paresseuses en définissant les arguments queue.declare au moment de la déclaration, ou en configurant une politique via la console de gestion RabbitMQ. L'exemple suivant illustre la déclaration d'une file d'attente paresseuse à l'aide de la bibliothèque client Java RabbitMQ.

Map<String, Object> args = new HashMap<String, Object>();
args.put("x-queue-mode", "lazy");
channel.queueDeclare("myqueue", false, false, false, args);

Toutes les files d'attente Amazon MQ pour RabbitMQ du 3.12.13 et des versions ultérieures se comportent par défaut comme des files d'attente latentes. Pour passer à la dernière version d'Amazon MQ pour RabbitMQ, consultez. Mise à niveau d'une version du moteur d'agent Amazon MQ

Utilisez des messages persistants et des files d'attente durables

Les messages persistants peuvent aider à prévenir la perte de données dans les situations où un agent se bloque ou redémarre. Les messages persistants sont écrits sur le disque dès leur arrivée. Cependant, contrairement aux files d'attente paresseuses, les messages persistants sont mis en cache à la fois dans la mémoire et dans le disque, sauf si l'agent a besoin de plus de mémoire. Dans les cas où plus de mémoire est nécessaire, les messages sont supprimés de la mémoire par le mécanisme d'agent RabbitMQ qui gère le stockage des messages sur disque, communément appelé couche de persistance.

Pour activer la persistance des messages, vous pouvez déclarer vos files d'attente comme durable et définissez le mode de remise des messages sur persistent. L'exemple suivant illustre l'utilisation de la bibliothèque client Java RabbitMQ pour déclarer une file d'attente durable. Lorsque vous utilisez le AMQP 0-9-1, vous pouvez marquer les messages comme persistants en définissant le mode de livraison « 2 ».

boolean durable = true;
channel.queueDeclare("my_queue", durable, false, false, null);

Une fois que vous avez configuré votre file d'attente comme durable, vous pouvez envoyer un message persistant à votre file d'attente en définissant MessageProperties sur PERSISTENT_TEXT_PLAIN illustré dans l'exemple suivant.

import com.rabbitmq.client.MessageProperties;

channel.basicPublish("", "my_queue",
            MessageProperties.PERSISTENT_TEXT_PLAIN,
            message.getBytes());

Conserver les files d'attente courtes

Dans les déploiements en cluster, les files d'attente comportant un grand nombre de messages peuvent entraîner une surexploitation des ressources. Lorsqu'un agent est surutilisé, le redémarrage d'un agent Amazon MQ for RabbitMQ peut entraîner une dégradation supplémentaire des performances. En cas de redémarrage, les agents surexploités risquent de ne plus répondre dans l'état REBOOT_IN_PROGRESS.

Durant les fenêtres de maintenance, Amazon MQ effectue tous les travaux de maintenance un nœud à la fois pour s'assurer que l'agent reste opérationnel. Par conséquent, les files d'attente peuvent devoir se synchroniser à mesure que chaque nœud reprend l'opération. Pendant la synchronisation, les messages qui doivent être répliqués sur des miroirs sont chargés en mémoire à partir du volume Amazon Elastic Block Store (AmazonEBS) correspondant pour être traités par lots. Le traitement des messages par lots permet aux files d'attente de se synchroniser plus rapidement.

Si les files d'attente sont courtes et que les messages sont petits, les files d'attente se synchronisent et reprennent le fonctionnement comme prévu. Toutefois, si la quantité de données dans un lot approche de la limite de mémoire du nœud, le nœud déclenche une alarme de mémoire élevée, mettant en pause la synchronisation de la file d'attente. Vous pouvez confirmer l'utilisation de la mémoire en comparant les métriques du nœud RabbitMemUsed et du nœud RabbitMqMemLimit broker dans CloudWatch. La synchronisation ne peut pas se terminer tant que les messages ne sont pas consommés ou supprimés, ou que le nombre de messages dans le lot est réduit.

Si la synchronisation des files d'attente est interrompue pour un déploiement en cluster, nous vous recommandons de consommer ou de supprimer des messages afin de réduire le nombre de messages dans les files d'attente. Une fois la profondeur de la file d'attente réduite et la synchronisation de la file d'attente terminée, l'état de l'agent passe à RUNNING. Pour résoudre une synchronisation de file d'attente interrompue, vous pouvez également appliquer une politique pour réduire la taille du lot de synchronisation des files d'attente.

Vous pouvez également définir la suppression automatique et des TTL politiques visant à réduire de manière proactive l'utilisation des ressources, tout en limitant au maximum la NACKs communication avec les consommateurs. La mise en attente de messages sur le courtier est CPU intensive, de sorte qu'un nombre élevé de messages NACKs peut affecter les performances du courtier.

Configurer la confirmation de l'éditeur et l'accusé de réception du client

Le processus de confirmation de l'envoi d'un message au courtier est appelé confirmation de l'éditeur. L'éditeur confirme que votre application est informée lorsque les messages ont été stockés de manière fiable. Les confirmations de l'éditeur peuvent également aider à contrôler le taux de messages stockés auprès du courtier. Sans la confirmation de l'éditeur, il n'y a aucune confirmation qu'un message a été traité correctement, et votre courtier peut supprimer les messages qu'il ne peut pas traiter.

De même, lorsqu'une application cliente envoie une confirmation de livraison et de consommation de messages au courtier, on parle d'accusé de réception pour le consommateur. La confirmation et l'accusé de réception sont essentiels pour garantir la sécurité des données lorsque vous travaillez avec des courtiers RabbitMQ.

L'accusé de réception de livraison du consommateur est généralement configuré sur l'application client. Lorsque vous utilisez le AMQP 0-9-1, l'accusé de réception peut être activé en configurant la méthode. basic.consume AMQPLes clients 0-9-1 peuvent également configurer les confirmations de l'éditeur en envoyant la confirm.select méthode.

En règle générale, l'accusé de réception de livraison est activé dans un canal. Par exemple, lorsque vous travaillez avec la bibliothèque client Java RabbitMQ, vous pouvez utiliser l'Channel#basicAck pour mettre en place une confirmation positive basic.ack comme illustré dans l'exemple suivant.

// this example assumes an existing channel instance

boolean autoAck = false;
channel.basicConsume(queueName, autoAck, "a-consumer-tag",
     new DefaultConsumer(channel) {
         @Override
         public void handleDelivery(String consumerTag,
                                    Envelope envelope,
                                    AMQP.BasicProperties properties,
                                    byte[] body)
             throws IOException
         {
             long deliveryTag = envelope.getDeliveryTag();
             // positively acknowledge a single delivery, the message will
             // be discarded
             channel.basicAck(deliveryTag, false);
         }
     });

Vous pouvez configurer consumer_timeout pour détecter les cas où les consommateurs n'accusent pas réception des livraisons. Si le consommateur n'envoie pas d'accusé de réception dans le délai imparti, le canal sera fermé et vous recevrez un. PRECONDITION_FAILED Pour diagnostiquer l'erreur, utilisez le UpdateConfigurationAPIpour augmenter la consumer_timeout valeur.

Configurer la pré-extraction

Vous pouvez utiliser la valeur de pré-extraction RabbitMQ pour optimiser la façon dont vos consommateurs consomment les messages. RabbitMQ implémente le mécanisme de pré-extraction des canaux fourni par AMQP 0-9-1 en appliquant le nombre de pré-extraction aux consommateurs plutôt qu'aux canaux. La valeur de pré-extraction est utilisée pour spécifier le nombre de messages envoyés au consommateur à un moment donné. Par défaut, RabbitMQ définit une taille de tampon illimitée pour les applications client.

Il existe une variété de facteurs à prendre en compte lors de la définition d'un nombre de pré-extraction pour vos consommateurs RabbitMQ. Tout d'abord, considérez l'environnement et la configuration de vos clients. Étant donné que les consommateurs doivent conserver tous les messages en mémoire au fur et à mesure qu'ils sont traités, une valeur de pré-extraction élevée peut avoir un impact négatif sur les performances de vos consommateurs et, dans certains cas, peut entraîner un blocage potentiel d'un consommateur. De même, l'agent RabbitMQ conserve lui-même tous les messages qu'il envoie mis en mémoire cache jusqu'à ce qu'il reçoive l'accusé de réception du consommateur. Une valeur de pré-extraction élevée peut entraîner une perte de mémoire rapide de votre serveur RabbitMQ si l'accusé de réception automatique n'est pas configuré pour les consommateurs et si les consommateurs prennent un temps relativement long pour traiter les messages.

En prenant en compte les considérations ci-dessus, nous vous recommandons de toujours définir une valeur de pré-extraction afin d'éviter les situations où un agent RabbitMQ ou ses consommateurs manquent de mémoire en raison d'un grand nombre de messages non traités ou sans accusés de réception. Si vous avez besoin d'optimiser vos agents pour traiter de grands volumes de messages, vous pouvez tester vos agents et vos consommateurs à l'aide d'une plage de comptes de pré-extraction afin de déterminer la valeur à laquelle les frais généraux du réseau deviennent largement insignifiants par rapport au temps nécessaire au traitement des messages par un consommateur.

L'exemple suivant montre la définition d'une valeur de pré-extraction de 10 pour un seul consommateur utilisant la bibliothèque client Java RabbitMQ.

ConnectionFactory factory = new ConnectionFactory();

Connection connection = factory.newConnection();
Channel channel = connection.createChannel();

channel.basicQos(10, false);

QueueingConsumer consumer = new QueueingConsumer(channel);
channel.basicConsume("my_queue", false, consumer);

Configurer Celery

Python Celery envoie beaucoup de messages inutiles qui peuvent rendre plus difficile la recherche et le traitement des informations utiles. Pour réduire le bruit et faciliter le traitement, saisissez la commande suivante :

celery -A app_name worker --without-heartbeat --without-gossip --without-mingle

Restauration automatique des défaillances du réseau

Nous vous recommandons de toujours activer la récupération automatique du réseau pour éviter les temps d'arrêt importants en cas d'échec des connexions client aux nœuds RabbitMQ. La bibliothèque client Java RabbitMQ prend en charge la récupération automatique du réseau par défaut, en commençant par la version 4.0.0.

La récupération automatique de la connexion est déclenchée si une exception non gérée est levée dans la boucle d'I/O de la connexion, si un délai d'expiration de l'opération de lecture de socket est détecté ou si le serveur rate une pulsations.

Dans les cas où la connexion initiale entre un client et un nœud RabbitMQ échoue, la récupération automatique ne sera pas déclenchée. Nous vous recommandons d'écrire votre code d'application pour tenir compte des échecs de connexion initiaux en tentant de nouveau la connexion. L'exemple suivant illustre la nouvelle tentative d'échec réseau initial à l'aide de la bibliothèque client Java RabbitMQ.

ConnectionFactory factory = new ConnectionFactory();
// enable automatic recovery if using RabbitMQ Java client library prior to version 4.0.0.
factory.setAutomaticRecoveryEnabled(true);
// configure various connection settings

try {
  Connection conn = factory.newConnection();
} catch (java.net.ConnectException e) {
  Thread.sleep(5000);
  // apply retry logic
}

Activer Classic Queues v2 pour votre agent RabbitMQ

Nous recommandons d'activer Classic Queue v2 (CQv2) sur les versions 3.10 et 3.11 du moteur de courtage pour améliorer les performances, notamment :

Toutes les files d'attente Amazon MQ pour RabbitMQ du 3.12.13 et versions ultérieures sont utilisées par défaut. CQv2 Pour passer à la dernière version d'Amazon MQ pour RabbitMQ, consultez. Mise à niveau d'une version du moteur d'agent Amazon MQ

Migration de vers CQv1 CQv2

Pour l'utiliserCQv2, vous devez d'abord activer l'indicateur de classic_mirrored_queue_version fonctionnalité. Pour plus d'informations sur les indicateurs de fonctionnalité, voir Comment activer les indicateurs de fonctionnalité.

Pour migrer de CQv1 versCQv2, vous devez créer une nouvelle politique de file d'attente ou modifier une politique de file d'attente existante avec la définition de clé de queue-version stratégie définie sur2. Pour plus d'informations sur l'application des politiques, consultezAppliquer des politiques à Amazon MQ pour RabbitMQ. Pour plus d'informations sur l'activation CQv2 avec une politique de file d'attente, consultez la section Queues classiques dans la documentation de RabbitMQ.

Nous vous recommandons de suivre nos autres bonnes pratiques en matière de performances avant de commencer la migration.

Si vous utilisez une politique de file d'attente, la suppression de la politique de file d'attente rétrogradera les CQv2 files d'attente à. CQv1 Nous ne recommandons pas de rétrograder les CQv2 files d'attente, CQv1 car RabbitMQ convertira la représentation sur disque de la file d'attente. Ce processus peut être gourmand en mémoire et chronophage pour les files d'attente très longues.