Ich habe LINE BOT gemacht, also werde ich es vorstellen. Der Quellcode ist auf Github.

Was ich gemacht habe

Es ist ein LINE BOT, der Sie benachrichtigt, wenn die eingegebene Zeit (Sekunden) abgelaufen ist. Es ist nicht interessant, aber es war ein gutes Thema für die asynchrone Verarbeitung. Unten ist ein Screenshot von dem, was ich erstellt habe. Wenn Sie jedoch "180" eingeben, werden Sie nach 180 Sekunden benachrichtigt. Natürlich müssen während dieser 180 Sekunden andere Nachrichten verarbeitet werden.

Aufgrund der Spezifikationen der LINE-API läuft das Zeitlimit für Anfragen von Benutzern jedoch innerhalb von 180 Sekunden ab, sodass keine Antwort möglich ist. Es wäre schön, wenn Sie überhaupt vor dem Timeout antworten könnten, Wenn eine große Menge an Verarbeitung kommt, schwere Verarbeitung wie Bildverarbeitung, die nicht rechtzeitig durchgeführt werden kann, So etwas wie dieser Timer kann nur nach einmaliger Rückgabe der Anfrage verarbeitet werden.

Grundlegende Richtlinien

Derzeit läuft der LINE BOT-Server wie viele andere auf Heroku. Die SSL-Kommunikation ist für LINE BOT unerlässlich, daher ist es etwas mühsam, sich selbst vorzubereiten. Dies liegt daran, dass Heroku standardmäßig möglich ist. Das ist der Vorteil von PaaS.

Ich habe auf den folgenden Artikel über die Architektur von LINE BOT verwiesen.

Artikel über LINE BOT 1.1. LINE BOT-Serverarchitektur, die auch dann sicher ist, wenn eine große Anzahl von Nachrichten eingeht
Artikel über Heroku 2.1 Worker Dynos, Background Jobs and Queueing 2.2 Background Tasks in Python with RQ

Hintergrundarbeiter für die asynchrone Verarbeitung verwenden RQ gemäß 2.2. Sie benötigen einen Redis-Server, um RQ verwenden zu können, aber Heroku ist einfach, da Sie nur ein Add-On namens RedisToGo hinzufügen müssen.

$ heroku addons:create redistogo

Wenn Sie beim Ausführen von LINE BOT mit RQ das MessageEvent grob zeichnen, wenn eine Nachricht vom Benutzer empfangen wird, ist die Reihenfolge wie in der folgenden Abbildung dargestellt.

Anforderungen (Absender-ID, Nachricht, Antworttoken) kommen vom LINE-Server zum BOT-Server
Antworten Sie mit dem Antworttoken auf eine Nachricht an den LINE-API-Server (nicht erforderlich).
Registrieren Sie den Job für die Nachricht in RQ (Job Queue).
Geben Sie 200 an den LINE-Server zurück
Entfernen Sie den Job aus der Jobwarteschlange
Verarbeiten Sie den Job
Benachrichtigen Sie den LINE API-Server über das Auftragsergebnis

Hier wird die an den LINE-API-Server gesendete Nachricht auf dem LINE-Bildschirm des Benutzers angezeigt. Wichtig ist, dass die Zeit von 1 bis 4 sowohl in Bezug auf LINE als auch in Bezug auf Heroku begrenzt ist. Das Antworttoken hat übrigens auch ein Ablaufdatum. Wenn Sie es verwenden, lassen Sie es uns schnell verwenden. Und sofort 200 an den LINE-Server zurückgeben. Wenn Sie die Absender-ID kennen, können Sie jederzeit 5-7 ausführen. (Es ist ein Problem, dass die Ergebnisbenachrichtigung zu spät ist.)

In diesem LINE BOT existieren die folgenden drei Prozesse. Ich konnte nicht für jede Anforderung einen Timer-Thread erstellen, daher habe ich beschlossen, den Timer mit Redis zu verwalten.

LINE BOT-Server: Akzeptiert Anforderungen und registriert Jobs in RQ
RQ-Mitarbeiter: Nehmen Sie einen Job heraus und registrieren Sie einen Timer in der sortierten Gruppe von Redis (nach festgelegter Zeit sortieren).
Timer-Mitarbeiter: Überwacht regelmäßig Redis, benachrichtigt den Absender, wenn ein Timer die eingestellte Zeit erreicht hat, und löscht den Timer.

Der Timer-Worker wird in der obigen Reihenfolge nicht angezeigt. Da der RQ-Worker nur ausgeführt wird, wenn der Job registriert ist, ist das Timing des Timers unbekannt. Daher erkennt der Timer-Worker, ob der Timer die eingestellte Zeit erreicht hat, und benachrichtigt den LINE-API-Server.

Heroku-Free-Frame-Restriktionsmaßnahmen

Quellcode dieser Zeit, aber es funktioniert nicht mit Herokus freiem Frame wie er ist. Ich habe einen Webserver und zwei Hintergrundarbeiter in der Procfile angegeben. Dies liegt daran, dass Sie in der freien Stufe jeweils nur zwei Dynos festlegen können.

`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.

Aus diesem Grund habe ich leider die Methode gewählt, denselben Quellcode nur in Procfile zu ändern und als zwei Apps bereitzustellen.

`Procfile für LINE BOT`


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

`Procfile für Timer`


timer_worker: python timer_worker.py

In diesem Fall müssen die beiden Apps eine Verbindung zum gleichen Redis-Server herstellen. Daher müssen Sie die von einer App erstellte RedisToGo-Add-On-Umgebungsvariable REDISTOGO_URL auf die Umgebungsvariable der anderen App setzen.

Bonus

Der LINE BOT, den ich dieses Mal erstellt habe, verarbeitet nicht viel für die Eingabe, sodass andere Fehler als Zahlen auftreten.

Übrigens habe ich auch einen LINE BOT erstellt, der die Eingabe morphologisch analysiert und ein Durcheinander verursacht (Quellcode: github).

Asynchrone Verarbeitung mit LINE BOT: RQ (Redis Queue) in Python