Mise en file d’attente des tâches Laravel pour qu’elles soient traitées par un travailleur

Qu’est-ce qu’un emploi dans Laravel ?

Il y a beaucoup de choses à décortiquer ici.

Tout d’abord, les jobs sont diverses tâches que nous faisons exécuter par Laravel. Plus précisément, ce sont des choses à faire en arrière-plan, donc elles sont souvent utilisées pour quelque chose qui pourrait prendre un certain temps.

En tant que développeurs, nous pouvons créer des tâches personnalisées pour à peu près tout ce que nous voulons, et nous le ferons couramment pour les tâches à forte intensité d’E/S comme l’importation/exportation de grands ensembles de données. Il convient également de noter que certaines autres parties de Laravel couramment utilisées peuvent être assez facilement transformées en tâches, comme les notifications. Les notifications sont de courts messages que Laravel peut envoyer. Nous les utilisons couramment pour l’envoi d’emails et de messages SMS.

Laravel nous présente des files d’attente que nous pouvons utiliser afin d’aligner une série de tâches. En faisant cela, ils seront traités de manière séquentielle. Le mécanisme pour faire cela est assez flexible pour vous laisser décider de la technologie utilisée pour stocker vos files d’attente (DB/Redis/Beanstalkd/SQS), et peut facilement être mis en place dans un environnement de dev également.

Le travailleur est un processus séparé qui est dédié au traitement des travaux dans votre file d’attente. L’ajout d’un processus de travailleur permet de relier tous ces éléments et d’améliorer l’interface utilisateur, l’évolutivité et la flexibilité, tout en conservant un code standardisé et élégant à lire.

Amélioration de l’expérience utilisateur (UX)

Les améliorations de l’expérience utilisateur sont réalisées grâce à la séparation de ces tâches en travaux qui sont exécutés dans un processus différent. Parfois, les tâches exécutées sont nécessaires pour que le système fonctionne, mais ne doivent pas nécessairement être exécutées instantanément.

Un bon exemple de ceci serait un site qui est accessible au public. Disons que notre site est un site que tout le monde peut visiter et remplir un formulaire d’inscription. Supposons également que tous les administrateurs du site reçoivent une notification par e-mail chaque fois qu’une nouvelle personne s’inscrit sur le site. S’il s’agit d’un site populaire, il est probable qu’il y ait plusieurs administrateurs.

Il ne semble pas normal qu’un utilisateur remplisse le formulaire d’inscription, appuie sur suivant, puis doive s’asseoir et attendre que le site envoie tous les e-mails avant de le rediriger vers la page suivante, n’est-ce pas ? C’est un parfait exemple de cas où nous pouvons mettre des tâches en file d’attente pour que le travailleur s’en occupe, et envoyer notre utilisateur sur son chemin.

Essentiellement, nous prenons ce qui était un processus très linéaire, nous le décomposons en parties, nous catégorisons ces parties en fonction du momentelles doivent être exécutées, et nous leur permettons d’être exécutées en parallèle.

Comparaison des flux de travail entre travailleurs et non-travailleurs
Comparaison des flux de travail entre travailleurs et non-travailleurs

Évolutivité

Puisque nous pouvons exécuter les travailleurs en tant que processus distincts, il devient possible de surveiller leurs performances individuelles et de les faire évoluer si nécessaire. Il est possible de configurer plusieurs travailleurs et de les répartir sur plusieurs serveurs de votre groupe pour optimiser les performances.

Flexibilité

Nous disposons d’une grande souplesse lorsque nous utilisons les tâches, les files d’attente et les travailleurs comme ils ont été conçus. Les tâches peuvent être configurées de manière à ce qu’elles soient tentées plusieurs fois en cas d’échec. Cela peut être spécifié globalement sur notre processus de travail, ou même sur une base par travail.

Les tâches sont également capables d’utiliser un intergiciel. Ceci est particulièrement utile lorsque vous avez plusieurs tâches qui doivent se comporter de manière similaire. Nous avons déjà tiré parti de l’utilisation d’un intergiciel basé sur les tâches pour nous assurer que les SMS ne sont envoyés qu’à certaines heures de la journée. Il est possible de configurer l’intergiciel pour qu’il vérifie l’heure actuelle et reprogramme la tâche à une heure ultérieure si elle ne correspond pas à certains critères. Maintenant que nous avons défini cet intergiciel, il ne nous reste plus qu’à spécifier si nous voulons qu’il soit utilisé sur une base par tâche/notification.

Puissance

Même si le système de Laravel est robuste, il est assez simple à mettre en place. La façon dont vous configurez votre site pour utiliser les jobs/queues/workers dépendra des différentes technologies que vous utilisez. De nombreux détails pertinents peuvent être trouvés dans la documentation officielle. Quelles que soient les technologies que vous choisirez, vous disposerez d’une grande puissance au bout des doigts. Vous pourrez classer les tâches par ordre de priorité et les planifier, elles seront bien documentées et organisées, et vous pourrez même consigner les tâches qui ont échoué. Si vous vous trouvez dans une situation où des tâches ont échoué et que vous voulez y remédier, vous avez même la possibilité de les réessayer !

Embûches

Il n’y a pas beaucoup d’inconvénients à l’utilisation de jobs/queues/workers, mais il y a quelques points qu’il est important de souligner. Tout d’abord, lorsque vous configurez votre installation, vous devez spécifier les pilotes que vous utiliserez pour établir une connexion avec votre technologie de mise en file d’attente. Certaines fonctionnalités de traitement des tâches sont spécifiques à la technologie. Par exemple, l’option block_for de configuration block_for n’est disponible que pour les files d’attente redis à l’heure où j’écris ces lignes.

L’autre remarque que j’aimerais ajouter est que, comme le processus de travail est généralement lancé par une commande telle que php artisan queue:work, vous devrez vous assurer de redémarrer ce processus après avoir apporté des modifications au code de base.

Conclusion

L’utilisation d’un processus distinct pour gérer vos tâches en file d’attente présente de nombreux avantages, et ces fonctionnalités sont toutes intégrées au framework Laravel. Même si vous n’utilisez cette fonctionnalité que pour vos notifications, elle en vaut la peine. Et pour couronner le tout, du point de vue du codeur, il y a très peu de changements dans le code que vous écrivez pour envoyer vos notifications. Utilisez-vous déjà les travailleurs? Si non, qu’attendez-vous pour le faire ?