So implementieren Sie eine Nachrichtenwarteschlange basierend auf Redis

Nachrichtenwarteschlange, Nachrichtenwarteschlange, wird häufig verwendet, um Ressourcenkonsistenzprobleme in gleichzeitigen Systemen zu lösen, die Spitzenverarbeitungsfähigkeiten zu verbessern und die Ordnungsmäßigkeit, Wiederherstellbarkeit und Zustellungseigenschaften von Nachrichten sicherzustellen , Entkopplung von Anwendungen oder Implementierung asynchroner Kommunikation usw. (Empfohlenes Lernen: Redis-Video-Tutorial)

Es gibt viele MQ-Anwendungen auf dem Markt (zum Beispiel: Kafka, RabbitMQ, Disque), und sie können auch basierend darauf implementiert werden Redis, was typischer ist. Zu den Lösungen gehören:

Listenbasierte Implementierung von LPUSH+BRPOP

PUB/SUB, Abonnement-/Veröffentlichungsmodus

Sorted-Set -basierte Implementierung

Implementierung basierend auf dem Stream-Typ

Bei der Verwendung von Nachrichtenwarteschlangen gibt es Produzenten und Konsumenten. Produzenten sind für die Generierung von Nachrichten verantwortlich, und Konsumenten sind für die Verarbeitung von Nachrichten verantwortlich.

Produktion bezieht sich auf das Einfügen von Nachrichten in die Nachrichtenwarteschlange.

Verbrauch bezieht sich auf das Lesen und Verarbeiten von Nachrichten. Nachdem eine Nachricht verbraucht wurde, sollte sie normalerweise aus der Nachrichtenwarteschlange gelöscht werden.

Implementierung von LPUSH+BRPOP basierend auf Liste

Der typische Befehl ist:

LPUSH，将消息队列
BRPOP，从队列中取出消息，阻塞模式

ist eine typische Lösung, die auf der FIFL-Warteschlange basiert. Unter diesen ist LPUSH das, was der Hersteller tut, und BRPOP ist das, was der Verbraucher tut.

Dieser Modus hat viele Vorteile:

Einfache Implementierung

Reids unterstützt persistente Nachrichten, was bedeutet, dass Nachrichten nicht verloren gehen und wiederholt angezeigt werden können (Hinweis: Nicht verbrauchend, nur Ansehen und Verwenden der LRANGE-Klassenanweisungen).

Die Reihenfolge kann mit dem Befehl LPUSH sichergestellt werden.

Mit RPUSH kann die Nachricht an den Anfang der Warteschlange gestellt werden, um den Zweck der Nachrichtenpriorisierung zu erreichen und Realisierung einfacher Nachrichten.

Gleichzeitig gibt es einige Nachteile:

Es ist mühsamer, eine Verbrauchsbestätigung (ACK) durchzuführen, das heißt, es gibt keine Garantie dafür, dass der Verbraucher sie erhält Unverarbeitete Ausfallzeiten nach dem Lesen. Dies führt zu einem unerwarteten Verlust von Nachrichten. Normalerweise müssen Sie selbst eine Pending-Liste pflegen, um sicherzustellen, dass die Nachricht verarbeitet und bestätigt wird.

Der Broadcast-Modus, wie der typische Pub/Discribe-Modus, ist nicht möglich.

Kann nicht wiederholt konsumiert werden, sobald es verbraucht ist, wird es gelöscht

Gruppenkonsum wird nicht unterstützt und muss auf der Ebene der Geschäftslogik selbst gelöst werden

PUB /SUB, Abonnement-/Veröffentlichungsmuster

SUBSCRIBE，用于订阅信道
PUBLISH，向信道发送消息
UNSUBSCRIBE，取消订阅

Produzenten und Verbraucher interagieren über denselben Kanal (Kanal). Ein Kanal ist eigentlich eine Warteschlange. In der Regel gibt es mehrere Verbraucher. Mehrere Verbraucher abonnieren denselben Kanal. Wenn ein Produzent eine Nachricht auf dem Kanal veröffentlicht, veröffentlicht der Kanal die Nachricht sofort einzeln an jeden Verbraucher. Es ist ersichtlich, dass der Kanal für Verbraucher ein divergierender Kanal ist und jeder Verbraucher die gleiche Nachricht erhalten kann. Typische Eins-zu-Viele-Beziehung.

Typische Vorteile sind:

Typischer Broadcast-Modus, eine Nachricht kann an mehrere Verbraucher veröffentlicht werden

Mehrkanalabonnement, Verbraucher können mehrere abonnieren Kanäle gleichzeitig, um mehrere Arten von Nachrichten zu empfangen

Nachrichten werden sofort gesendet und die Nachrichten müssen nicht darauf warten, dass Verbraucher sie lesen. Verbraucher erhalten automatisch vom Kanal veröffentlichte Nachrichten

Es gibt auch einige Nachteile:

Sobald die Nachricht veröffentlicht ist, kann sie nicht mehr empfangen werden. Mit anderen Worten, wenn der Client zum Zeitpunkt der Veröffentlichung nicht online ist, geht die Nachricht verloren und kann nicht abgerufen werden

Es gibt keine Garantie dafür, dass die von jedem Verbraucher empfangene Zeit konsistent ist

Wenn eine Nachricht erscheint auf dem Consumer-Client. Der Rückstand wird bis zu einem gewissen Grad zwangsweise getrennt, was zu einem unerwarteten Verlust von Nachrichten führt. Es tritt normalerweise auf, wenn die Produktion von Nachrichten viel schneller ist als die Verbrauchsgeschwindigkeit

Es ist ersichtlich, dass der Pub/Sub-Modus nicht für Nachrichtenspeicher- und Nachrichten-Backlog-Dienste geeignet ist, aber gut für die sofortige Verarbeitung von Broadcast geeignet ist Messaging- und Instant-Feedback-Dienste.

Implementierung basierend auf der geordneten Menge von SortedSet

ZADD KEY score member，压入集合
ZRANGEBYSCORE，依据score获取成员

Die Lösung der geordneten Menge wird häufiger verwendet, wenn Sie die Nachrichten-ID selbst bestimmen, indem Sie den Score des Gruppenmitglieds als verwenden Die Nachrichten-ID garantiert die Reihenfolge und kann auch die monotone Erhöhung der Nachrichten-ID sicherstellen. Normalerweise kann die Lösung Zeitstempel + Sequenznummer verwendet werden. Der monotone Anstieg der Nachrichten-ID ist gewährleistet, und eine geordnete Nachrichtenwarteschlange kann mithilfe der Sortierfunktion von SortedSet nach Score erstellt werden.

Im Vergleich zur oben genannten Lösung besteht der Vorteil darin, dass die Nachrichten-ID angepasst werden kann, was wichtiger ist, wenn die Nachrichten-ID aussagekräftig ist. Die Nachteile liegen ebenfalls auf der Hand. Es ist nicht zulässig, Nachrichten zu duplizieren (denken Sie, es handelt sich um eine Sammlung). Gleichzeitig führen Fehler bei der Bestimmung der Nachrichten-ID dazu, dass die Reihenfolge der Nachrichten falsch ist.

Wenn Sie also die Nachrichten-ID nicht anpassen müssen, scheint diese Lösung etwas nutzlos zu sein...

Implementierung basierend auf dem Stream-Typ

Dieser Stream-Typ ist Redis, um eine Nachrichtenwarteschlange zu implementieren. Unterstützt die automatische Generierung von Nachrichten-IDs, Gruppenverbrauch, ACK, Nachrichtenübertragung, Warteschlangenüberwachung und andere Kernfunktionen der Nachrichtenwarteschlange

Weitere technische Artikel zu Redis finden Sie im Redis-Erste-Schritte-Tutorial Kolumne zum Lernen!

Das obige ist der detaillierte Inhalt vonSo implementieren Sie eine Nachrichtenwarteschlange basierend auf Redis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!