Detaillierte Erläuterung der Implementierung eines Codebeispiels für die Redis-Warteschlangenpriorität

So verwenden Sie Redis, um eine Nachrichtenwarteschlange zu erstellen

Redis ist zunächst für die Verwendung im Caching konzipiert, kann aber aufgrund einiger eigener Eigenschaften auch für Nachrichtenwarteschlangen verwendet werden. Es verfügt über mehrere blockierende APIs, die verwendet werden können. Diese blockierenden APIs ermöglichen die Erstellung von Nachrichtenwarteschlangen.

Stellen Sie sich vor, dass Ihre Anforderungen unter der Idee „Datenbank löst alle Probleme“ erfüllt werden können, ohne Nachrichtenwarteschlangen zu verwenden. Wir speichern alle Aufgaben in der Datenbank und bearbeiten sie dann durch kontinuierliches Polling. Obwohl dieser Ansatz Ihre Aufgabe erfüllen kann, ist er sehr grob. Wenn Ihre Datenbankschnittstelle jedoch eine Blockierungsmethode bereitstellt, können Sie Abfragevorgänge vermeiden. Ihre Datenbank kann auch als Nachrichtenwarteschlange verwendet werden, die aktuelle Datenbank verfügt jedoch nicht über eine solche Schnittstelle.

Darüber hinaus sind auch andere Funktionen der Nachrichtenwarteschlange wie FIFO einfach zu implementieren. Sie benötigen lediglich ein List-Objekt, um Daten vom Anfang abzurufen und Daten vom Ende zu stopfen.

Redis kann dank seiner Listenobjekt-Blpop-Brpop-Schnittstelle und einigen Schnittstellen von Pub/Sub (Publish/Subscribe) als Nachrichtenwarteschlange verwendet werden. Sie sind alle blockierende Versionen und können daher als Nachrichtenwarteschlangen verwendet werden.

Rabbitmqs Priorität Ansatz

Es gibt viele ausgereifte Nachrichtenwarteschlangenprodukte, wie zum Beispiel Rabbitmq. Es ist relativ einfach zu bedienen und verfügt über relativ umfangreiche Funktionen. Es ist in allgemeinen Situationen völlig ausreichend. Was jedoch sehr ärgerlich ist, ist, dass Prioritäten nicht unterstützt werden.

Zum Beispiel hoffen einige privilegierte Benutzer beim Versenden von E-Mails, dass ihre E-Mails schneller versendet werden können, oder geben ihnen zumindest Vorrang vor normalen Benutzern. Standardmäßig kann RabbitMQ damit nicht umgehen. Die an RabbitMQ geworfenen Aufgaben sind FIFO-First-In, First-Out. Wir können jedoch einige Problemumgehungen nutzen, um diese Prioritäten zu unterstützen. Erstellen Sie mehrere Warteschlangen und legen Sie entsprechende Routing-Regeln für Rabbitmq-Konsumenten fest.

Zum Beispiel gibt es standardmäßig eine solche Warteschlange, um [Aufgabe1, Aufgabe2, Aufgabe3] zu simulieren, und die Verbraucher nehmen abwechselnd Aufgaben nach dem FIFO-Prinzip heraus, um sie zu verarbeiten . Wenn eine Aufgabe mit hoher Priorität eintrifft, kann sie nur als letzte bearbeitet werden [Aufgabe1, Aufgabe2, Aufgabe3, Higitask1]. Wenn jedoch zwei Warteschlangen verwendet werden, eine Warteschlange mit hoher Priorität und eine Warteschlange mit normaler Priorität. Normale Priorität [task1, task2, task3], hohe Priorität [hightask1] Dann legen wir das Routing des Verbrauchers fest und lassen den Verbraucher zufällig Daten aus einer beliebigen Warteschlange abrufen.

Und wir können einen Verbraucher definieren, der speziell Warteschlangen mit hoher Priorität verarbeitet. Er verarbeitet keine Daten aus Warteschlangen mit niedriger Priorität, wenn er inaktiv ist. Dies ist vergleichbar mit dem VIP-Schalter einer Bank. Normale Kunden stehen Schlange, um eine Nummer bei der Bank zu erhalten. Wenn ein VIP kommt, zieht er zwar kein Ticket aus dem Nummernausgabeautomaten, der vor normalen Mitgliedern steht. Er kann immer noch schneller direkt zum VIP-Kanal gelangen.

Wenn Sie Rabbitmq verwenden, um Prioritätsnachrichtenwarteschlangen zu unterstützen, nutzen Sie, genau wie die oben erwähnten VIP-Mitglieder derselben Bank, verschiedene Kanäle. Diese Methode verwendet jedoch nur relative Priorität und kann keine absolute Prioritätskontrolle erreichen. Ich hoffe beispielsweise, dass eine bestimmte Aufgabe mit hoher Priorität im absoluten Sinne zuerst verarbeitet wird. In diesem Fall funktioniert die obige Lösung nicht . . Da der Consumer von Rabbitmq nur die ersten Daten in einer Warteschlange aus der Warteschlange, die ihn interessiert, „zufällig“ verarbeiten kann, wenn diese frei ist, kann er nicht steuern, welche Warteschlange er zuerst annimmt. Oder eine feinkörnigere Prioritätskontrolle. Oder es sind mehr als 10 Prioritäten in Ihrem System festgelegt. Es ist auch schwierig, Rabbitmq auf diese Weise zu verwenden.

Aber wenn Sie Redis als Warteschlange verwenden, können die oben genannten Anforderungen erfüllt werden.

Warum eine Nachrichtenwarteschlange benötigt wird

Die Einführung des Nachrichtenwarteschlangenmechanismus in das System ist eine sehr große Verbesserung des Systems. Beispielsweise muss in einem Websystem eine E-Mail-Benachrichtigung an das Postfach des Benutzers gesendet werden, nachdem ein Benutzer einen bestimmten Vorgang ausgeführt hat. Sie können die synchrone Methode verwenden, um den Benutzer auf das Senden der E-Mail warten zu lassen, bevor er dem Benutzer eine Rückmeldung gibt. Dies kann jedoch dazu führen, dass der Benutzer aufgrund der Netzwerkunsicherheit lange wartet und die Benutzererfahrung beeinträchtigt .

In einigen Szenarien ist es unmöglich, mithilfe der Synchronisierung auf den Abschluss zu warten, und diese Vorgänge erfordern viel Zeit im Hintergrund. In einem extremen Beispiel dauert es beispielsweise für eine Online-Kompilierungssystemaufgabe 30 Minuten, bis die Hintergrundkompilierung abgeschlossen ist. Das Design dieses Szenarios macht es unmöglich, synchron zu warten und dann Feedback zu geben. Es muss zuerst eine Rückmeldung an den Benutzer geben und dann die asynchrone Verarbeitung abgeschlossen sein, und dann warten, bis die Verarbeitung abgeschlossen ist, bevor eine Rückmeldung an den Benutzer erfolgt Situation.

Darüber hinaus ist die Situation, in der die Nachrichtenwarteschlange anwendbar ist, Situationen, in denen die Systemverarbeitungskapazität begrenzt ist. Der Warteschlangenmechanismus wird zunächst zum vorübergehenden Speichern der Aufgaben verwendet, und das System verarbeitet dann abwechselnd die in der Warteschlange befindlichen Aufgaben eins nach dem anderen. Auf diese Weise können hochgradig gleichzeitige Aufgaben auch bei unzureichendem Systemdurchsatz stabil verarbeitet werden.

Nachrichtenwarteschlange kann als Warteschlangenmechanismus verwendet werden. Solange das System den Warteschlangenmechanismus verwenden muss, kann die Nachrichtenwarteschlange verwendet werden.

Implementierung der Redis-Nachrichtenwarteschlangenpriorität

Erläuterung einiger grundlegender Redis-Grundkenntnisse

redis> blpop tasklist 0
"im task 01"

In diesem Beispiel wird der Befehl blpop verwendet, um die ersten Daten blockierend aus der Tasklistenliste abzurufen, und der letzte Parameter ist die Wartezeit für das Warten. Wenn der Wert auf 0 gesetzt ist, bedeutet dies, dass auf unbestimmte Zeit gewartet wird. Darüber hinaus können die in Redis gespeicherten Daten nur vom Typ string sein, sodass bei der Aufgabenübertragung nur string übergeben werden kann. Wir müssen lediglich die verantwortlichen Daten einfach in einen String im JSON-Format serialisieren und ihn dann auf der Verbraucherseite konvertieren.

Hier verwendet unsere Beispielsprache Python und die mit Redis verknüpfte Bibliothek verwendet Redis-Py. Wenn Sie über einige Programmierkenntnisse verfügen, sollte es kein Problem sein, sie auf Ihre Lieblingssprache umzustellen.

1. Einfache FIFO-Warteschlange

import redis, time
def handle(task):
    print task
    time.sleep(4)
 
def main():
    pool = redis.ConnectionPool(host='localhost', port=6379, db=0)
    r = redis.Redis(connection_pool=pool)
    while 1:
        result = r.brpop('tasklist', 0)
        handle(result[1])
 
if name == "main":
    main()

Das obige Beispiel ist sogar der einfachste Verbraucher. Wir rufen kontinuierlich Daten aus der Redis-Warteschlange ab. Wenn sich keine Daten in der Warteschlange befinden, werden sie dort ohne Zeitüberschreitung blockiert. Wenn Daten vorhanden sind, werden sie herausgenommen und ausgeführt.

Im Allgemeinen handelt es sich um eine komplexe Zeichenfolge. Möglicherweise müssen wir sie formatieren und dann an die Verarbeitungsfunktion übergeben. Der Einfachheit halber handelt es sich bei unserem Beispiel jedoch um eine gewöhnliche Zeichenfolge. Darüber hinaus führt die Verarbeitungsfunktion im Beispiel keine Verarbeitung durch und wird nur zum Ruhen verwendet, um zeitaufwändige Vorgänge zu simulieren.

Wir öffnen einen weiteren Redis-Client, um den Produzenten zu simulieren, der integrierte Client reicht aus. Fügen Sie mehr Daten in die Aufgabenlistenwarteschlange ein.

redis> lpush tasklist 'im task 01'
redis> lpush tasklist 'im task 02'
redis> lpush tasklist 'im task 03'
redis> lpush tasklist 'im task 04'
redis> lpush tasklist 'im task 05'

Dann sehen Sie auf der Verbraucherseite, wie diese simulierten Aufgaben nacheinander ausgeführt werden.

2. Einfache Prioritätswarteschlange

Gehen Sie von einer einfachen Anforderung aus, bei der nur Aufgaben mit hoher Priorität zuerst verarbeitet werden müssen und nicht Aufgaben mit niedriger Priorität. Die Reihenfolge anderer Aufgaben spielt keine Rolle. In diesem Fall müssen wir sie nur an den Anfang der Warteschlange schieben, wenn wir auf eine Aufgabe mit hoher Priorität stoßen, anstatt sie nach hinten zu schieben.

Da unsere Warteschlange eine Redis-Liste verwendet, ist die Implementierung einfach. Verwenden Sie rpush, wenn Sie auf eine niedrige Priorität stoßen. Dann werden Sie sehen, dass die hohe Priorität immer vor der niedrigen Priorität ausgeführt wird. Der Nachteil dieser Lösung besteht jedoch darin, dass die Ausführungsreihenfolge von Aufgaben mit hoher Priorität in der Reihenfolge „First in, last out“ erfolgt.

redis> lpush tasklist 'im task 01'
redis> lpush tasklist 'im task 02'
redis> rpush tasklist 'im high task 01'
redis> rpush tasklist 'im high task 01'
redis> lpush tasklist 'im task 03'
redis> rpush tasklist 'im high task 03'

3. Eine vollständigere Warteschlange

In Beispiel 2 werden Aufgaben mit hoher Priorität einfach an den Anfang der Warteschlange gestellt und Aufgaben mit niedriger Priorität am Ende. Dies garantiert nicht die Reihenfolge zwischen Aufgaben mit hoher Priorität.

Angenommen, wenn alle Aufgaben eine hohe Priorität haben, wird ihre Ausführungsreihenfolge umgekehrt. Dies verstößt offensichtlich gegen das FIFO-Prinzip der Warteschlange.

Allerdings kann unsere Warteschlange mit einer kleinen Verbesserung verbessert werden.

Ähnlich wie bei der Verwendung von Rabbitmq richten wir zwei Warteschlangen ein, eine Warteschlange mit hoher Priorität und eine Warteschlange mit niedriger Priorität. Aufgaben mit hoher Priorität werden in die Warteschlange mit hoher Priorität gestellt, Aufgaben mit niedriger Priorität werden in die Warteschlange mit niedriger Priorität gestellt. Der Unterschied zwischen Redis und Rabbitmq besteht darin, dass es den Warteschlangenkonsumenten auffordern kann, zuerst zu lesen, aus welcher Warteschlange.

Der obige Code ruft blockierend Daten aus den beiden Warteschlangen „high_task_queue“ und „low_task_queue“ ab, wenn die erste nicht aus der zweiten Warteschlange abgerufen wird.

def main():
    pool = redis.ConnectionPool(host='localhost', port=6379, db=0)
    r = redis.Redis(connection_pool=pool)
    while 1:
        result = r.brpop(['high_task_queue', 'low_task_queue'], 0)
        handle(result[1])

Sie müssen also nur solche Verbesserungen am Warteschlangenkonsumenten vornehmen, um das Ziel zu erreichen.

Durch den obigen Test können wir sehen, dass die hohe Priorität zuerst ausgeführt wird und das FIFO-Prinzip auch zwischen hohen Prioritäten gewährleistet ist.

redis> lpush low_task_queue low001
redis> lpush low_task_queue low002
redis> lpush low_task_queue low003
redis> lpush low_task_queue low004
redis> lpush high_task_queue low001
redis> lpush high_task_queue low002
redis> lpush high_task_queue low003
redis> lpush high_task_queue low004

Mit dieser Lösung können wir Prioritätswarteschlangen auf verschiedenen Ebenen unterstützen, z. B. auf drei Ebenen, hoch, mittel, niedrig oder mehr.

4. Situationen mit vielen Prioritätsstufen

Angenommen, es gibt eine solche Anforderung und die Priorität ist nicht einfach eine feste Stufe von hoch, mittel, niedrig oder 0-10. Aber es gibt so viele Ebenen wie 0-99999. Dann ist unsere dritte Option nicht geeignet.

Obwohl Redis einen sortierbaren

Datentyp

wie z. B. einen sortierten Satz hat, ist es schade, dass es keine blockierende Version der Schnittstelle hat. Daher können wir den Listentyp nur verwenden, um den Zweck durch andere Methoden zu erreichen.

Eine einfache Möglichkeit besteht darin, nur eine Warteschlange einzurichten und sicherzustellen, dass diese nach Priorität sortiert ist. Verwenden Sie dann die Methode Binäre Suche

, um den geeigneten Speicherort für eine Aufgabe zu finden, und fügen Sie ihn über den Befehl lset am entsprechenden Speicherort ein.

Zum Beispiel enthält die Warteschlange Aufgaben mit der Schreibpriorität [1, 3, 6, 8, 9, 14]. Wenn eine Aufgabe mit der Priorität 7 eintrifft, verwenden wir unseren eigenen binären Algorithmus, um die Aufgaben nacheinander zu schreiben Erstens: Nehmen Sie die Daten aus der Warteschlange, vergleichen Sie sie mit den Zieldaten, berechnen Sie die entsprechende Position und fügen Sie sie dann an der angegebenen Stelle ein.

Da die binäre Suche relativ schnell ist und sich Redis selbst auch im Speicher befindet, kann die Geschwindigkeit theoretisch garantiert werden. Aber wenn die Datenmenge wirklich groß ist, können wir sie auch in gewisser Weise optimieren.

Erinnern Sie sich an unsere dritte Option: Durch die Kombination der dritten Option wird der Overhead erheblich reduziert. Beispielsweise liegen bei Warteschlangen mit einem Datenvolumen von 100.000 auch deren Prioritäten zufällig im Bereich von 0-100.000. Wir können 10 oder 100 verschiedene Warteschlangen einrichten. Prioritätsaufgaben von 0 bis 10.000 werden in Warteschlange 1 platziert, und Aufgaben von 10.000 bis 20.000 werden in Warteschlange 2 platziert. Auf diese Weise werden nach der Aufteilung einer Warteschlange in verschiedene Ebenen die Daten einer einzelnen Warteschlange erheblich reduziert, sodass die Effizienz des binären Suchabgleichs höher ist. Die von den Daten belegten Ressourcen bleiben jedoch grundsätzlich unverändert. Hunderttausend Daten sollten die gleiche Speichermenge belegen. Es gibt nur mehr Warteschlangen im System.

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung der Implementierung eines Codebeispiels für die Redis-Warteschlangenpriorität. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!