Wie kann ich eine Warteschlange mit mehreren Arbeitern erstellen?
Ich möchte eine Warteschlange erstellen, in die Clients Anforderungen einfügen können, und dann können Server-Worker-Threads sie herausziehen, wenn Ressourcen verfügbar sind.
Ich untersuche, wie ich dies mit einem Firebase-Repository und nicht mit einem externen Warteschlangendienst tun könnte, der Daten in Firebase zurückspeichern müsste.
Unter Berücksichtigung von Sicherheits- und Validierungswerkzeugen hier ein einfaches Beispiel für meine Absicht:
- Benutzer schiebt eine Anfrage in einen "Queue" -Bucket
- Server ziehen die Anfrage heraus und löschen sie ( Wie stelle ich sicher, dass nur ein Server die Anfrage erhält? )
- Server validiert Daten und ruft sie aus einem privaten Bucket ab (oder injiziert neue Daten)
- Server schiebt Daten und / oder Fehler zurück in den Bucket des Benutzers
Ein vereinfachtes Beispiel dafür, wo dies nützlich sein könnte, wäre die Authentifizierung:
- Benutzer stellt Authentifizierungsanfrage in die öffentliche Warteschlange
- sein Login / Passwort geht in seinen privaten Eimer (ein Ort, den er nur lesen / schreiben kann)
- Ein Server nimmt die Authentifizierungsanfrage an, ruft Login / Passwort ab und validiert gegen den privaten Bucket, auf den nur der Server zugreifen kann
- Der Server schiebt ein Token in den privaten Bucket des Benutzers
(Sicherlich gibt es immer noch einige Sicherheitslücken in einer öffentlichen Warteschlange; ich erkunde gerade an dieser Stelle)
Einige andere Beispiele für die Verwendung:
- schreibgeschützte Statuswarteschlange (der Benutzerstatus wird über den privaten Bucket kommuniziert, der Server schreibt ihn in einen öffentlichen Bucket, der für die Öffentlichkeit schreibgeschützt ist)
- Nachrichtenwarteschlange (Nachrichten werden über den Benutzer gesendet, der Server entscheidet, in welche Diskussionsgruppen sie fallen gelassen werden)
Also sind die Fragen:
- Ist das ein gutes Design, das sich gut in die kommenden Sicherheitspläne integrieren lässt? Welche alternativen Ansätze werden untersucht?
- Wie bekomme ich alle Server dazu, die Warteschlange zu hören, aber nur einen, der jede Anfrage entgegennimmt?
2 Antworten
Wow, große Frage. Dies ist ein Nutzungsmuster, das wir intern besprochen haben, daher würden wir gerne von Ihrer Erfahrung bei der Implementierung hören ([email protected]). Hier sind einige Gedanken zu Ihren Fragen:
Authentifizierung
Wenn Ihr primäres Ziel die Authentifizierung ist, warten Sie einfach auf unsere Sicherheitsfunktionen. :-) Insbesondere beabsichtigen wir, Auth von Ihrem eigenen Backend-Server, unterstützt von einem Firebase-Shop oder von Drittanbietern (Facebook, Twitter, etc.) unterstützt zu machen.
>Work-Queue mit Lastenausgleich
Unabhängig von der Authentifizierung gibt es immer noch einen interessanten Anwendungsfall für die Verwendung von Firebase als Backbone für eine Art Workload-Balancing-System, wie Sie es beschreiben. Dafür gibt es ein paar Ansätze, die Sie ergreifen könnten:
- Wie Sie beschreiben, haben Sie eine einzige Arbeitswarteschlange, auf der alle Ihre Server Elemente beobachten und entfernen. Sie können dies erreichen, indem Sie transaction () entfernen die Gegenstände. transaction () behandelt Konflikte, so dass nur die Transaktion eines Servers erfolgreich ist. Wenn ein Server einen zweiten Server an ein Arbeitselement schlägt, kann der zweite Server seine Transaktion abbrechen und es beim nächsten Element in der Warteschlange erneut versuchen. Dieser Ansatz ist vorteilhaft, da er beim Hinzufügen und Entfernen von Servern automatisch skaliert wird, aber für jeden Transaktionsversuch ein Overhead entsteht, da er einen Roundtrip zu den Firebase-Servern durchführen muss, um sicherzustellen, dass niemand das Element bereits aus der Warteschlange übernommen hat. Aber wenn die Zeit, die für die Bearbeitung eines Workitems benötigt wird, viel länger ist als die Zeit für einen Roundtrip zu den Firebase-Servern, ist dieser Overhead wahrscheinlich keine große Sache. Wenn Sie viele Server (d. H. Mehr Konkurrenz) und / oder viele kleine Arbeitselemente haben, kann der Overhead ein Mörder sein.
- Schieben Sie den Lastenausgleich auf den Client, indem Sie ihn willkürlich aus einer Reihe von Arbeitswarteschlangen auswählen. (Haben Sie beispielsweise / queue / 0, / queue / 1, / queue / 2, / queue / 3, und lassen Sie den Client zufällig einen auswählen). Dann kann jeder Server eine Arbeitswarteschlange überwachen und die gesamte Verarbeitung besitzen. Im Allgemeinen hat dies den geringsten Overhead, aber es lässt sich beim Hinzufügen / Entfernen von Servern nicht so nahtlos skalieren (Sie müssen wahrscheinlich eine separate Liste von Arbeitswarteschlangen führen, die Server aktualisieren, wenn sie online gehen und dann Clients haben Überwachen Sie die Liste, damit sie wissen, aus wie vielen Warteschlangen Sie wählen können.).
Ich persönlich würde mich der Option # 2 zuwenden, wenn Sie eine optimale Leistung wünschen. Aber # 1 könnte für das Prototyping einfacher sein und zumindest anfangs gut funktionieren.
Im Allgemeinen ist Ihr Design definitiv auf dem richtigen Weg. Wenn Sie mit der Implementierung experimentieren und auf Probleme stoßen oder Vorschläge für unsere API haben, lassen Sie es uns wissen ([email protected]: -)!
Diese Frage ist ziemlich alt, aber für den Fall, dass es jemand hier macht ...
Seit Mitte 2015 bietet Firebase eine so genannte Firebase-Warteschlange , eine fehlertolerante Job-Pipeline für mehrere Worker, die auf Firebase basiert .
F: Ist das ein gutes Design, das sich gut in die kommenden Sicherheitspläne integrieren lässt?
A: Ihr Designvorschlag passt perfekt zur Firebase-Warteschlange.
F: Wie erhalte ich alle Server, die die Warteschlange abhören sollen, aber nur einen, der jede Anfrage entgegennimmt?
A: Nun, das ist ziemlich genau das, was Firebase Queue für Sie tut!
Referenzen:
Tags und Links firebase