Gültige Architektur für ein Message Queue & Worker System in PHP?

Meine Vorschläge gehen im Grunde auf: Halte es einfach !

In diesem Sinne ist mein erster Vorschlag, die DispatcherWorker fallen zu lassen. Nach meinem derzeitigen Verständnis besteht der einzige Zweck des Arbeiters darin, auf die Warteschlange MAIN zu warten und Nachrichten an die verschiedenen Aufgabenwarteschlangen weiterzuleiten. Ihre Anwendung sollte dafür sorgen, dass die richtige Nachricht in die richtige Warteschlange (oder das richtige Thema) eingereiht wird.

Antworten auf Ihre Fragen:

  

Meine Mitarbeiter würden in PHP geschrieben werden, alle müssen den Cloud Queue Service abfragen? das könnte teuer werden, vor allem, wenn Sie viele Arbeiter haben.

Ja, es gibt kein kostenloses Mittagessen. Natürlich können Sie die Worker-Polling-Rate je nach Anwendungsnutzung (wenn mehr Nachrichten eintreffen, Poll-Rate erhöhen) nach Tag / Woche anpassen und optimieren (wenn Ihre Benutzer zu bestimmten Zeiten aktiv sind) und so weiter. Denken Sie daran, dass die Entwicklungskosten bald höher sein könnten als die nicht optimierten Abfragen.

Stattdessen sollten Sie Push-Warteschlangen in Betracht ziehen (siehe unten).

  

Ich dachte, vielleicht hätte ich nur einen Arbeiter, um die Warteschlange abzufragen, und wenn es Nachrichten gibt, benachrichtige die anderen Arbeiter, dass sie Jobs haben, ich muss nur diesen einen Arbeiter online halten, vielleicht mit supervisord? Ist diese Abfragemethode besser als die Verwendung eines MQ, der benachrichtigt werden kann? Wie soll ich das MQ einmal pro Sekunde oder so schnell abfragen? und dann die Umfragearbeiter erhöhen, wenn ich sehe, dass es langsamer wird?

Das klingt zu kompliziert. Die Kommunikation ist unzuverlässig, es gibt jedoch zuverlässige Nachrichtenwarteschlangen. Wenn Sie keine Daten verlieren möchten, bleiben Sie bei den Nachrichtenwarteschlangen und erfinden Sie keine benutzerdefinierten Protokolle.

  

Ich dachte auch daran, eine einzige Warteschlange für alle Nachrichten zu haben, und dann die Überwachung, die die Nachrichten an andere Cloud-MQs verteilt, je nachdem, wo sie verarbeitet werden müssen, da möglicherweise eine Nachricht von zwei diff-Workern verarbeitet werden muss .

Wie bereits erwähnt, sollte die Anwendung Ihre Nachricht bei Bedarf in mehrere Warteschlangen einreihen. Dies hält die Dinge einfach und an Ort und Stelle.

  

Benötige ich immer noch einen Getriebemanager, um meine Arbeiter zu managen, oder kann ich einfach Supervisor verwenden, um Arbeiter auf und ab zu drehen?

Es gibt so viele Nachrichtenwarteschlangen und noch mehr Möglichkeiten, sie zu verwenden. Im Allgemeinen müssen Sie, wenn Sie Poll Queues verwenden, Ihre Mitarbeiter selbst am Leben erhalten. Wenn Sie jedoch Push-Warteschlangen verwenden, ruft der Warteschlangendienst einen von Ihnen angegebenen Endpunkt auf. Daher müssen Sie nur sicherstellen, dass Ihre Mitarbeiter verfügbar sind.

  

Grundsätzlich, wie könnte ich den MQ so effizient und effektiv wie möglich überprüfen?

Dies hängt von Ihren geschäftlichen Anforderungen und der Arbeit Ihrer Mitarbeiter ab. Welche Zeitspannen sind kritisch? Sekunden, Minuten, Stunden, Tage? Wenn Sie Mitarbeiter zum Senden von E-Mails verwenden, sollte dies nicht Stunden dauern, im Idealfall ein paar Sekunden. Gibt es einen Unterschied (für den Benutzer) zwischen dem Abruf alle 3 Sekunden oder alle 15 Sekunden?

Lösung Ihres Problems (mit Push-Warteschlangen):

  

Mein Ziel ist es, Nachrichten / Daten, die an mehrere APIs von Drittanbietern gesendet werden müssen, zu entlasten. Der Zugriff darauf verlangsamt den Client nicht. Daher ist es ideal, die Daten an eine Nachrichtenwarteschlange zu senden. Ich überlegte, nur Gearman zu verwenden, um die MQ / Jobs zu halten, aber ich wollte einen Cloud Queue-Dienst wie SQS oder Rackspace Cloud Queues verwenden, so dass ich die Nachrichten nicht verwalten müsste.

Tatsächlich passt das von Ihnen beschriebene Szenario gut zu Nachrichtenwarteschlangen. Wie Sie erwähnt haben, möchten Sie die Nachrichtenwarteschlange selbst nicht verwalten, vielleicht möchten Sie die Mitarbeiter auch nicht verwalten? Dies ist der Ort, an dem Push-Warteschlangen erscheinen.

Push-Warteschlangen rufen Ihren Worker im Grunde auf. Amazon ElasticBeanstalk Worker Environments beispielsweise führen im Hintergrund das "Heavy Lifting" (Polling) durch und rufen Ihre Anwendung einfach mit einer HTTP-Anforderung auf, die die Warteschlangennachricht enthält ( Details finden Sie in den Dokumenten ). Ich habe persönlich die AWS-Push-Warteschlangen verwendet und bin glücklich darüber, wie einfach sie sind. Beachten Sie, dass es andere Anbieter für Push-Warteschlangen wie Iron.io gibt.