Database Reference
In-Depth Information
Publisher
Nachricht 1
Nachricht 1
Subscriber A
Subscriber B
Abbildung 37: Ein Publisher sendet eine Nachricht an alle Subscriber
Das ist wesentlich effizienter, als immer nur einen einzelnen Befehl zu senden
und sollte überall da genutzt werden, wo es einen Sinn ergibt - insbesondere
bei Transaktionen. Achten Sie nur darauf, jeden Befehl mit
\r\n
abzuschlie-
ßen, weil das die vom Server erwarteten Trennzeichen sind.
Publish/Subscribe
Gestern konnten wir mit Hilfe einer Liste eine rudimentäre blockierende
Queue aufbauen. Die in die Queue geschriebenen Daten konnten durch einen
blockierenden Pop-Befehl gelesen werden. Mit Hilfe dieser Queue haben wir
ein sehr einfaches Publish/Subscribe-Modell aufgebaut. Eine beliebige Zahl
von Nachrichten konnte in die Queue geschoben werden und ein einzel-
ner Queue-Reader hat sie verarbeitet, sobald sie verfügbar waren. Das ist
leistungsfähig, aber etwas beschränkt. In vielen Fällen wünscht man sich
das umgekehrte Verhalten, d. h., mehrere „Abonnenten“ (Subscriber) wollen
die Meldungen eines einzelnen „Herausgebers“ (Publisher) lesen (siehe Abbil-
dung 37,
Ein Publisher sendet eine Nachricht an alle Subscriber
). Redis stellt
einige spezialisierte Publish/Subscribe-Befehle zur Verfügung.
Wir wollen den Kommentar-Mechanismus, den wir gestern mit blockieren-
den Listen aufgebaut haben, verbessern, indem wir es den Benutzern er-
lauben, einen Kommentar an mehrere Subscriber zu senden (und nicht nur
an einen). Wir beginnen mit einigen Subscribern, die sich mit einem Schlüs-
sel verbinden, der in Publisher/Subscriber-Nomenklatur als
Channel
(Kanal)
bezeichnet wird. Lassen Sie uns zwei weitere Clients starten und den com-
