PHP Message Queue oder so...

[paulfrank]

Hallo zusammen

ich weiss nicht ob hier bereits ein Thema existiert, noch weiss ich gar nicht nach was ich suchen soll. Vielleicht könnt ihr mir helfen, da ihr eventuell bereits ein solches System am laufen habt. Meine Frage dreht sich um folgendes:

Ich habe für meinen Arbeitgeber ein Informationssystem entwickelt, welches pro Tag mehrere tausend Datensätze bearbeitet und diese an ein Web GUI weitergibt. Dazu habe ich ebenfalls ein paar Administrationsskripts hinzugefügt, welche zum Beispiel die Datenbank aufräumen nach einer gewissen Zeit. Alle diese Skripte werden über einen pseudo Cron gesteuert. Pseudo Cron deshalb, weil mir echte Cronjobs nicht zur Verfügung stehen.

Ich wollte von euch wissen ob es möglich ist, mit php eine Serveranwendung zu schreiben, an welche ich messages senden kann und diese dann aufgrund der messages funktionen aufruft ohne dass ein User einen Request gestartet hat.

Ich danke für euch bereits jetzt für die Denkanstösse und Ideen!

[zapmuc]

Hi,

geht es um echte Message Queues, d.h. die asynchrone Abarbeitung von Requests, oder nur um das Auffangen und Ausführen von requests?

Bei zweiterem würde ich einfach einen REST-Service bauen, der als Parameter den Request erhält. Anhand irgendwelcher Kennzeichen in der Message ruft er den einen oder anderen Service auf.

Message Queues würde ich wie folgt bauen:

- REST-Service zum Empfangen der Requests. Schreibt die Requests in eine DB-Tabelle

- Queue-Listener: Pollt die DB-Tabelle. Bei neuem Request, lese ihn aus und delegiere ihn an die entsprechende Verarbeitungslogik.
Achtung: hier kann es ein Synchronisationsproblem geben, wenn es mehrere Listener (=Worker Nodes) gibt. Wenn das zugrundeliegende DBMS es erlaubbt, würde ich einen Tablelock auf die Queue-Tbl setzen, den neusten Datensatz auslesen und seinen Status auf "in Arbeit" setzen, und dann den Lock auflösen. Table-Lock ist nicht schön, in dem Fall aber akzeptierbar.

Das wäre die einfachste Möglichkeit, die mir einfällt. Man kann natürlich weiterdenken, und den QueueListener mittels Subscriber-Methode so erweitern, dass sich Worker aktiv registieren können. Der Listener würde dann steuern, welcher Worker welchen Auftrag bekommt. Das lohnt aber nur, wenn mehr als ein Server und nennenswerte Last zu erwarten ist.

Hoffe, meine Denkansätze bringen Deine Überlegungen weiter....

VG,

zapmuc

[DivDax]

Oder man nutzt IronMQ, Beanstalk (self hostet).

[Slava]

Ich würde dem Auftraggeber vorschlagen, dass er selber klickt. Wen er die Schnauzer voll hat, dann soll er Server mit cron-job bestellen.

Als alternative mach cronjob, auf einer Firmenmaschine, die per http ein Skript-Aufruf macht.