Conception de files d'attente de messages : Assurer les garanties d'ordre des messages

Les files d'attente de messages sont un élément fondamental des systèmes distribués modernes, permettant une communication asynchrone entre les services, améliorant la scalabilité et renforçant la résilience. Cependant, s'assurer que les messages sont traités dans l'ordre où ils ont été envoyés est une exigence essentielle pour de nombreuses applications. Cet article de blog explore les défis du maintien de l'ordre des messages dans les files d'attente de messages distribuées et fournit un guide complet sur les différentes stratégies de conception et leurs compromis.

Pourquoi l'ordre des messages est-il important ?

L'ordre des messages est crucial dans les scénarios où la séquence des événements est significative pour maintenir la cohérence des données et la logique applicative. Considérez ces exemples :

Transactions financières : Dans un système bancaire, les opérations de débit et de crédit doivent être traitées dans le bon ordre pour éviter les découverts ou les soldes incorrects. Un message de débit arrivant après un message de crédit pourrait conduire à un état de compte inexact.
Traitement des commandes : Sur une plateforme de e-commerce, les messages de passation de commande, de traitement du paiement et de confirmation d'expédition doivent être traités dans la bonne séquence pour garantir une expérience client fluide et une gestion précise des stocks.
Event Sourcing : Dans un système basé sur l'approvisionnement en événements (event-sourcing), l'ordre des événements représente l'état de l'application. Le traitement des événements dans le désordre peut entraîner la corruption des données et des incohérences.
Fils d'actualité des réseaux sociaux : Bien que la cohérence à terme (eventual consistency) soit souvent acceptable, l'affichage de publications dans un ordre non chronologique peut être une expérience utilisateur frustrante. Un ordre en temps quasi réel est souvent souhaité.
Gestion des stocks : Lors de la mise à jour des niveaux de stock, en particulier dans un environnement distribué, il est vital de s'assurer que les ajouts et les retraits de stock sont traités dans le bon ordre pour garantir la précision. Un scénario où une vente est traitée avant un ajout de stock correspondant (dû à un retour) pourrait conduire à des niveaux de stock incorrects et à une potentielle survente.

Ne pas maintenir l'ordre des messages peut entraîner une corruption des données, un état d'application incorrect et une expérience utilisateur dégradée. Par conséquent, une prise en compte minutieuse des garanties d'ordre des messages lors de la conception de la file d'attente est essentielle.

Les défis du maintien de l'ordre des messages

Maintenir l'ordre des messages dans une file d'attente de messages distribuée est difficile en raison de plusieurs facteurs :

Architecture distribuée : Les files d'attente de messages fonctionnent souvent dans un environnement distribué avec plusieurs courtiers (brokers) ou nœuds. Garantir que les messages sont traités dans le même ordre sur tous les nœuds est difficile.
Concurrence : Plusieurs consommateurs peuvent traiter des messages simultanément, ce qui peut potentiellement entraîner un traitement dans le désordre.
Pannes : Les pannes de nœuds, les partitions réseau ou les crashs de consommateurs peuvent perturber le traitement des messages et entraîner des problèmes d'ordre.
Nouvelles tentatives de message : Réessayer les messages échoués peut introduire des problèmes d'ordre si le message réessayé est traité avant les messages suivants.
Équilibrage de charge : La distribution des messages entre plusieurs consommateurs à l'aide de stratégies d'équilibrage de charge peut involontairement entraîner un traitement des messages dans le désordre.

Stratégies pour assurer l'ordre des messages

Plusieurs stratégies peuvent être employées pour assurer l'ordre des messages dans les files d'attente de messages distribuées. Chaque stratégie a ses propres compromis en termes de performance, de scalabilité et de complexité.

1. File d'attente unique, consommateur unique

L'approche la plus simple consiste à utiliser une seule file d'attente et un seul consommateur. Cela garantit que les messages seront traités dans l'ordre où ils ont été reçus. Cependant, cette approche limite la scalabilité et le débit, car un seul consommateur peut traiter les messages à la fois. Cette approche est viable pour les scénarios à faible volume et critiques pour l'ordre, tels que le traitement des virements bancaires un par un pour une petite institution financière.

Avantages :

Simple à mettre en œuvre
Garantit un ordre strict

Inconvénients :

Scalabilité et débit limités
Point de défaillance unique

2. Partitionnement avec clés d'ordonnancement

Une approche plus scalable consiste à partitionner la file d'attente en fonction d'une clé d'ordonnancement. Les messages avec la même clé d'ordonnancement sont garantis d'être livrés à la même partition, et les consommateurs traitent les messages au sein de chaque partition dans l'ordre. Les clés d'ordonnancement courantes peuvent être un ID utilisateur, un ID de commande ou un numéro de compte. Cela permet le traitement parallèle des messages avec différentes clés d'ordonnancement tout en maintenant l'ordre pour chaque clé.

Exemple :

Considérez une plateforme de e-commerce où les messages liés à une commande spécifique doivent être traités dans l'ordre. L'ID de la commande peut être utilisé comme clé d'ordonnancement. Tous les messages liés à l'ID de commande 123 (par ex., passation de commande, confirmation de paiement, mises à jour d'expédition) seront acheminés vers la même partition et traités dans l'ordre. Les messages liés à un ID de commande différent (par ex., ID de commande 456) peuvent être traités simultanément dans une autre partition.

Les systèmes de files d'attente de messages populaires comme Apache Kafka et Apache Pulsar offrent une prise en charge intégrée du partitionnement avec des clés d'ordonnancement.

Avantages :

Scalabilité et débit améliorés par rapport à une file d'attente unique
Garantit l'ordre au sein de chaque partition

Inconvénients :

Nécessite une sélection rigoureuse de la clé d'ordonnancement
Une distribution inégale des clés d'ordonnancement peut conduire à des partitions surchargées (hot partitions)
Complexité dans la gestion des partitions et des consommateurs

3. Numéros de séquence

Une autre approche consiste à attribuer des numéros de séquence aux messages et à s'assurer que les consommateurs traitent les messages dans l'ordre des numéros de séquence. Cela peut être réalisé en mettant en mémoire tampon les messages qui arrivent dans le désordre et en les libérant lorsque les messages précédents ont été traités. Cela nécessite un mécanisme pour détecter les messages manquants et demander leur retransmission.

Exemple :

Un système de journalisation distribué reçoit des messages de log de plusieurs serveurs. Chaque serveur attribue un numéro de séquence à ses messages de log. L'agrégateur de logs met en mémoire tampon les messages et les traite dans l'ordre des numéros de séquence, garantissant que les événements de log sont ordonnés correctement même s'ils arrivent dans le désordre en raison de retards réseau.

Avantages :

Offre de la flexibilité dans la gestion des messages arrivant dans le désordre
Peut être utilisé avec n'importe quel système de file d'attente de messages

Inconvénients :

Nécessite une logique de mise en mémoire tampon et de réorganisation côté consommateur
Complexité accrue dans la gestion des messages manquants et des nouvelles tentatives
Potentiel de latence accrue en raison de la mise en mémoire tampon

4. Consommateurs idempotents

L'idempotence est la propriété d'une opération qui peut être appliquée plusieurs fois sans changer le résultat au-delà de l'application initiale. Si les consommateurs sont conçus pour être idempotents, ils peuvent traiter les messages en toute sécurité plusieurs fois sans causer d'incohérences. Cela permet une sémantique de livraison "au moins une fois" (at-least-once), où la livraison des messages est garantie au moins une fois, mais peut être effectuée plus d'une fois. Bien que cela ne garantisse pas un ordre strict, cela peut être combiné avec d'autres techniques, comme les numéros de séquence, pour assurer une cohérence à terme même si les messages arrivent initialement dans le désordre.

Exemple :

Dans un système de traitement des paiements, un consommateur reçoit des messages de confirmation de paiement. Le consommateur vérifie si le paiement a déjà été traité en interrogeant une base de données. Si le paiement a déjà été traité, le consommateur ignore le message. Sinon, il traite le paiement et met à jour la base de données. Cela garantit que même si le même message de confirmation de paiement est reçu plusieurs fois, le paiement n'est traité qu'une seule fois.

Avantages :

Simplifie la conception de la file d'attente de messages en permettant une livraison "au moins une fois"
Réduit l'impact de la duplication des messages

Inconvénients :

Nécessite une conception soignée des consommateurs pour garantir l'idempotence
Ajoute de la complexité à la logique du consommateur
Ne garantit pas l'ordre des messages

5. Patron de conception "Transactional Outbox"

Le patron de conception "Transactional Outbox" est un modèle qui garantit que les messages sont publiés de manière fiable dans une file d'attente de messages dans le cadre d'une transaction de base de données. Cela garantit que les messages ne sont publiés que si la transaction de base de données réussit, et que les messages ne sont pas perdus si l'application plante avant de publier le message. Bien que principalement axé sur la livraison fiable des messages, il peut être utilisé en conjonction avec le partitionnement pour assurer une livraison ordonnée des messages liés à une entité spécifique.

Comment ça marche :

Lorsqu'une application doit mettre à jour la base de données et publier un message, elle insère un message dans une table "outbox" (boîte d'envoi) au sein de la même transaction de base de données que la mise à jour des données.
Un processus distinct (par ex., un lecteur du journal des transactions de la base de données ou une tâche planifiée) surveille la table "outbox".
Ce processus lit les messages de la table "outbox" et les publie dans la file d'attente de messages.
Une fois le message publié avec succès, le processus marque le message comme envoyé (ou le supprime) de la table "outbox".

Exemple :

Lorsqu'une nouvelle commande client est passée, l'application insère les détails de la commande dans la table `orders` et un message correspondant dans la table `outbox`, le tout au sein de la même transaction de base de données. Le message dans la table `outbox` contient des informations sur la nouvelle commande. Un processus distinct lit ce message et le publie dans une file d'attente `new_orders`. Cela garantit que le message n'est publié que si la commande est créée avec succès dans la base de données, et que le message n'est pas perdu si l'application plante avant de le publier. De plus, l'utilisation de l'ID client comme clé de partition lors de la publication dans la file d'attente de messages garantit que tous les messages relatifs à ce client sont traités dans l'ordre.

Avantages :

Garantit une livraison de message fiable et l'atomicité entre les mises à jour de la base de données et la publication de messages.
Peut être combiné avec le partitionnement pour assurer une livraison ordonnée des messages associés.

Inconvénients :

Ajoute de la complexité à l'application et nécessite un processus distinct pour surveiller la table "outbox".
Nécessite une prise en compte minutieuse des niveaux d'isolation des transactions de la base de données pour éviter les incohérences de données.

Choisir la bonne stratégie

La meilleure stratégie pour garantir l'ordre des messages dépend des exigences spécifiques de l'application. Prenez en compte les facteurs suivants :

Exigences de scalabilité : Quel débit est requis ? L'application peut-elle tolérer un seul consommateur, ou le partitionnement est-il nécessaire ?
Exigences d'ordonnancement : Un ordre strict est-il requis pour tous les messages, ou l'ordre n'est-il important que pour les messages associés ?
Complexité : Quelle complexité l'application peut-elle tolérer ? Des solutions simples comme une file d'attente unique sont plus faciles à mettre en œuvre mais peuvent ne pas être très scalables.
Tolérance aux pannes : Dans quelle mesure le système doit-il être résilient aux pannes ?
Exigences de latence : À quelle vitesse les messages doivent-ils être traités ? La mise en mémoire tampon et la réorganisation peuvent augmenter la latence.
Capacités du système de file d'attente de messages : Quelles fonctionnalités d'ordonnancement le système de file d'attente de messages choisi offre-t-il ?

Voici un guide de décision pour vous aider à choisir la bonne stratégie :

Ordre strict, faible débit : File d'attente unique, consommateur unique
Messages ordonnés dans un contexte (ex: utilisateur, commande), débit élevé : Partitionnement avec clés d'ordonnancement
Gestion des messages occasionnellement désordonnés, flexibilité : Numéros de séquence avec mise en mémoire tampon
Livraison "au moins une fois", duplication de messages tolérable : Consommateurs idempotents
Garantir l'atomicité entre les mises à jour de la base de données et la publication de messages : Patron de conception "Transactional Outbox" (peut être combiné avec le partitionnement pour une livraison ordonnée)

Considérations sur les systèmes de files d'attente de messages

Différents systèmes de files d'attente de messages offrent différents niveaux de prise en charge de l'ordre des messages. Lors du choix d'un système de file d'attente de messages, considérez ce qui suit :

Garanties d'ordre : Le système fournit-il un ordre strict, ou garantit-il seulement l'ordre au sein d'une partition ?
Prise en charge du partitionnement : Le système prend-il en charge le partitionnement avec des clés d'ordonnancement ?
Sémantique "exactly-once" : Le système fournit-il une sémantique "exactly-once" (exactement une fois), ou seulement une sémantique "at-least-once" (au moins une fois) ou "at-most-once" (au plus une fois) ?
Tolérance aux pannes : Dans quelle mesure le système gère-t-il bien les pannes de nœuds et les partitions réseau ?

Voici un bref aperçu des capacités d'ordonnancement de quelques systèmes de files d'attente de messages populaires :

Apache Kafka : Fournit un ordre strict au sein d'une partition. Les messages avec la même clé sont garantis d'être livrés à la même partition et traités dans l'ordre.
Apache Pulsar : Fournit un ordre strict au sein d'une partition. Prend également en charge la déduplication des messages pour atteindre une sémantique "exactly-once".
RabbitMQ : Prend en charge une file d'attente unique et un consommateur unique pour un ordre strict. Prend également en charge le partitionnement à l'aide de types d'échange et de clés de routage, mais l'ordre n'est pas garanti entre les partitions sans logique supplémentaire côté client.
Amazon SQS : Fournit un ordre au mieux ("best-effort"). Les messages sont généralement livrés dans l'ordre où ils ont été envoyés, mais une livraison dans le désordre est possible. Les files d'attente FIFO SQS (First-In-First-Out) fournissent un traitement "exactly-once" et des garanties d'ordre.
Azure Service Bus : Prend en charge les sessions de messages, qui permettent de regrouper des messages associés et de s'assurer qu'ils sont traités dans l'ordre par un seul consommateur.

Considérations pratiques

En plus de choisir la bonne stratégie et le bon système de file d'attente de messages, tenez compte des considérations pratiques suivantes :

Surveillance et alertes : Mettez en place une surveillance et des alertes pour détecter les messages arrivant dans le désordre et d'autres problèmes d'ordre.
Tests : Testez minutieusement le système de file d'attente de messages pour vous assurer qu'il répond aux exigences d'ordre. Incluez des tests qui simulent des pannes et un traitement simultané.
Traçage distribué : Mettez en œuvre le traçage distribué pour suivre les messages à travers le système et identifier les problèmes d'ordre potentiels. Des outils comme Jaeger, Zipkin et AWS X-Ray peuvent être inestimables pour diagnostiquer les problèmes dans les architectures de files d'attente de messages distribuées. En étiquetant les messages avec des identifiants uniques et en suivant leur parcours à travers différents services, vous pouvez facilement identifier les points où les messages sont retardés ou traités dans le désordre.
Taille des messages : Des messages plus volumineux могут affecter les performances et augmenter la probabilité de problèmes d'ordre en raison de retards réseau ou de limitations de la file d'attente. Envisagez d'optimiser la taille des messages en compressant les données ou en divisant les gros messages en plus petits morceaux.
Délais d'attente et nouvelles tentatives : Configurez des délais d'attente et des politiques de nouvelle tentative appropriés pour gérer les pannes temporaires et les problèmes de réseau. Cependant, soyez conscient de l'impact des nouvelles tentatives sur l'ordre des messages, en particulier dans les scénarios où les messages peuvent être traités plusieurs fois.

Conclusion

Assurer l'ordre des messages dans les files d'attente de messages distribuées est un défi complexe qui nécessite une prise en compte attentive de divers facteurs. En comprenant les différentes stratégies, compromis et considérations pratiques décrits dans cet article de blog, vous pouvez concevoir des systèmes de files d'attente de messages qui répondent aux exigences d'ordre de votre application et garantissent la cohérence des données et une expérience utilisateur positive. N'oubliez pas de choisir la bonne stratégie en fonction des besoins spécifiques de votre application et de tester minutieusement votre système pour vous assurer qu'il répond à vos exigences d'ordre. À mesure que votre système évolue, surveillez et affinez continuellement la conception de votre file d'attente de messages pour vous adapter aux exigences changeantes et garantir des performances et une fiabilité optimales.