perform_later und deliver_later funktionieren wie bisher.
Was dieses Tutorial behandelt
- Solid Queue und seine Tabellen zu einer bestehenden Anwendung hinzufügen.
- Active Job Umgebung für Umgebung darauf ausrichten.
- Solid Queue mit seinem eigenen Befehl oder mit dem Puma-Plugin ausführen.
- Die von ihm erstellten Tabellen lesen und die Reihenfolge steuern, in der Jobs laufen.
Voraussetzungen
Rails 8 generiert neue Anwendungen bereits mit konfiguriertem Solid Queue. Wenn Sie
rails new unter Rails 8 ausgeführt haben, ist der Installationsschritt bereits erledigt. Sie können direkt zum Ausführen des Workers übergehen.Solid Queue installieren
Fügen Sie das Gem hinzu, installieren Sie seine Migrationen, und migrieren Sie:Active Job auf Solid Queue ausrichten
Legen Sie den Queue-Adapter pro Umgebung fest, inconfig/environments/development.rb und erneut in config/environments/production.rb:
config/environments/test.rb beim :test-Adapter, sofern Sie keinen Grund haben, das nicht zu tun. Tests, die Behauptungen über eingereihte Jobs aufstellen, lassen sich mit dem Test-Adapter leichter schreiben.
Das Setzen des Adapters bewirkt nur, dass Rails Jobs in die Datenbank schreibt. Nichts führt sie aus, solange der Worker-Prozess nicht läuft. Ein Einreihen, bei dem nichts passiert, ist in dieser Phase also zu erwarten und keine Fehlkonfiguration.
Den Worker ausführen
Als eigener Prozess
Procfile betreiben und mehrere Prozesse verwalten.
Innerhalb von Puma
Wenn Sie lieber keinen zweiten Prozess verwalten möchten: Solid Queue liefert ein Puma-Plugin. Fügen Sie es zuconfig/puma.rb hinzu:
bin/rails server Ihnen beides gibt. Standardmäßig forkt Solid Queue separate Worker- und Dispatcher-Prozesse. Die Puma-Integration von AppSignal meldet die Kapazität des Webservers, nicht die der Jobs. Verwenden Sie die Active-Job-Integration, um die Job-Performance zu überwachen.
Was Solid Queue speichert
Jeder Teil des Zustands von Solid Queue ist eine Active-Record-Tabelle. Sie können ihn über die Rails-Konsole abfragen, statt einen separaten Dienst zu befragen.
Die Zeile eines Jobs lesen und korrigieren zu können, ist ein echter Unterschied zu Redis-basierten Queues. Dort wird von der Bearbeitung eines Jobs an Ort und Stelle abgeraten. Greifen Sie darauf zurück, um einen Fehler zu beheben, nicht als routinemäßigen Teil des Ausführens von Jobs.
Queue-Reihenfolge und Priorität
Zwei Mechanismen entscheiden, was als Nächstes läuft, und sie wirken zusammen. Queue-Reihenfolge. Ein Worker, der mit einer Liste von Queues konfiguriert ist, leert sie in der angegebenen Reihenfolge. Ein Worker, derreal_time und dann background abhört, leert real_time jedes Mal zuerst.
Priorität. Jobs tragen außerdem eine ganzzahlige Priorität. Niedriger gewinnt, und die Zählung beginnt bei null, sodass eine Priorität von 0 eine Priorität von 1 übertrifft.
Solid Queue mit AppSignal überwachen
AppSignal instrumentiert Solid Queue über seine Solid-Queue-Integration und, für alles, was über Active Job eingereiht wird, über seine Active-Job-Integration. Jobs werden im Namespacebackground gemeldet, getrennt von Web-Requests. Ein langsamer Job verzerrt Ihre Request-Perzentile nicht.
Zwei Dinge lohnt es sich, einmal einzurichten, sobald Solid Queue läuft:
- Fehler aus fehlgeschlagenen Jobs. Eine Zeile in
solid_queue_failed_executionssagt Ihnen, dass ein Job eine Exception ausgelöst hat. AppSignals Fehler-Tracking sagt Ihnen, was er ausgelöst hat, wie oft, und mit welchen Argumenten. - Job-Dauer und queue time. Jeder Job erhält einen Performance-Trace, aufgeschlüsselt in die Events, die er durchlaufen hat. Die Active-Job-Integration meldet, wie lange Jobs warten, bevor sie laufen. Eine steigende queue time kann bedeuten, dass Jobs schneller eintreffen, als die Worker sie verarbeiten können.
Transkript
Aus dem Video transkribiert und leicht bearbeitet. Die automatischen Untertitel haben mehrere Produkt- und API-Namen falsch verstanden, und diese wurden korrigiert.Transkript lesen
Transkript lesen
0:02 Hallo zusammen, in dieser Lektion geht es darum, wie Sie Solid Queue in Ihren Rails-Anwendungen verwenden. Wenn Sie von einem anderen Active-Job-Backend kommen, vielleicht Sidekiq: Sidekiq braucht Redis, damit die Jobs übertragen werden. Ihre Rails-App sendet also eine Nachricht an Redis, Redis wird von Sidekiq beobachtet, und das stößt die Jobs an. Good Job ist ein ähnliches Werkzeug, das aber Ihre Postgres-Datenbank verwendet, und Solid Queue ist dem sehr ähnlich: Es verwendet die Datenbank Ihrer Rails-Anwendung. Sie führen also eine Migration aus, fügen einige Tabellen hinzu, und ein Prozess läuft und überwacht Ihre Datenbank auf Jobs.0:41 Das Coole daran: Sie brauchen keinen zusätzlichen Dienst wie Redis. Wenn Sie es für nichts anderes verwendet haben, müssten Sie Redis erst hinzufügen, um Sidekiq zu nutzen, und das hier ist ein Weg, einfach die vorhandene Datenbank zu verwenden, die Sie bereits haben. Richten wir also ein Beispiel ein. Ich starte eine brandneue Rails-App, und zur Referenz zeige ich Ihnen: Wir sind auf Rails 7.1. Wir führen
rails new aus und nennen unsere Anwendung Solid Queue Example. Wir kommen in einem Moment zurück, wenn das erstellt ist, und fügen Solid Queue hinzu und reihen ein paar Jobs ein. Gut, gehen wir in unser Solid Queue Example, und wir machen bundle add solid_queue, um es zu unserem Gemfile hinzuzufügen.1:30 Der nächste Schritt ist, die Migrationen zu installieren und dann db:migrate auszuführen. Das wird sich vermutlich noch ändern, es wird wahrscheinlich ein Installationsskript geben, das das übernimmt, denn eine weitere Sache, die es momentan braucht, ist eine Konfigurationsdatei. Wir führen das aus, um die Migrationen zu installieren, dann können wir rails db:migrate sagen, um das zu unserer Datenbank hinzuzufügen. Ich verwende in diesem Beispiel SQLite, aber Sie können auch Postgres oder MySQL verwenden, und Unterstützung für MS SQL und anderes wird wahrscheinlich bald hinzukommen, und es wird hier auch weitere Verbesserungen geben. Aber hier sehen Sie, dass eins, zwei, drei, vier, fünf, sechs, sieben, acht, neun Tabellen erstellt werden, um Ihren Job zu verwalten.2:14 Sie können sich diese später ansehen und sehen, was sie tun, während wir Jobs einreihen und so weiter, aber testen wir erst mal den Befehl. Ich zeige Ihnen, dass er gerade abstürzt und sagt, dass keine Konfigurationsdatei gefunden wurde. Wir können also config/solid_queue.yml anlegen, und jetzt kann unser Solid-Queue-Prozess laufen. Das funktioniert einwandfrei. Standardmäßig startet er einen Dispatcher und einen Worker, die alle Queues abhören.2:50 Der Dispatcher ist im Grunde der Supervisor, der alle Worker verwaltet und die Prozesse und alles Weitere im Blick behält. Die Worker übernehmen die eigentliche Verarbeitung des Jobs. Standardmäßig hört das also alle Queues ab, hat eine Thread-Pool-Größe von fünf und richtet dafür einen Prozess mit der Standardkonfiguration ein. Sie können das immer für Ihren Anwendungsfall anpassen und sagen, wir brauchen 10 Prozesse, die unterschiedliche Queues bedienen müssen, und all das, aber wir bleiben vorerst bei diesen Standardwerten. Jetzt können wir eine Rails-Anwendung ausführen und ein paar Jobs erstellen.3:26 Wir können also entweder einen Mailer generieren, sagen wir einen User-Mailer, um Nutzer zum Beispiel über eine Zahlungsbestätigung zu benachrichtigen. Oder wir erstellen einfach einen Job, etwa einen Import-Job, der etwas zu erledigen hat. Anschließend können wir die Rails-Konsole öffnen. Zuerst gehen wir aber in unsere Config-Environments. Das machen wir gleich.3:57 Wir gehen in config/environments und setzen dort eine Config-Zeile: config.active_job.queue_adapter = :solid_queue. Das ist die Zeile, die die Magie macht und Active Job mit Solid Queue verdrahtet, und ab dann werden Jobs in die Datenbank geschrieben. Dann brauchen wir noch den separaten Prozess, der die Job-Worker und den Dispatcher tatsächlich ausführt, damit die Arbeit erledigt wird. Denn wenn wir es dabei belassen, reiht Rails Jobs ein, aber niemand hört ihnen zu, solange wir diesen anderen Prozess nicht starten. Sie können das auch in Ihre Test-Umgebung eintragen und in die Produktion.4:43 In Ihrer Test-Umgebung wollen Sie vielleicht den Test-Adapter behalten, das ist völlig in Ordnung und einfach zu handhaben. In der Produktion machen Sie das aber auch. Gut, lassen wir es vorerst bei Test mit dem Test-Adapter und richten Solid Queue in Development ein. Jetzt können wir uns unsere Rails-Anwendung ansehen. Wir öffnen die Rails-Konsole und rufen UserMailer.receipt.deliver_later auf, was den Job einreiht.5:18 Sie sehen, dass es meldet, dass Solid Queue das übernommen und einen Job eingereiht hat. Die Standard-Queue hat eine Active-Job-ID und alle weiteren Informationen von Action Mailer, und dann wurde der Mail-Delivery-Job eingereiht und an uns zurückgegeben. Wir können auch diesen Import-Job aufsetzen und perform_later darauf aufrufen. Wir tun mit diesen Jobs noch nichts, aber sie werden eingereiht, und wir können in unserer Datenbank nachsehen, was drinsteht. Da wir SQLite verwenden, haben wir im Ordner storage unsere development.sqlite-Datenbank.6:00 Die öffnen wir in einem Tool wie TablePlus, um uns umzusehen und zu sehen, was hier passiert. Die erste Tabelle, die wir haben, ist blocked_executions. Lassen Sie mich das vergrößern. Tabelle blocked_executions, claimed_executions, failed_executions, und in solid_queue_jobs sehen wir unsere zwei gerade hinzugefügten Jobs. Es wird noch nichts verarbeitet, die Jobs liegen einfach nur da.6:29 Sie haben die übergebenen Argumente, Prioritäten, mit denen Sie sagen können, dass dieser Job wichtiger ist als ein anderer, außerdem die Active-Job-ID, wann er geplant war, wann er erstellt und aktualisiert wurde, und es wird auch festgehalten, wann er fertig war. Das sind also alle Job-Informationen. Es gibt solid_queue_pauses, es sieht so aus, als könnten wir damit einen Job pausieren und seine Ausführung mitten drin anhalten. Wir haben unsere Prozesse: Wenn wir unsere Solid-Queue-Worker starten, taucht das hier auf. Wir sehen den letzten Heartbeat, und das wird mitverfolgt.7:10 Wir haben außerdem ready_executions und scheduled_executions. Wir können also Jobs haben, und diese Executions, und wenn wir diese Jobs erstellen, wird automatisch eine Execution dafür eingerichtet. Wir könnten also einen Job erstellen und ihn für später einplanen. Er könnte auch wiederkehrend sein. Das ist eingerichtet, um vieles davon für uns zu übernehmen.7:30 Wir müssen nicht viel darüber wissen, wie es intern funktioniert, aber wir sollten diese Prioritäten und die Queues kennen, denn die Queues bestimmen auch, wie Jobs behandelt werden. Und ich weiß, dass das hier auch erwähnt wird. Äh, äh, äh … Da ist es, Queue-Reihenfolge und Prioritäten. Wenn Sie für einen Worker eine Liste von Queues angeben, werden diese in der angegebenen Reihenfolge abgearbeitet. Wenn Sie also real_time und background wählen, haben Jobs aus real_time immer Vorrang vor den anderen.8:03 Sie können Jobs aber auch ganzzahlige Prioritäten geben. Sie können also eine Priorität von null oder eine Priorität von eins festlegen. Die Priorität null ist immer wichtiger, und die Zählung beginnt bei null, ähnlich wie bei einem Array. Null ist also das erste Element, eins das nächste, und so weiter.8:26 So weit dazu, und hier sehen wir diese Priorität in unseren Executions. Jetzt können wir unseren Befehl ausführen, um Solid Queue zu starten. Rails würde in einem Server in einem anderen Prozess laufen, und wir würden Jobs einreihen, was von Rake-Tasks oder von überall herkommen könnte, genau wie Sie Active Job sonst auch verwenden würden. Wir sehen, dass es diese beiden Jobs ausführt und dass sie fertig sind. Job Nummer zwei war schneller als Job Nummer eins, die E-Mail, und es hat beide Jobs abgeholt und gibt einfach die typische Ausgabe aus, die Sie normalerweise auch in Ihren Sidekiq-Logs sehen würden.9:10 Das ist eigentlich schon alles. Es gibt nicht wahnsinnig viel Interessantes zu entdecken. Wir sehen, dass diese Prozesse hier jetzt sichtbar sind, sodass wir unsere Datenbank abfragen können. Wenn wir in einem Dashboard sehen wollen, ob und wie viele Worker wir haben und was sie tun, können wir einfach die Datenbank abfragen, statt mit einem anderen Prozess unter Linux oder Ähnlichem sprechen zu müssen. Wir haben all diese Informationen direkt in Rails-Modellen verfügbar, was wirklich toll ist.9:44 Eine der Sachen, von denen bei Sidekiq abgeraten wird, ist zum Beispiel, einen Job zu löschen oder Ähnliches. Hier haben wir einfachen Zugriff auf die Datenbank. Bei Jobs wollen Sie wahrscheinlich nicht groß herumpfuschen, aber wenn Sie mal einen Fehler gemacht haben und die Argumente eines Jobs bearbeiten oder die Priorität ändern müssen, haben Sie in Ihrer Datenbank Zugriff darauf und könnten das bei Bedarf tun. Das ist also ein ziemlich cooles Werkzeug. Das Tolle daran ist, dass wir keinen weiteren Dienst brauchen, der läuft, oder Ähnliches.10:20 Es liegt direkt bei uns in der Datenbank und braucht kein Redis oder Ähnliches. Eine weitere coole Sache, die ich zeigen möchte: Es gibt ein Plugin für Puma. Wenn Sie das in Ihren Rails-Anwendungen nicht als separaten Prozess ausführen wollen, ist das eine coole Funktion, die wir nutzen können. Viele von uns haben ja Procfiles und nutzen CSS- und JS-Bundling oder Ähnliches, sodass wir am Ende mehrere Prozesse ausführen müssen.10:48 Gehen wir in VS Code, öffnen config/puma.rb, und hier unten, neben plugin :tmp_restart, das darauf wartet, dass die tmp-restart-Datei angefasst wird und Rails neu startet, können wir auch dieses Plugin hinzufügen. Wenn Puma startet, führt es auch Solid Queue aus, und wenn Puma herunterfährt, stoppt es auch Solid Queue. Hier sehen Sie: Wenn wir unsere Rails-App mit rails server starten, bekommen wir viele Logs von Solid-Queue-Prozessen, die die Datenbank überwachen. Standardmäßig prüft es etwa alle 100 Millisekunden, also etwa 0,1 Sekunden.11:30 Ich glaube, das war der Standardwert, den ich vorhin im Code gesehen habe. Es stellt also viele Anfragen an Ihre Datenbank, aber nicht so häufig, weil Ihre Datenbanken super performant sind, und es behält sie einfach im Blick. Wenn Sie also einen Job einreihen, sollte es etwa eine Zehntelsekunde dauern, bis er erkannt wird und zu laufen beginnt. Das ist also sehr schnell und performant und läuft einfach neben allem anderen mit. Mit Strg+C fährt Puma Solid Queue herunter und stoppt auch die Rails-Anwendung, alles in einem einzigen Prozess, was ich als Funktion super praktisch finde, wenn Sie kein Procfile verwenden und noch keine separaten Prozesse verwalten.12:15 Das ist schön und eingebaut. Bei Sidekiq wollten Sie beim Deployment immer, dass es läuft und von etwas anderem überwacht wird, und das ist jetzt ein guter Weg, das zu tun. Ich glaube, mittlerweile kann Sidekiq das vielleicht auch. Aber das war eine kurze Einführung in Solid Queue. Es gibt nicht viele Funktionen, weil es im Hintergrund im Grunde einfach nahtlos funktioniert.12:39 Sie müssen einen Prozess ausführen, ein paar Tabellen zu Ihrer Datenbank hinzufügen, und schon sind Sie fertig. Das ist im Grunde alles. Es nutzt bereits das Active-Job-Backend beziehungsweise -Interface, das Sie schon gewohnt sind. Es gibt also wirklich nichts weiter für Sie zu tun. Ich empfehle sehr, sich das anzusehen.12:57 Ich glaube, das wird künftig eine große Sache werden. Es wird wahrscheinlich in viele Anwendungen eingebaut, weil es einfach ist, den Datenbankdienst zu nutzen, den Sie bereits haben. Das war’s für diese Episode. Ich hoffe, sie hat Ihnen gefallen. Wenn Sie Fragen zu Solid Queue oder Ähnlichem haben, schreiben Sie uns gerne in den Kommentaren.13:14 Wir schauen uns das an und versuchen, sie zu beantworten.