Top 6 des systèmes de file d’attente pour les développeurs backend

Vous cherchez un système de file d’attente? Ou peut-être cherchez-vous un meilleur? Voici toutes les informations dont vous avez besoin !

Les systèmes de file d’attente sont le secret le mieux gardé du développement backend.

Sans essayer d’écrire un poème à la louange des systèmes de file d’attente, je dirais qu’un développeur backend junior devient un développeur backend de niveau intermédiaire après avoir appris à intégrer les files d’attente dans le système. Les files d’attente améliorent l’expérience client (nous verrons comment), réduisent la complexité et améliorent la fiabilité d’un système.

Bien sûr, pour les applications Web très simples avec un trafic proche de zéro et des sites Web de brochures, les files d’attente peuvent être globales (ou même impossibles à installer si vous êtes sur un environnement d’hébergement partagé typique), mais les applications non triviales bénéficieront toutes de la mise en file d’attente systèmes et les grandes applications sont impossibles sans faire la queue.

Avant de commencer, un avertissement : si vous êtes déjà à l’aise avec les systèmes de file d’attente et que vous souhaitez comparer les différentes options, les prochaines sections d’introduction induiront un sommeil majeur. 🙂 Alors n’hésitez pas à sauter devant. Les sections d’introduction sont destinées à ceux qui n’ont qu’une vague idée des systèmes de file d’attente ou qui ont juste entendu le nom en passant.

Qu’est-ce qu’un système de file d’attente ?

Commençons par comprendre ce qu’est une file d’attente.

Une file d’attente est une structure de données en informatique qui imite, eh bien, les files d’attente du monde réel que nous voyons autour de nous. Si vous allez à un guichet, par exemple, vous remarquerez que vous devrez vous tenir au bout de la file d’attente, tandis que la personne au début de la file d’attente recevra le billet en premier. C’est ce que l’on appelle aussi le phénomène du « premier arrivé, premier servi ». En informatique, il est possible d’écrire des programmes qui stockent leurs tâches comme celle-ci dans une file d’attente, en les traitant une par une sur la même base du premier arrivé, premier servi.

Notez que la file d’attente n’effectue aucun traitement réel elle-même. C’est juste une sorte de stockage temporaire où les tâches attendent d’être récupérées par quelque chose. Si tout cela semble un peu trop abstrait, ne vous inquiétez pas. C’est un concept abstrait, mais nous verrons des exemples clairs dans la section suivante. 🙂

Pourquoi avez-vous besoin de systèmes de file d’attente ?

Sans entrer dans une description très longue, je dirais que le besoin principal des systèmes de mise en file d’attente est dû au traitement en arrière-plan, à l’exécution parallèle et à la récupération après une panne. Examinons-les à l’aide d’exemples :

Traitement en arrière-plan

Supposons que vous meniez une campagne de marketing e-commerce où le temps presse et que votre application est conçue de manière à envoyer un e-mail de confirmation juste avant que le client n’effectue le paiement et que la page de remerciement ne s’affiche. Si le serveur de messagerie auquel vous vous connectez est en panne, la page Web mourra, perturbant l’expérience utilisateur.

Imaginez le nombre élevé de demandes d’assistance que vous recevriez ! Dans ce cas, il est préférable de pousser cette tâche d’envoi d’e-mails vers une file d’attente de tâches et de montrer au client la page de réussite.

Exécution parallèle

De nombreux développeurs, en particulier ceux qui codent principalement des applications plus simples et à faible trafic, ont l’habitude d’utiliser des tâches cron pour le traitement en arrière-plan. C’est bien jusqu’à ce que la taille de l’entrée devienne si grande qu’elle ne puisse pas être effacée. Par exemple, supposons que vous disposiez d’une tâche cron qui compile des rapports d’analyse et les envoie par e-mail aux utilisateurs et que votre système puisse traiter 100 rapports par minute.

Dès que votre application grandit et commence à recevoir plus de 100 requêtes par minute en moyenne, elle commencera à prendre de plus en plus de retard et ne pourra jamais terminer toutes les tâches.

Dans un système de file d’attente, cette situation peut être évitée en mettant en place plusieurs travailleurs, qui peuvent chacun choisir un travail (contenant 100 rapports à faire chacun) et travailler en parallèle pour terminer la tâche beaucoup, beaucoup plus tôt.

Récupération après un échec

En tant que développeurs Web, nous ne pensons généralement pas à l’échec. Nous tenons en quelque sorte pour acquis que nos serveurs et les API que nous utilisons seront toujours en ligne. Mais la réalité est différente : les pannes de réseau ne sont que trop courantes et les excellentes API sur lesquelles vous comptez peuvent être en panne en raison de problèmes d’infrastructure (avant de dire « pas moi ! », n’oubliez pas le panne massive d’Amazon S3). Donc, pour revenir à l’exemple de rapport, si une partie de la génération de votre rapport nécessite que vous vous connectiez à l’API de paiement et que cette connexion soit interrompue pendant 2 minutes, qu’advient-il des 200 rapports qui ont échoué ?

Les systèmes de file d’attente impliquent cependant des frais généraux considérables. La courbe d’apprentissage est assez raide lorsque vous entrez dans un tout nouveau domaine, la complexité de votre application et de votre déploiement augmente et les tâches en file d’attente ne peuvent pas toujours être contrôlées avec une précision de 100 %. Cela dit, il existe des situations où la création d’une application sans files d’attente n’est tout simplement pas possible.

Avec cela à l’écart, examinons certaines des options courantes parmi les backends / systèmes de mise en file d’attente aujourd’hui.

Redis

Redis est connu comme un magasin clé-valeur qui stocke, met à jour et récupère simplement des chaînes de données sans aucune connaissance de la structure des données. Bien que cela ait pu être vrai auparavant, Redis dispose aujourd’hui de structures de données efficaces et très utiles telles que des listes, des ensembles triés et même un système Pub-Sub, ce qui le rend hautement souhaitable pour les implémentations de files d’attente.

Les avantages de Redis sont :

• Base de données entièrement en mémoire, ce qui permet des lectures/écritures plus rapides.
• Très efficace : peut facilement prendre en charge plus de 100 000 opérations de lecture/écriture par seconde.
• Schéma de persistance très flexible. Vous pouvez soit opter pour des performances maximales au prix d’une éventuelle perte de données en cas de panne, soit configurer en mode entièrement conservateur pour sacrifier les performances à la cohérence.
• Clusters pris en charge prêts à l’emploi

Veuillez noter que Redis n’a pas d’abstractions de messagerie/mise en file d’attente/récupération, vous devez donc soit utiliser un package, soit créer vous-même un système léger. Un exemple est que Redis est le backend de file d’attente par défaut pour le framework PHP Laravel, où un planificateur a été implémenté par les auteurs du framework.

Apprendre Redis est facile.

LapinMQ

Il existe quelques différences subtiles entre Redis et LapinMQalors éliminons-les d’abord.

Tout d’abord, RabbitMQ a un rôle plus spécialisé et bien défini, et il a donc été conçu pour refléter cela : la messagerie. En d’autres termes, son sweet spot est de servir d’intermédiaire entre deux systèmes, ce qui n’est pas le cas de Redis, qui fait office de base de données. Par conséquent, RabbitMQ fournit quelques fonctionnalités supplémentaires qui manquent dans Redis : routage des messages, tentatives, répartition de la charge, etc.

Si vous y réfléchissez bien, les files d’attente de tâches peuvent également être considérées comme un système de messagerie, où le planificateur, les travailleurs et les « soumis » du travail peuvent être considérés comme des entités participant à la transmission des messages.

RabbitMQ présente les avantages suivants :

• Meilleures abstractions pour la transmission de messages, réduisant le travail au niveau de l’application si la transmission de messages est ce dont vous avez besoin.
• Plus résistant aux pannes de courant et aux pannes (que Redis, du moins par défaut).
• Prise en charge des clusters et de la fédération pour les déploiements distribués.
• Des outils utiles pour gérer et surveiller vos déploiements.
• Prise en charge de pratiquement tous les langages de programmation non triviaux.
• Déploiement avec l’outil de votre choix (Docker, Chef, Puppet, etc.).

Quand utiliser RabbitMQ ? Je dirais que c’est un excellent choix lorsque vous savez que vous devez utiliser le passage de messages asynchrone mais que vous n’êtes pas prêt à vous attaquer à la grande complexité de certaines des autres options de mise en file d’attente de cette liste (voir ci-dessous).

ActiveMQ

Si vous êtes dans l’espace de l’entreprise (ou si vous créez une application hautement distribuée et à grande échelle) et que vous ne voulez pas avoir à réinventer la roue tout le temps (et à faire des erreurs en cours de route), ActiveMQ vaut le coup d’oeil.

Voici où ActiveMQ excelle :

• Il est implémenté en Java et a donc une intégration Java vraiment soignée (suit la norme JMS).
• Plusieurs protocoles pris en charge : AMQP, MQTT, STOMP, OpenWire, etc.
• Gère la sécurité, le routage, l’expiration des messages, l’analyse, etc., prêt à l’emploi.
• Prise en charge intégrée des modèles de messagerie distribués populaires, vous permettant d’économiser du temps et des erreurs coûteuses.

Cela ne veut pas dire qu’ActiveMQ n’est disponible que pour Java. Il a des clients pour Python, C/C++, Node, .Net et d’autres écosystèmes, il ne devrait donc y avoir aucune inquiétude quant à un éventuel effondrement à l’avenir. En outre, ActiveMQ est construit sur des normes complètement ouvertes et la création de vos propres clients légers devrait être facile.

Cela dit et fait, sachez qu’ActiveMQ n’est qu’un courtier et n’inclut pas de backend. Vous devrez toujours utiliser l’un des backends pris en charge pour stocker les messages. Je l’ai inclus ici car il n’est pas lié à un langage de programmation particulier (comme d’autres solutions populaires comme Celery, Sidekiq, etc.)

Amazon MQ

Amazon MQ mérite une mention rapide mais importante ici. Si vous pensez qu’ActiveMQ est la solution idéale pour vos besoins mais que vous ne souhaitez pas vous occuper vous-même de la construction et de la maintenance de l’infrastructure, Amazon MQ propose un service géré pour le faire. Il prend en charge tous les protocoles d’ActiveMQ – il n’y a aucune différence de fonctionnalités – puisqu’il utilise ActiveMQ lui-même sous la surface.

L’avantage est qu’il s’agit d’un service géré, vous n’avez donc pas à vous soucier de quoi que ce soit d’autre que de l’utiliser. Cela a encore plus de sens pour les déploiements sur AWS, car vous pouvez tirer parti d’autres services et offres directement à partir de votre déploiement (transferts de données plus rapides, par exemple).

SQS d’Amazon

Nous ne pouvons pas nous attendre à ce qu’Amazon reste silencieux en ce qui concerne les éléments d’infrastructure critiques, n’est-ce pas ? 🙂

Et donc nous avons SQS d’Amazon, qui est un service de file d’attente simple entièrement hébergé (littéralement) par le géant bien connu AWS. Encore une fois, les différences subtiles sont importantes, veuillez donc noter que SQS n’a pas le concept de transmission de message. Comme Redis, c’est un backend simple pour accepter et distribuer des travaux dans des files d’attente.

Alors, quand voudriez-vous utiliser Amazon SQS ? Voici quelques raisons :

• Vous êtes un fan d’AWS et vous ne toucherez à rien d’autre (honnêtement, il y a beaucoup de gens comme ça, et je pense qu’il n’y a rien de mal à ça).
• Vous avez besoin d’une solution hébergée, assurez-vous donc que le taux d’échec est nul et qu’aucun travail n’est perdu.
• Vous ne voulez pas créer un cluster et devoir le surveiller vous-même. Ou pire, vous devez créer des outils de surveillance alors que vous pourriez utiliser ce temps pour faire du développement productif.
• Vous avez déjà des investissements substantiels dans la plate-forme AWS et rester bloqué est logique sur le plan commercial.
• Vous voulez un système de mise en file d’attente simple et ciblé, sans aucun problème associé à la transmission de messages, aux protocoles, etc.

Dans l’ensemble, Amazon SQS est un choix solide pour tous ceux qui souhaitent incorporer des files d’attente de tâches dans leur système et ne pas avoir à se soucier de l’installation/de la surveillance des choses par eux-mêmes.

Haricot magique

Haricot magique existe depuis longtemps et est un backend éprouvé, rapide et facile pour la mise en file d’attente des tâches. Il y a quelques caractéristiques de Beanstalkd qui le différencient considérablement de Redis :

• C’est strictement un système de mise en file d’attente et rien d’autre. Vous y poussez des emplois, qui sont ensuite tirés par des travailleurs. Donc, si votre application a ne serait-ce qu’un petit besoin de transmission de messages, vous devriez éviter Beanstalkd.
• Il n’y a pas de structures de données avancées telles que des ensembles, des files d’attente prioritaires, etc.
• Beanstalkd est ce qu’on appelle une file d’attente premier entré, premier sorti (FIFO). Il n’y a aucun moyen d’organiser les travaux par priorité.
• Il n’y a pas d’options pour le clustering.

Tout cela dit, Beanstalkd constitue un système de file d’attente simple et rapide pour des projets simples qui résident sur un seul serveur. Pour beaucoup, c’est plus rapide et plus stable que Redis. Donc, si vous avez problèmes avec Redis que vous n’arrivez pas à résoudre quoi qu’il arrive, et vos besoins sont simples, Beanstalkd vaut la peine d’essayer.

Conclusion

Si vous avez lu jusqu’ici (ou atteint ici la lecture écrémée 😉 ), il y a de fortes chances que vous soyez intéressé par les systèmes de file d’attente ou que vous en ayez besoin. Si tel est le cas, la liste sur cette page vous sera utile, à moins que vous ne recherchiez un système de file d’attente spécifique à un langage/framework.

J’aimerais pouvoir vous dire que la file d’attente est simple et fiable à 100 %, mais ce n’est pas le cas. C’est désordonné, et comme tout est en arrière-plan et se passe très vite (les erreurs peuvent passer inaperçues et devenir très coûteuses). Pourtant, les files d’attente sont très nécessaires au-delà d’un certain point, et vous constaterez qu’elles sont une arme puissante (peut-être même la plus puissante) de votre arsenal. Bonne chance! 🙂