- RabbitMQ a été retiré et remplacé par une file d’attente dans PostgresDB utilisant SQL
- Le remplacement a pris environ une demi-journée et le code source a été allégé de 580 lignes
- Plus important encore, la fiabilité et la résilience se sont nettement améliorées
- Il ne s’agit pas d’une critique des systèmes de file d’attente comme RabbitMQ, mais simplement d’un effort pour garder les choses simples
- Prequel, qui a écrit cet article, est un produit qui aide les entreprises B2B SaaS à synchroniser les bases de données de leurs clients via des pipelines de données à grande échelle
- La pile était composée de RabbitMQ + AQMP + Helm + un wrapper GoLang ; cela a bien fonctionné pendant un temps, puis des problèmes ont commencé à apparaître
- La livraison des messages prenait trop de temps, au point que certains messages étaient annulés
- À cause du préfetch des consommateurs, le message suivant était réservé avant la fin du traitement du message en cours
- Régler ce préfetch à 0 le rend infini, ce qui empêche en pratique de le désactiver
- Le problème venait du fait que les traitements des messages sont généralement des tâches de longue durée (transferts de données)
- Une fois la cause exacte comprise, il n’existait pas de correctif immédiat. Comme le problème touchait des clients en production, attendre n’était pas envisageable
- Ils sont donc passés à un fonctionnement basé sur une simple table dans Postgres, en lecture/écriture
- Des verrous de ligne en lecture/écriture garantissent qu’un seul consommateur lit une tâche à la fois
- C’est absurdement simple, mais cela fonctionne parfaitement
- Avantage supplémentaire : l’état de l’application n’est plus réparti entre RabbitMQ et Postgres, mais unifié dans un seul système
6 commentaires
Moi aussi, j’ai directement implémenté une file d’attente dans MySQL avec des verrous au niveau des lignes, et cela fonctionne très bien en production depuis des années.
Je voulais simplement fournir à plusieurs workers une fonctionnalité similaire à une file d’attente, tout en pouvant stocker avec la payload les états en attente / en cours / échec (et suppression une fois terminé).
À voir dans l’article qu’ils sont passés de RabbitMQ à la base de données en peu de temps, j’ai l’impression que c’est parce qu’ils n’avaient pas vraiment besoin de la portée généraliste d’un service de file d’attente spécialisé distinct, ni de ses nombreuses fonctionnalités et possibilités de configuration.
On dirait qu’il y a eu un problème à cause du décalage entre l’envoi manuel de l’ACK et la transaction DB,
mais c’est intéressant qu’ils aient choisi non pas une solution d’ingénierie, mais de retirer RabbitMQ.
RabbitMQ n’y est probablement pour rien...
https://news.ycombinator.com/item?id=35526846
Il y a beaucoup d’avis dans les commentaires.
Il y a aussi quelque chose comme https://github.com/pjongy/jasyncq qui semble fonctionner de manière similaire.
J’imagine qu’il y a un risque qu’une même ligne soit sélectionnée simultanément ; je serais curieux de savoir comment cela a été résolu.
Il est indiqué qu’il s’agit d’un verrouillage au niveau des lignes.