Bestell-Pipelines
Bestellungen fließen an Abrechnung, Versand und Analytics, die jeweils denselben Stream in ihrem eigenen Tempo lesen.
KerndatenHintergrundaufgaben
Event-Streaming
Event-Streams, an die nur angehängt wird, mit Consumer Groups, Bestätigungen und automatischer Wiederherstellung von Nachrichten, die ein abgestürzter Konsument zurückgelassen hat.
- Append-only-Log
- Dauerhaft
- Consumer Groups pro Stream
- N
- verlorene Nachrichten bei Absturz
- 0
Schritt 1 von 5
Ein Ereignis veröffentlichen
Der Bestelldienst hängt ein Ereignis an und bekommt dessen ID zurück.
Beispielsitzungplaying
# Ein Ereignis veröffentlichen
hotkv> XADD orders * type created order 1182 total 49.00
"1790985600123-0"
Ein animierter Durchlauf mit echten HotKV-Befehlen und Beispielantworten. Klicken Sie auf einen Schritt, um direkt dorthin zu springen. Befehle und Antworten bleiben auf Englisch, genau so, wie Sie sie in HotKV eingeben und sehen.
Das Problem
Dienste, die auf Ereignisse reagieren, brauchen mehr als eine Queue. Mehrere unabhängige Konsumenten wollen dieselben Ereignisse, jede Consumer Group muss die Arbeit auf ihre Instanzen verteilen, und wenn eine Instanz mit Nachrichten in der Hand ausfällt, muss jemand das bemerken und sie übernehmen.
So löst HotKV es
Ein Stream ist ein Log, an das nur angehängt wird. Jede Consumer Group liest ihn unabhängig, stellt jede Nachricht einem Mitglied der Gruppe zu und hält sie offen, bis das Mitglied sie bestätigt. XAUTOCLAIM übergibt Nachrichten, die zu lange offen waren, an einen gesunden Konsumenten.
Schritt für Schritt
Was passiert, Befehl für Befehl
- 01
Ein Ereignis veröffentlichen
Der Bestelldienst hängt ein Ereignis an und bekommt dessen ID zurück.
XADD orders * type created order 1182 total 49.00 - 02
Zwei Gruppen, ein Stream
Abrechnung und Versand haben jeweils eine eigene Gruppe, und jede erhält das Ereignis.
XGROUP CREATE orders billing 0 MKSTREAM - 03
Konsumieren
Eine Abrechnungsinstanz liest neue Nachrichten für ihre Gruppe und blockiert, bis etwas eintrifft.
XREADGROUP GROUP billing billing-1 COUNT 10 BLOCK 5000 STREAMS orders > - 04
Bestätigen
Sobald die Rechnung erstellt ist, bestätigt die Abrechnung, und die Nachricht verlässt ihre Liste offener Einträge.
XACK orders billing 1790985600123-0 - 05
Nach einem Absturz wiederherstellen
Eine Versandinstanz ist mit Nachrichten in der Hand ausgefallen. Nach 60 Sekunden Leerlauf übernimmt sie eine gesunde Instanz.
XAUTOCLAIM orders shipping shipping-2 60000 0-0 COUNT 25
Wo es passt
Szenarien aus der Praxis
Audit- und Aktivitäts-Feeds
Benutzeraktionen werden an einen Stream angehängt und von jedem Dienst wiedergegeben, der den Verlauf braucht.
IoT-Erfassung
Gerätenachrichten werden in Streams gepuffert und von einer Gruppe von Workern verarbeitet, die mit der Last skaliert.
Integriert
Was Sie bekommen
Append-only-Log
Einträge erhalten zeitlich geordnete IDs und lassen sich nach Länge oder Alter kürzen.
XADDXTRIMConsumer Groups
Jede Gruppe erhält jede Nachricht und verteilt die Arbeit auf ihre Mitglieder.
XGROUPXREADGROUPBestätigungen
Nachrichten bleiben offen, bis sie bestätigt sind.
XACKXPENDINGAutomatische Wiederherstellung
Zu lange untätige Nachrichten werden von einem anderen Konsumenten übernommen.
XAUTOCLAIMXCLAIMHäufige Fragen
Kann ich alte Ereignisse erneut abspielen?
Ja. XRANGE liest jeden Teil des Streams nach ID, und eine neue Consumer Group kann am Anfang beginnen.
Wie verhindere ich, dass ein Stream endlos wächst?
Kürzen Sie ihn mit XTRIM oder mit der Option MAXLEN oder MINID von XADD.
Kann XADD doppelte Ereignisse vermeiden?
XADD unterstützt idempotente Produzenten-IDs (IDMP), sodass ein wiederholtes Veröffentlichen keinen zweiten Eintrag erzeugt. Siehe die XADD-Referenz.
Verwandte Anwendungsfälle
Probieren Sie es mit Ihrer eigenen Workload
HotKV spricht das Redis-Protokoll, sodass Sie einen bestehenden Client darauf richten und genau diese Befehle ausführen können.