Architektonisches F&E-Exemplar 02 — Referenz: Unternehmens-Integrationsschicht
Ausfallsichere Ereigniswarteschlange: dauerhafte Annahme, begrenzte Wiederholungen, idempotente Wirkung
Architektonisches F&E-Exemplar: Forschung und Entwicklung des Studios, in diesem Repository gebaut und gemessen. Es ist keine Kundenarbeit und beschreibt keinen Kunden. Jede Zahl auf dieser Seite ist gemessen oder berechnet, ihre Methode ist angegeben.
Entwurfsfrage
Wenn ein System in einer Kette stockt, dürfen Ereignisse weder verschwinden noch doppelt angewendet werden. Kann ein kleiner, abhängigkeitsfreier Zustandsautomat mindestens einmalige Zustellung mit höchstens einmaliger Wirkung liefern, einen Neustart und einen toten Kanal überstehen und das an deterministischen Ausfallszenarien zeigen?
Nachweisstufe B: eine Referenzimplementierung, verifiziert durch ausführbare Tests. Sie ist an keine Systeme eines Kunden angeschlossen; Volumen, Zugangsdaten und rechtlicher Kontext liegen außerhalb dessen, was dieses Exemplar behauptet.
I
Randbedingung und Toleranz
Drei Fehlerarten, jede mit einer schriftlichen Toleranz.
Verlust: Ein dem Erzeuger bestätigtes Ereignis muss einen Neustart und einen toten Kanal überstehen. Die Annahme ist ein dauerhaftes Schreiben, das vor der Bestätigung geschieht.
Wiederholung: Netze wiederholen. Die Zustellung ist mindestens einmalig, also wendet der Empfänger eine Ereignis-ID einmal an und verwirft die Wiederholung, wer auch immer sie erneut sendet.
Unbegrenztheit: Kein Ereignis darf endlos wiederholt oder endlos gehalten werden. Versuche, Alter und das Ergebnis an jeder Grenze (in die Dead Letters, aufbewahrt, nie verworfen) sind als Richtlinie festgeschrieben.
II
Architektur
Ein Zustandsautomat ohne Zeitgeber und ohne eigene Ein- und Ausgabe.
Der Aufrufer liefert Uhr, dauerhaften Speicher und Kanal, sodass derselbe Code in einer deterministischen Simulation, im Browser und, mit echtem Speicher und Kanal, in einem Projekt läuft.
Zustände: ausstehend, Wiederholung, geparkt, zugestellt, tot. Fehlgeschlagene Sendungen werden mit exponentiellem Backoff wiederholt. Nach einer Fehlerserie und einer fehlgeschlagenen Gesundheitsprüfung öffnet der Schutzschalter: Ereignisse werden im Speicher geparkt, eine günstige Sonde prüft den Kanal, bis er zurückkehrt, dann wird der Rückstau der Reihe nach abgearbeitet.
Isolierung giftiger Ereignisse: Ein fehlschlagendes Ereignis auf einem gesunden Kanal ist ein schlechtes Ereignis, kein toter Kanal. Es wird innerhalb seines Budgets wiederholt, dann in die Dead Letters gelegt, und der Schutzschalter bleibt geschlossen; ein schlechtes Ereignis hält die Warteschlange hinter sich also nicht länger auf als dieses Budget.
III
Verifikation
Deterministische Szenarien und eine feste Menge von Invarianten.
Zu den Szenarien gehören ein zwanzig Sekunden ausgefallener Kanal, ein flackernder Kanal, bei 30 % der Sendungen verlorene Bestätigungen, ein giftiges Ereignis, ein hartnäckiges Ereignis, Neustarts während eines Ausfalls, ein Erzeuger, der doppelt sendet, und alles zugleich. Jedes nutzt eine virtuelle Uhr und einen Zufallsgenerator mit festem Startwert: keine Zeitgeber, kein Netz.
In jedem Szenario stellen die Vertragstests sicher: Kein angenommenes Ereignis geht verloren, keines wird doppelt angewendet, die Annahmereihenfolge bleibt erhalten und kein Ereignis wird öfter gesendet, als die Richtlinie erlaubt.
Die Ergebnistabelle in der Dokumentation wird aus dem Code erzeugt und von einem Test mit ihm verglichen; der Nachweis ist also, was der Code heute tut.
Wo die Stufen gelten: Diese Warteschlange ist Nachweisstufe B (eine durch Tests verifizierte Referenz). Der signierte Webhook mit idempotenter Zustellung, den diese Seite in Produktion betreibt, ist Stufe A.
IV
Gemessenes Ergebnis und Grenzen
Berechnet aus dem Code, den die Tests ausführen.
Gemessen
Diese Zahlen werden beim Zeichnen der Seite berechnet, indem die Szenarien der Vertragstests ausgeführt werden. Sie sind deterministisch: bei jeder Anfrage gleich.
- Ausgeführte Szenarien
- 9
- 9 von 9 hielten jede Invariante
- Angenommene Ereignisse
- 370
- über alle Szenarien
- Verlorene Ereignisse
- 0
- jedes angenommene Ereignis angewendet, in den Dead Letters oder noch in der Warteschlange
- Doppelt angewendete Ereignisse
- 0
- 56 Wiederholungen wurden verworfen
Berechnet aus lib/arch/scenarios.ts mit dem Simulator, den die Vertragstests ausführen, beim Zeichnen dieser Seite. 5 Ereignisse wurden in die Dead Letters gelegt (aufbewahrt, nie verworfen): giftige oder hartnäckige Ereignisse, entwurfsgemäß.
Zielkonflikte und Grenzen
Was dieses Muster kostet und wo es den Kunden braucht.
Mindestens einmal heißt Wiederholungen
Wiederholungen entstehen entwurfsgemäß, also muss der Empfänger damit umgehen und IDs länger behalten als die längste Zeit, in der die Warteschlange weiter versuchen kann.
Reihenfolge kostet Verfügbarkeit
Bei strenger Reihenfolge hält ein fehlschlagendes Ereignis die dahinter auf, bis es gelingt oder in die Dead Letters geht. Für unabhängige Ereignisse abschalten.
Der Speicher ist eine Abhängigkeit
Die Dauerhaftigkeit ist nur so stark wie der Speicher, den die Warteschlange erhält. Seine Wahl (eine Datenbank, eine verwaltete Warteschlange) und seine eigenen Garantien gehören zum Projekt.
Gemessen auf
- TypeScript · no dependencies
- Virtual clock · seeded generator
- Node · browser