Vous êtes à la recherche d'un système de fichier d'attente ? Ou peut-être cherchez-vous un meilleur système ? Voici toutes les informations dont vous avez besoin !
Les systèmes de file d'attente sont le secret le mieux gardé du développement des applications dorsales.
Sans vouloir écrire un poème à la gloire des systèmes de files 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 des applications web très simples avec un trafic proche de zéro et des sites web de brochures, les fichiers d'attente peuvent être un problème global (voire impossible à installer si vous êtes sur un environnement d'hébergement partagé typique), mais les applications non triviales bénéficieront toutes de systèmes de fichiers d'attente, et les applications de grande taille sont impossibles sans l'implication de fichiers d'attente.
Avant de commencer, un avertissement : si vous êtes déjà à l'aise avec les systèmes de file d'attente et que vous voulez comparer les différentes options, les prochaines sections d'introduction vous feront dormir profondément 🙂 N'hésitez donc pas à passer directement à la suite. Les sections introductives sont destinées à ceux qui n'ont qu'une vague idée des systèmes de mise en file d'attente ou qui ont simplement entendu leur nom en passant.
Qu'est-ce qu'un système de fichier d'attente ?
Commençons par comprendre ce qu'est un fichier d'attente.
Un fichier d'attente est une structure de données en informatique qui imite les fichiers d'attente du monde réel que nous voyons autour de nous. Si vous vous rendez à un guichet, par exemple, vous remarquerez que vous devrez vous tenir à la fin de la file d'attente, tandis que la personne au début de la file obtiendra le billet en premier. C'est ce qu'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 dans une file d'attente et les traitent une à une selon le même principe du "premier arrivé, premier servi".
Notez que la file d'attente n'effectue pas de traitement proprement dit. Il s'agit simplement d'une sorte de stockage temporaire où les tâches attendent d'être prises en charge par quelque chose. Si tout cela vous semble un peu trop abstrait, ne vous inquiétez pas. Il s'agit d'un concept abstrait, mais nous verrons des exemples clairs dans la section suivante 🙂 .
Pourquoi avez-vous besoin de systèmes de fichiers d'attente ?
Sans entrer dans une longue description, je dirais que les systèmes de files d'attente sont principalement nécessaires pour le traitement en arrière-plan, l'exécution parallèle et la reprise après une défaillance. Examinons ces points à l'aide d'exemples :
Traitement en arrière-plan
Supposons que vous meniez une campagne de marketing en ligne où le temps est un facteur essentiel, et que votre application soit conçue de manière à envoyer un courrier électronique de confirmation juste avant que le client n'achève son paiement et ne reçoive la page de remerciement. Si le serveur de messagerie auquel vous vous connectez est en panne, la page web ne fonctionnera pas, ce qui perturbera l'expérience de l'utilisateur.
Imaginez le nombre élevé de demandes d'assistance que vous recevriez ! Dans ce cas, il est préférable de placer cette tâche d'envoi de courrier électronique dans une file d'attente 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 simples et à faible trafic, ont l'habitude d'utiliser des tâches cron pour le traitement en arrière-plan. C'est une bonne chose jusqu'à ce que la taille de l'entrée devienne si importante qu'elle ne puisse pas être effacée. Par exemple, supposons que vous ayez une tâche cron qui compile des rapports d'analyse et les envoie par courriel aux utilisateurs et que votre système puisse traiter 100 rapports par minute.
Dès que votre application se développe et commence à recevoir plus de 100 requêtes par minute en moyenne, elle prendra de plus en plus de retard et ne sera jamais en mesure de 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 une tâche (contenant 100 rapports à traiter chacun) et travailler en parallèle pour terminer la tâche beaucoup, beaucoup plus tôt.
Récupération en cas d'échec
En tant que développeurs web, nous ne pensons généralement pas à l'échec. Nous tenons 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 fréquentes, et les excellentes API sur lesquelles vous comptez peuvent être hors service en raison de problèmes d'infrastructure (avant que vous ne disiez "pas moi !", n'oubliez pas la panne massive d'Amazon S3). Pour en revenir à l'exemple des rapports, si une partie de la génération de vos rapports exige que vous vous connectiez à l'API des paiements et que cette connexion est interrompue pendant deux minutes, qu'advient-il des 200 rapports qui ont échoué ?
Les systèmes de mise en file d'attente impliquent toutefois des frais généraux considérables. La courbe d'apprentissage est assez raide car 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, dans certaines situations, il n'est pas possible de construire une application sans fichier d'attente.
Ceci étant dit, jetons un coup d'œil à quelques-unes des options les plus courantes parmi les backends/systèmes de mise en fichier d'attente aujourd'hui.
Redis
Redis est connu comme un magasin clé-valeur qui se contente de stocker, de mettre à jour et de récupérer des chaînes de données sans aucune connaissance de la structure des données. Bien que cela ait pu être vrai auparavant, Redis possède aujourd'hui des 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 très souhaitable pour les implémentations de fichiers d'attente.
Les avantages de Redis sont les suivants
- Base de données entièrement en mémoire, ce qui accélère les lectures/écritures.
- Très efficace : Peut facilement supporter 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 défaillance, soit mettre en place un mode totalement conservateur afin de sacrifier les performances au profit de la cohérence.
- Clusters pris en charge dès le départ
Veuillez noter que Redis n'a pas d'abstractions de messagerie, de file d'attente ou de récupération, vous devez donc utiliser un paquetage ou construire un système léger vous-même. Par exemple, 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 LapinMQ.
Tout d'abord, LapinMQ a un rôle plus spécialisé et bien défini, et il a donc été construit pour refléter cela - la messagerie. En d'autres termes, son point fort est d'agir en tant qu'intermédiaire entre deux systèmes, ce qui n'est pas le cas de Redis, qui agit en tant que base de données. Par conséquent, RabbitMQ fournit quelques fonctions supplémentaires qui manquent à Redis : routage des messages, tentatives, distribution de la charge, etc.
Si vous y réfléchissez, les fichiers d'attente de tâches peuvent également être considérés comme un système de messagerie, où le planificateur, les travailleurs et les "soumetteurs" de tâches peuvent être considérés comme des entités participant à la transmission de messages.
RabbitMQ présente les avantages suivants
- Meilleures abstractions pour le passage de messages, réduisant le travail au niveau de l'application si le passage de messages est ce dont vous avez besoin.
- Plus résistant aux pannes de courant et aux interruptions (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 asynchrones mais que vous n'êtes pas prêt à vous attaquer à l'énorme complexité de certaines des autres options de fichier d'attente de cette liste (voir ci-dessous).
ActiveMQ
Si vous êtes dans le domaine de l'entreprise (ou si vous construisez 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 la peine d'être regardé.
C'est là que ActiveMQ excelle :
- Il est implémenté en Java et dispose donc d'une intégration Java très soignée (suit le standard JMS).
- Plusieurs protocoles sont pris en charge : AMQP, MQTT, STOMP, OpenWire, etc.
- Gestion de la sécurité, du routage, de l'expiration des messages, de l'analyse, etc.
- Prise en charge des modèles de messagerie distribuée les plus courants, ce qui vous permet de gagner du temps et de ne pas commettre d'erreurs coûteuses.
Cela ne veut pas dire qu'ActiveMQ n'est disponible que pour Java. Il dispose de clients pour Python, C/C, Node, .Net et d'autres écosystèmes, de sorte qu'il n'y a pas lieu de s'inquiéter d'un éventuel effondrement à l'avenir. En outre, ActiveMQ est construit sur des normes complètement ouvertes et il devrait être facile de construire vos propres clients légers.
Cela dit, sachez qu'ActiveMQ n'est qu'un courtier et n'inclut pas de backend. Vous devrez toujours utiliser l'un des backends supportés pour stocker les messages. Je l'ai inclus ici parce qu'il n'est pas lié à un langage de programmation particulier (comme d'autres solutions populaires telles que Celery, Sidekiq, etc.)
Amazon MQ
Amazon MQ mérite une mention rapide mais importante. Si vous pensez qu'ActiveMQ est la solution idéale pour vos besoins mais que vous ne voulez pas vous occuper de la construction et de la maintenance de l'infrastructure vous-même, Amazon MQ offre 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 d'autre chose que de l'utiliser. Il est encore plus intéressant pour les déploiements sur AWS, car vous pouvez exploiter d'autres services et offres directement à partir de votre déploiement (transferts de données plus rapides, par exemple).
Amazon SQS
Nous ne pouvons pas attendre d'Amazon qu'il reste tranquille lorsqu'il s'agit d'éléments d'infrastructure critiques, n'est-ce pas ? 🙂 .
Nous avons donc Amazon SQS, qui est un service de file d'attente simple (littéralement) entièrement hébergé par le géant bien connu AWS. Une fois de plus, les différences subtiles sont importantes, alors veuillez noter que SQS n'a pas le concept de passage de messages. Comme Redis, il s'agit d'un simple backend pour accepter et distribuer des travaux dans des fichiers d'attente.
Alors, quand voudriez-vous utiliser Amazon SQS ? Voici quelques raisons :
- Vous êtes un fan d'AWS et ne voulez toucher à rien d'autre (honnêtement, il y a beaucoup de gens comme ça, et je pense qu'il n'y a rien de mal à cela).
- Vous avez besoin d'une solution hébergée pour vous assurer que le taux d'échec est nul et qu'aucun travail n'est perdu.
- Vous ne voulez pas construire un cluster et devoir le surveiller vous-même. Ou, pire encore, vous devez créer des outils de surveillance alors que vous pourriez consacrer ce temps à des activités de développement productives.
- Vous avez déjà investi des sommes considérables dans la plateforme AWS et il est logique que vous y restiez attaché.
- Vous voulez un système de fichier d'attente simple et ciblé, sans les complications liées au passage de messages, aux protocoles, etc.
Dans l'ensemble, Amazon SQS est un choix solide pour tous ceux qui souhaitent intégrer des fichiers d'attente dans leur système sans avoir à se préoccuper de l'installation et de la surveillance.
La salade de haricots
La salade de haricots existe depuis longtemps et est un backend éprouvé, rapide et facile pour les fichiers d'attente. Beanstalkd présente quelques caractéristiques qui le différencient considérablement de Redis :
- Il s'agit strictement d'un système de mise en file d'attente de travaux et rien d'autre. Vous lui envoyez des travaux, qui sont ensuite traités par des travailleurs. Par conséquent, si votre application a un besoin, même minime, de transmission de messages, vous devriez éviter Beanstalkd.
- Il n'y a pas de structures de données avancées comme des ensembles, des fichiers d'attente prioritaires, etc.
- Beanstalkd est ce que l'on appelle un fichier d'attente FIFO (First In, First Out). Il n'y a aucun moyen de classer les travaux par priorité.
- Il n'y a pas d'options de regroupement.
Ceci dit, Beanstalkd est un système de file d'attente simple et rapide pour les projets simples qui vivent sur un seul serveur. Pour beaucoup, il est plus rapide et plus stable que Redis. Donc si vous avez des problèmes avec Redis que vous n'arrivez pas à résoudre, et que vos besoins sont simples, Beanstalkd vaut la peine d'être essayé.
Conclusion
Si vous avez lu jusqu'ici (ou êtes arrivé ici en lisant superficiellement 😉 ), il y a de fortes chances que vous soyez intéressé par les systèmes de files d'attente ou que vous ayez besoin d'un système de files d'attente. Si c'est le cas, la liste de cette page vous sera utile, à moins que vous ne cherchiez un système de file d'attente spécifique à un langage ou à un cadre de travail.
J'aimerais pouvoir vous dire que les fichiers d'attente sont simples et fiables à 100 %, mais ce n'est pas le cas. C'est compliqué, et comme tout se passe en arrière-plan et très rapidement, les erreurs peuvent passer inaperçues et devenir très coûteuses. Néanmoins, les fichiers d'attente sont indispensables au-delà d'un certain point, et vous découvrirez qu'elles constituent une arme puissante (peut-être même la plus puissante) dans votre arsenal. Bonne chance ! 🙂 .
-
J'écris sur, autour et pour l'écosystème des développeurs. Recommandations, tutoriels, discussions techniques - quoi que je publie, je fais de mon mieux pour dissiper la confusion et le flou, et fournir des réponses concrètes basées sur l'expérience personnelle... en savoir plus