Traitement asynchrone avec LINE BOT: RQ (Redis Queue) en Python

J'ai créé LINE BOT, je vais donc le présenter. Le code source est sur github.

• Qu'est-ce que LINE BOT?
• Introduction de l'API de messagerie | LINE Business Center
• [Pour ceux qui ont raté le boom du Bot], j'ai résumé le Chat Bot.

Ce que j'ai fait

C'est un LINE BOT qui vous avertit lorsque le temps entré (secondes) s'est écoulé. Ce n'est pas intéressant, mais c'était un bon sujet pour le traitement asynchrone. Ci-dessous, une capture d'écran de ce que j'ai créé, mais si vous tapez «180», vous serez averti après 180 secondes. Bien entendu, d'autres messages doivent être traités pendant ces 180 secondes.

Cependant, en raison des spécifications de l'API de LINE, les demandes des utilisateurs expirent dans les 180 secondes et ne peuvent pas être traitées. Ce serait bien si vous pouviez répondre avant l'expiration du délai en premier lieu, Lorsqu'une grande quantité de traitement intervient, un traitement lourd tel qu'un traitement d'image qui ne peut pas être effectué à temps, Quelque chose comme ce minuteur ne peut être traité qu'après avoir renvoyé la demande une fois.

Politique de base

Pour le moment, le serveur LINE BOT fonctionne sur heroku comme beaucoup d'autres le font. La communication SSL est essentielle pour LINE BOT, il est donc un peu gênant de se préparer soi-même, C'est parce que heroku est possible par défaut. C'est l'avantage du PaaS.

Je me suis référé à l'article suivant sur l'architecture de LINE BOT.

1. Articles sur LINE BOT 1.1. Architecture de serveur LINE BOT sûre même si un grand nombre de messages arrivent

2. Articles sur heroku 2.1 Worker Dynos, Background Jobs and Queueing 2.2 Background Tasks in Python with RQ

Les travailleurs d'arrière-plan pour le traitement asynchrone utilisent RQ selon 2.2. Vous avez besoin d'un serveur Redis pour utiliser RQ, mais heroku est facile car il vous suffit d'ajouter un module complémentaire appelé RedisToGo.

$ heroku addons:create redistogo

Lorsque vous effectuez LINE BOT avec RQ, si vous dessinez approximativement l'événement MessageEvent lorsqu'un message est reçu de l'utilisateur, la séquence sera comme indiqué dans la figure ci-dessous.

1. Les demandes (ID de l'expéditeur, message, jeton de réponse) arrivent du serveur LINE vers le serveur BOT
2. Répondre à un message au serveur de l'API LINE à l'aide du jeton de réponse (non requis)
3. Enregistrez le travail pour le message dans RQ (Job Queue)
4. Renvoyez 200 au serveur LINE
5. Supprimez le travail de la file d'attente des travaux
6. Traitez le travail
7. Informez le serveur API LINE du résultat du travail

Ici, le message envoyé au serveur API LINE est affiché sur l'écran LINE de l'utilisateur. L'important est que le temps de 1 à 4 soit limité à la fois en termes de LINE et d'heroku. À propos, le jeton de réponse a également une date d'expiration. Si vous l'utilisez, utilisons-le rapidement. Et renvoyez immédiatement 200 au serveur LINE. Si vous connaissez l'ID de l'expéditeur, vous pouvez exécuter 5-7 à tout moment. (C'est un problème que la notification de résultat est trop tardive)

Dans ce LINE BOT, les trois processus suivants existent. Je ne pouvais pas créer de fil de minuterie pour chaque demande, j'ai donc décidé de gérer le minuteur avec Redis.

• Serveur LINE BOT: Accepte les demandes et enregistre les travaux dans RQ
• Travailleur RQ: prenez un travail et enregistrez une minuterie dans l'ensemble trié de Redis (tri par heure définie)
• Travailleur de la minuterie: surveille régulièrement Redis, informe l'expéditeur s'il y a une minuterie qui a atteint l'heure définie et supprime la minuterie.

L'outil Timer n'apparaît pas dans la séquence ci-dessus, Etant donné que le worker RQ n'est exécuté que lorsque le travail est enregistré, la synchronisation du temporisateur est inconnue. Par conséquent, le travailleur du minuteur détecte si le minuteur a atteint l'heure définie et avertit le serveur API LINE.

mesures de restriction de cadre gratuit heroku

Code source de cette époque, mais cela ne fonctionnera pas avec le cadre libre d'heroku tel quel. J'ai spécifié un serveur Web et deux travailleurs en arrière-plan dans Procfile, En effet, vous ne pouvez définir que deux dynamomètres à la fois dans l'offre gratuite.

Procfile

web: gunicorn app:app
rq_worker: python rq_worker.py
timer_worker: python timer_worker.py

$ heroku ps:scale rq_worker=1 timer_worker=1
Scaling dynos... !
 !    Cannot run more than 2 Free size dynos.

Pour cette raison, malheureusement, j'ai pris la méthode de modification du même code source uniquement dans Procfile et de le déployer en tant que deux applications.

Procfile pour LINE BOT

web: gunicorn app:app
rq_worker: python rq_worker.py

Procfile pour la minuterie

timer_worker: python timer_worker.py

Dans ce cas, les deux applications doivent se connecter au même serveur Redis, vous devez donc définir la variable d'environnement du module complémentaire RedisToGo REDISTOGO_URL créée par une application sur la variable d'environnement de l'autre application.

prime

Le LINE BOT que j'ai créé cette fois ne traite pas beaucoup de données d'entrée, donc des erreurs autres que des nombres se produiront.

Au fait, j'ai aussi fait un LINE BOT qui analyse morphologiquement l'entrée et fait un désordre (code source: github).