Glossar
Idempotenz
Auch: idempotent
Eine Verarbeitung ist idempotent, wenn dieselbe Anfrage mehrfach ausgeführt dasselbe Ergebnis hat wie einmal ausgeführt.
In verteilten Systemen ist die Wiederholung der Normalfall: Ein Aufruf läuft in eine Zeitüberschreitung, der Aufrufer weiß nicht, ob er angekommen ist, und versucht es erneut. Ohne Idempotenz wird daraus eine zweite Zahlung oder eine doppelte Bestellung.
Umgesetzt wird sie meist über einen mitgelieferten Schlüssel je Vorgang, den der Empfänger speichert. Kommt derselbe Schlüssel noch einmal, liefert er das gespeicherte Ergebnis, statt erneut zu verarbeiten.
Der Grund, warum es kein Herumkommen gibt, ist eine Eigenschaft des Netzes: Eine Zeitüberschreitung sagt nichts darüber aus, ob die Gegenseite die Anfrage verarbeitet hat. Sie kann verlorengegangen sein, sie kann verarbeitet und die Antwort verlorengegangen sein, oder sie kann gerade noch laufen. Alle drei Fälle sehen für den Aufrufer identisch aus, und deshalb muss die Wiederholung sicher sein statt vermieden werden.
Dieselbe Situation entsteht bei Nachrichtenverarbeitung. Warteschlangendienste garantieren üblicherweise mindestens eine Zustellung, nicht genau eine. Eine Nachricht, deren Bestätigung verloren geht oder deren Verarbeitung die Frist überschreitet, wird erneut zugestellt. Ein Konsument ohne Idempotenz erzeugt dann Doppelbuchungen, und zwar nicht bei Fehlern, sondern im Normalbetrieb unter Last.
Der Schlüssel muss vom Aufrufer stammen und den fachlichen Vorgang bezeichnen, nicht den einzelnen Versuch. Brauchbar sind eine Bestell- oder Vorgangsnummer aus dem Quellsystem, oder eine beim ersten Versuch erzeugte Kennung, die über alle Wiederholungen hinweg dieselbe bleibt. Ein pro Versuch neu erzeugter Zufallswert sieht nach Idempotenz aus und schützt vor nichts.
Die verbreitetste Fehlimplementierung ist die Prüfung vor der Verarbeitung ohne Sperre: erst nachsehen, ob der Schlüssel schon existiert, dann verarbeiten, dann speichern. Zwei gleichzeitige Wiederholungen laufen beide durch die Prüfung, bevor einer speichert. Richtig ist, den Schlüssel mit einer eindeutigen Bedingung in derselben Transaktion einzufügen wie die fachliche Änderung; der zweite Versuch scheitert dann an der Bedingung statt an einer Abfrage.
Zum vollständigen Bild gehört das gespeicherte Ergebnis. Wenn eine Wiederholung nur „schon verarbeitet" meldet, ohne die ursprüngliche Antwort mitzuliefern, ist der Aufrufer genauso schlau wie vorher. Idempotenz heißt, dieselbe Antwort noch einmal zu geben, nicht die zweite Anfrage abzuweisen.
Woran Sie es erkennen
- Aufrufe können durch Zeitüberschreitungen wiederholt werden.
- Es geht um Zahlungen, Bestellungen oder Versand.
- Doppelte Datensätze tauchen sporadisch auf, meist unter Last.
- Ein Warteschlangendienst garantiert mindestens eine Zustellung.
- Ein fremdes System sendet Rückmeldungen erneut, wenn die Bestätigung ausbleibt.
Nicht zu verwechseln mit
- Exactly-once-Zustellung
- Ein Versprechen des Transportwegs, das es praktisch nicht gibt. Was es gibt, ist mindestens eine Zustellung plus idempotente Verarbeitung, und das ergibt zusammen die gewünschte Wirkung.
- Deduplizierung
- Nachträgliches Aussortieren von Doubletten, oft über einen Zeitraum. Idempotenz verhindert die zweite Wirkung, statt sie später zu bereinigen.
- Transaktion
- Sorgt dafür, dass eine Verarbeitung ganz oder gar nicht passiert. Sagt nichts darüber, was bei einer zweiten identischen Anfrage geschieht.
Wann es trägt
- Bei allen Vorgängen mit Geld-, Bestell- oder Versandwirkung.
- Bei Konsumenten von Warteschlangen mit Zustellung mindestens einmal.
- Überall dort, wo Aufrufer bei Zeitüberschreitung automatisch wiederholen.
- Bei Rückmeldungen fremder Systeme, die bei ausbleibender Bestätigung erneut senden.
Wann nicht
- Bei reinen Leseabfragen: die sind es von Natur aus.
- Bei Vorgängen, deren Wiederholung fachlich gewollt ist, etwa dem Anlegen mehrerer gleicher Positionen.
Wie man rangeht
- Fachlichen Schlüssel bestimmenWas genau ist ein Vorgang: eine Bestellung, eine Zahlung, ein Versand. Der Schlüssel bezeichnet ihn, nicht den Übertragungsversuch.
- Schlüssel vom Aufrufer verlangenAls Feld oder Kopfzeile, verpflichtend. Wird er serverseitig erzeugt, kennt die Wiederholung ihn nicht.
- Eindeutigkeit in der Datenbank erzwingenEin eindeutiger Index auf den Schlüssel, eingefügt in derselben Transaktion wie die fachliche Änderung. Eine vorgelagerte Abfrage schützt nicht gegen Gleichzeitigkeit.
- Ergebnis mitspeichernAntwortstatus und Nutzdaten. Die Wiederholung bekommt dieselbe Antwort, keine Fehlermeldung.
- Aufbewahrungsdauer festlegenSo lange, wie Wiederholungen realistisch sind, meist 24 Stunden bis sieben Tage, mit automatischem Aufräumen.
- Wiederholungen im Test erzwingenDieselbe Anfrage doppelt und parallel schicken. Wenn kein Test das tut, wird der Fehler in Produktion unter Last gefunden.
Häufig gefragt
Wie lange muss ich Idempotenzschlüssel aufbewahren?
So lange, wie Wiederholungen realistisch sind, meist 24 Stunden bis sieben Tage. Kürzer öffnet die Lücke wieder, deutlich länger kostet nur Speicher. Wichtig ist, dass der Schlüssel den fachlichen Vorgang meint, nicht den einzelnen Versuch.
Reicht es, vorher zu prüfen, ob der Vorgang schon existiert?
Nein, das ist die häufigste Fehlimplementierung. Zwei gleichzeitige Wiederholungen laufen beide durch die Prüfung, bevor eine von beiden schreibt. Die Eindeutigkeit muss die Datenbank durchsetzen, über einen eindeutigen Index, der in derselben Transaktion gesetzt wird wie die fachliche Änderung.
Was gibt man bei einer Wiederholung zurück?
Dieselbe Antwort wie beim ersten Mal, aus dem gespeicherten Ergebnis. Eine Fehlermeldung wie „bereits verarbeitet" zwingt den Aufrufer, einen Sonderfall zu behandeln, und genau das führt zu neuen Fehlern. Kommt derselbe Schlüssel mit abweichenden Nutzdaten, ist das dagegen ein echter Konflikt und gehört als solcher gemeldet.
Gilt das auch für Warteschlangen?
Besonders dort. Übliche Dienste sichern mindestens eine Zustellung zu, nicht genau eine. Eine Nachricht, deren Verarbeitung die Sichtbarkeitsfrist überschreitet, wird erneut zugestellt, während die erste noch läuft. Ohne idempotente Konsumenten entstehen Doppelbuchungen im Normalbetrieb, nicht nur im Fehlerfall.