Queen MQ présente un courtier de messages ACID avec des files d'attente par entité et une forte cohérence

L'utilisateur GitHub queen-mq a publié Queen, un courtier de messages open source conçu pour fournir des garanties ACID (Atomicité, Cohérence, Isolation, Durabilité) pour la messagerie distribuée. Publié le 10 novembre 2026, ce système basé sur Rust vise à simplifier l'architecture backend en traitant chaque client, commande ou conversation comme sa propre file d'attente, garantissant que les changements d'état et les accusés de réception des messages sont validés ensemble comme une seule transaction.

Ce qui s'est passé

La version introduit un courtier qui s'éloigne des modèles traditionnels de cohérence éventuelle souvent présents dans les systèmes à haut débit. Au lieu de dépendre de mécanismes séparés pour le verrouillage, la planification ou le réessai des messages échoués, Queen intègre directement ces capacités dans son cœur transactionnel. La documentation du projet souligne que chaque étape d'un flux de travail, y compris l'accusé de réception, la diffusion du message suivant, les mises à jour d'état et la configuration des minuteurs, est validée comme une unité atomique unique. Cette approche supprime la complexité liée à la gestion des verrous Redis, des tâches cron ou des tables de réessai dédiées.

Queen prend en charge plusieurs langages de programmation, notamment JavaScript, Python, Go et Rust, et offre des fonctionnalités telles que le traitement de flux avec des fenêtres tumbling, sliding et session. Il inclut également la prise en charge de la fusion des groupes de consommateurs, qui ne délivrent que le message le plus récent pour les partitions où seule la dernière valeur compte. Pour les motifs requête-réponse, le courtier fournit des files d'attente éphémères en mémoire, rapides mais volontairement perdues lors des plantages, les distinguant ainsi des journaux persistants. Le système est conçu pour gérer une gestion d'état complexe, offrant un stockage clé-valeur, des verrous distribués et des minuteurs programmés au sein de la même limite transactionnelle que le traitement des messages.

Détails clés

• Transactions ACID : Chaque opération de message, y compris les accusés de réception, les changements d'état et les minuteurs, est validée de manière atomique, garantissant qu'aucune mise à jour partielle ne se produit.
• Benchmarks de haute performance : Sur trois nœuds GCP avec NVMe local, Queen a atteint 3 millions de messages par seconde avec une latence p99 de 15-25 ms sur jusqu'à 10 millions de partitions.
• Récupération rapide : Un nœud rejoignant un cluster après cinq minutes d'arrêt a synchronisé uniquement un delta de 1,1 GB en 28 secondes, nettement plus rapidement que les versions précédentes.
• Indépendant du langage : Prend en charge les clients en JavaScript, Python, Go et Rust, et permet aux producteurs et consommateurs Kafka inchangés de se connecter via un port compatible Kafka.
• Stockage intégré : Le courtier peut écrire directement les files d'attente dans des tables PostgreSQL ou des buckets S3 aux formats JSONL ou Parquet sans nécessiter de processus externes.
• Fiabilité prouvée : Le logiciel a réussi 226 tests Jepsen sur la version 2.7, confirmant qu'aucun message accusé de réception n'a été perdu et qu'aucun bail n'a été détenu deux fois.

Contexte

Les courtiers de messages sont des composants essentiels de l'architecture logicielle moderne, agissant comme intermédiaires permettant à différentes parties d'un système de communiquer de manière asynchrone. Les courtiers traditionnels comme Kafka ou RabbitMQ privilégient souvent le débit et la disponibilité, parfois au détriment de la cohérence immédiate. Les développeurs doivent fréquemment construire des infrastructures supplémentaires, telles que des files d'attente de réessai basées sur une base de données ou des gestionnaires de verrous distribués, pour garantir que la logique métier reste cohérente lorsque les messages échouent ou arrivent dans le désordre.

Les propriétés ACID, généralement associées aux bases de données relationnelles, garantissent que les transactions sont traitées de manière fiable. L'atomicité signifie que toutes les parties d'une transaction réussissent ou échouent ensemble. La cohérence assure que la base de données reste dans un état valide. L'isolation empêche les transactions concurrentes d'interférer les unes avec les autres, et la durabilité garantit que les données validées survivent aux défaillances du système. En apportant ces garanties au courtage de messages, Queen tente de réduire la charge opérationnelle pesant sur les équipes d'ingénierie qui devaient auparavant assembler plusieurs outils pour atteindre une fiabilité similaire.

Pourquoi c'est important

Pour les équipes gérant leur propre logiciel, la promesse de conformité ACID dans un courtier de messages peut réduire considérablement la complexité architecturale. Actuellement, de nombreuses applications auto-hébergées nécessitent une combinaison d'une file d'attente de messages, d'une base de données relationnelle pour l'état et d'un magasin séparé pour les verrous distribués. La gestion de la cohérence entre ces trois systèmes est une source courante de bugs et de charges opérationnelles. Si Queen tient ses promesses, les développeurs pourraient remplacer cette triade par un seul composant, simplifiant le déploiement, la surveillance et le débogage.

Les benchmarks de performance suggèrent que cette simplicité ne se fait pas au prix sévère du débit. La gestion de 3 millions de messages par seconde avec une faible latence est compétitive avec des acteurs établis comme Redpanda et Pulsar, en particulier à des nombres élevés de partitions. Pour les entreprises de taille moyenne faisant évoluer leur infrastructure, la capacité de drainer 100 GB de retard en 32 secondes et de récupérer les nœuds rapidement peut faire la différence entre un léger incident et une panne prolongée lors des pics de trafic.

Cependant, l'adoption d'un nouveau composant d'infrastructure central comporte des risques. Bien que les tests Jepsen offrent confiance dans son modèle de cohérence, les cas d'utilisation en production réelle varient largement. Les équipes doivent évaluer si les fonctionnalités spécifiques, telles que les files d'attente par entité et le déchargement intégré vers S3, correspondent à leurs besoins en matière de rétention et de traitement des données. La licence Apache-2.0 autorise l'utilisation commerciale et la modification, ce qui est attractif pour les entreprises souhaitant éviter l'enfermement fournisseur tout en gardant le contrôle sur leur code source.

Ce que vous pouvez faire

• Examiner la documentation : Téléchargez le PDF "The little book of QueenMQ" pour comprendre l'architecture, le modèle de stockage et les garanties API avant d'envisager l'adoption.
• Lancer des tests de benchmark : Reproduisez les benchmarks fournis en utilisant votre propre matériel ou environnement cloud pour vérifier si le débit et la latence revendiqués répondent aux exigences de votre application.
• Évaluer les chemins de migration : Si vous utilisez actuellement Kafka, testez le port compatible Kafka pour voir si les producteurs et consommateurs existants peuvent se connecter sans modifications de code.
• Évaluer les besoins de gestion d'état : Déterminez si la logique de votre application bénéficierait d'avoir le stockage KV, les verrous et les minuteurs intégrés directement dans le flux de transaction des messages.
• Tester les scénarios d'échec : Utilisez la fonctionnalité de cluster de secours et les mécanismes de récupération de nœud dans un environnement de préproduction pour valider le temps de rejonction de 28 secondes et l'intégrité des données.
• Vérifier la prise en charge des langages : Assurez-vous que les bibliothèques clientes pour vos principaux langages de développement (JS, Python, Go, Rust) sont suffisamment matures pour vos normes de production.