Arguments contre l'encombrement des courtiers
Les courtiers de messages dédiés comme SQS, Kafka et RabbitMQ introduisent une surcharge opérationnelle importante, souvent cachée. Vous gérez une infrastructure séparée, ce qui entraîne des coûts de provisionnement, de déploiement, de surveillance et de mise à l'échelle de services distincts. Cela ajoute de la latence réseau et augmente considérablement la charge cognitive des développeurs qui intègrent et déboguent de multiples systèmes distribués, imposant une complexité inutile à votre stack.
Votre base de données Postgres existante offre une alternative robuste et fiable, éliminant l'encombrement des courtiers. Basé sur la conformité ACID et une puissance transactionnelle éprouvée au combat, Postgres fournit une base solide pour une mise en file d'attente fiable, garantissant l'intégrité des données même en cas de défaillance. Il gère confortablement des millions de lignes et des milliers de requêtes par seconde ; par exemple, un test avec 2 CPU et 2 Go de RAM a traité 100 000 messages en 9 secondes, soit une moyenne de 11 100 messages/seconde.
PGMQ formalise ce modèle puissant sous la forme d'une extension légère et simple. Il offre une API de type SQS directement dans Postgres, permettant la création de files d'attente, l'envoi de messages avec des délais optionnels, et la consommation avec des délais de visibilité (VT) pour garantir une livraison exactement une fois. Cela signifie que vous obtenez une file d'attente de messages entièrement fonctionnelle, avec des bibliothèques clientes pour Rust, Python et TypeScript, sans ajouter un seul nouveau service à votre stack.
De zéro à la file d'attente en 5 lignes de SQL
Créez des files d'attente avec du SQL pur. Appelez pgmq.create('my_queue') ; chaque file d'attente devient sa propre table Postgres. Envoyez des messages en utilisant pgmq.send('my_queue', '{"job_id": 123}'). Cela intègre les messages sous forme de JSON directement dans Postgres, simplifiant votre modèle de données.
Implémentez la livraison planifiée avec pgmq.send(). Ajoutez un paramètre delay (par exemple, pgmq.send('my_queue', '{"task": "future"}', 30)). Le message entre dans la file d'attente mais reste non consommable pendant 30 secondes, permettant une planification avancée des tâches sans services cron externes.
Consommez les messages via pgmq.read('my_queue', 30, 1). Le paramètre critique vt (délai de visibilité) rend les messages lus invisibles pour la durée spécifiée (par exemple, 30 secondes). Cela garantit une livraison exactement une fois : aucun autre travailleur ne peut traiter le même message pendant sa fenêtre active. S'il n'est pas traité ou supprimé dans le délai VT, il réapparaît dans la file d'attente.
Une fois traité, supprimez les messages. Utilisez pgmq.delete('my_queue', message_id) pour supprimer définitivement un message. Alternativement, pgmq.archive('my_queue', message_id) supprime le message de la file d'attente active et le déplace vers une table d'archivage dédiée, fournissant un journal historique pour l'audit ou le retraitement.
Mais est-ce que cela passe vraiment à l'échelle ?
"Mais ça ne passe pas à l'échelle", dites-vous. C'est le refrain habituel contre l'utilisation des bases de données comme files d'attente. Postgres, cependant, gère confortablement des millions de lignes et des milliers de requêtes par seconde. PGMQ exploite cette capacité inhérente, transformant une faiblesse perçue en une force pour les applications distribuées.
Un récent test de résistance a validé les performances de PGMQ sur des ressources limitées. Les chercheurs ont provisionné un conteneur Docker avec seulement 2 CPU et 2 Go de RAM. Ils ont ensuite injecté 100 000 messages dans une file d'attente PGMQ. Cette configuration reflète les environnements de service réels typiques, rendant les résultats hautement pertinents.
Cent travailleurs simultanés ont traité les 100 000 messages en seulement 9 secondes. Chaque travailleur a lu, enregistré et supprimé les messages par lots. Cela se traduit par un débit combiné dépassant 11 100 messages par seconde. Pour une documentation complète et d'autres exemples, consultez le dépôt officiel Postgres Message Queue (PGMQ).
Une telle performance invalide sans équivoque le mythe du « manque de scalabilité » pour pratiquement toutes les applications du monde réel. PGMQ prouve que Postgres est non seulement viable, mais hautement performant en tant que file d'attente de messages, éliminant la surcharge opérationnelle des courtiers dédiés pour la plupart des cas d'utilisation. Simplifiez votre infrastructure.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Intégrer PGMQ dans votre application
Intégrez PGMQ directement dans votre pile applicative. Allez au-delà du SQL brut avec des bibliothèques clientes robustes pour les langages populaires. Le support officiel alimente les intégrations Python et Rust, offrant des interfaces idiomatiques. Les bibliothèques pilotées par la communauté étendent davantage PGMQ à Ruby et à plusieurs variantes de TypeScript, y compris une expérience transparente avec Prisma.
Créez des producteurs avec un minimum de code. Un producteur Python envoie un message avec un simple appel send(), en spécifiant le nom de la file d'attente et la charge utile JSON. Cela reflète la commande SQL pgmq.send(), en faisant abstraction de l'interaction avec la base de données pour vous.
Les travailleurs consomment les messages efficacement. Utilisez la fonction read() d'une bibliothèque cliente pour récupérer un lot de messages, en respectant le délai de visibilité (VT). Après le traitement, appelez delete() ou archive() pour supprimer les messages, garantissant une livraison exactement une fois et empêchant le retraitement. Ce modèle gère les tâches à haut volume.
Unifier vos couches de données et de messagerie au sein de Postgres simplifie votre infrastructure. Éliminez la surcharge opérationnelle des courtiers de messages séparés, réduisant la latence réseau et la charge cognitive. Cette consolidation rationalise le développement, les tests et le déploiement, produisant un système plus robuste et maintenable.
Questions fréquemment posées
Qu'est-ce que PGMQ ?
PGMQ (Postgres Message Queue) est une extension légère pour PostgreSQL qui permet une fonctionnalité de file d'attente de messages directement au sein de la base de données, offrant une alternative à des services comme AWS SQS, RabbitMQ ou Kafka.
Comment PGMQ garantit-il une livraison exactement une fois ?
PGMQ utilise un « délai de visibilité ». Lorsqu'un message est lu, il devient invisible pour les autres consommateurs pendant une période définie. Le consommateur doit supprimer ou archiver le message dans ce délai. En cas d'échec, le message réapparaît pour qu'un autre consommateur puisse le traiter, évitant ainsi la perte de données.
PGMQ peut-il gérer un trafic de niveau production ?
Oui. Les benchmarks montrent que PGMQ peut traiter plus de 11 000 messages par seconde sur du matériel modeste (par exemple, un conteneur à 2 CPU). C'est largement suffisant pour de nombreuses applications distribuées à haut volume.
Quel est le principal avantage d'utiliser Postgres comme file d'attente de messages ?
L'avantage principal est la simplification de l'infrastructure. En tirant parti de votre base de données existante, vous réduisez les dépendances, diminuez la surcharge opérationnelle et simplifiez toute votre pile technologique sans sacrifier les performances pour la plupart des cas d'utilisation courants.