Was ist Idempotenz?
In der Informatik ist Idempotenz eine Eigenschaft eines Vorgangs, bei dem die mehrfache Anwendung den gleichen Enderfolg hat wie die einmalige Anwendung. Wenn Sie dieselbe Anfrage fünfmal an einen Server senden, sorgt ein idempotentes System dafür, dass sich das Ergebnis auf dem Server nach dem ersten erfolgreichen Versuch nicht mehr ändert.
Neben dem gleichen Ergebnis ist ein wichtiges Merkmal idempotenter Vorgänge, dass sie bei zusätzlichen Aufrufen keine Nebenwirkungen haben. Dies ist eine Grundvoraussetzung für den Aufbau ausfallsicherer verteilter Systeme, bei denen zeitweilige Netzwerkausfälle oder Zeitüberschreitungen dazu führen können, dass ein Client dieselbe Nachricht mehrmals sendet.
Informationen zum Schreiben idempotenter Funktionen in Cloud Run
Analogie: Stellen Sie sich die Aufwärtstaste in einem Aufzug vor. Wenn Sie sie einmal drücken, wird der Aufzug in Ihr Stockwerk gerufen. Wenn Sie noch zehnmal drücken, während Sie warten, kommt trotzdem nur ein Aufzug. Wenn Sie mehrmals auf die Taste drücken, kommen nicht zehn Aufzüge gleichzeitig. Das Hinzufügen eines Artikels zu einem digitalen Einkaufswagen ist dagegen in der Regel nicht idempotent. Wenn Sie fünfmal auf den Button „In den Einkaufswagen“ klicken, landen wahrscheinlich fünf Artikel im Warenkorb.
Wichtigste Vorteile idempotenter Systeme
Zuverlässigkeit in unzuverlässigen Netzwerken
Sie können Anfragen nach einem Timeout oder Verbindungsabbruch sicher wiederholen, ohne Aktionen zu duplizieren (z. B. eine Kreditkarte doppelt zu belasten).
Vereinfachte Nutzerlogik
Nutzer müssen nicht aufwendig den Status verfolgen, um zu wissen, ob eine vorherige Anfrage erfolgreich war. Sie können einfach „wiederholen, bis es klappt“.
Infrastruktur-Resilienz
Verteilte Systeme können sich von Abstürzen erholen, indem sie Protokolle wiedergeben oder fehlende Nachrichten neu senden, ohne Daten zu beschädigen.
Idempotente und nicht idempotente HTTP-Methoden
Der REST-Standard definiert, wie sich verschiedene Arten von Webanfragen verhalten sollen. Einige HTTP-Methoden sind von Natur aus „sicher“ oder idempotent, d. h., die Spezifikation erwartet, dass sie sich auch bei Wiederholung vorhersagbar verhalten. Andere sind so konzipiert, dass sie neue Daten erstellen, und erfordern besondere Sorgfalt, um sie für Wiederholungen sicher zu machen.
Idempotente Methoden (GET, PUT, DELETE)
Gemäß RFC 9110 sind mehrere Standardmethoden von Natur aus idempotent. Durch das Wiederholen dieser Aktionen sollte sich der Zustand des Servers über die ursprüngliche Anfrage hinaus nicht ändern.
- GET: Diese Methode ruft Daten ab. Da sich auf dem Server nichts ändert, können Sie sie eine Million Mal aufrufen und die Ressource bleibt gleich.
- PUT: Mit dieser Methode wird eine Ressource vollständig ersetzt. Wenn Sie die E-Mail-Adresse eines Nutzers dreimal auf „user@example.com“ aktualisieren, ist der Endzustand immer noch „user@example.com“.
- DELETE: Damit wird eine Ressource entfernt. Wenn Sie „Bestellung #123“ löschen und dann versuchen, sie noch einmal zu löschen, bleibt sie gelöscht. Das Ergebnis (die Reihenfolge ist weg) bleibt gleich.
Nicht idempotente Methoden (POST, PATCH)
Einige Methoden sind nicht idempotent, weil ihre Hauptaufgabe darin besteht, Daten so zu ändern, dass etwas Neues entsteht oder ein Teil eines vorhandenen Datensatzes geändert wird.
- POST: Entwickler verwenden POST, um neue Ressourcen zu erstellen. Ohne Idempotenzlogik würde das zweimalige Senden derselben POST-Anfrage (z. B. „Zahlung senden“) in der Regel zu zwei separaten Datensätzen und zwei Belastungen für den Kunden führen.
- PATCH: Mit dieser Methode werden Teilaktualisierungen angewendet. Sie kann zwar idempotent gemacht werden, ist es aber oft nicht standardmäßig, da eine wiederholte relative Änderung (wie „5 zum Guthaben hinzufügen“) jedes Mal zu einem anderen Endwert führen würde.
Idempotente API implementieren
- Eindeutigen Schlüssel generieren: Der Client erstellt einen eindeutigen String (z. B. eine UUID) und fügt ihn in einen benutzerdefinierten HTTP-Header ein.
- Abfangen und validieren: Der Server prüft in einem schnellen Datenspeicher wie Memorystore, ob dieser Schlüssel kürzlich verarbeitet wurde.
- Zustand verwalten: Wenn der Schlüssel neu ist, verarbeiten Sie die Anfrage und speichern Sie das Ergebnis. Wenn es sich um ein Duplikat handelt, geben Sie das gespeicherte Ergebnis sofort zurück, ohne die Geschäftslogik erneut auszuführen.
Gängige Anwendungsfälle für Idempotenz
Idempotenz ist oft in den Systemen erforderlich, die wir entwickeln. In einigen Fällen wird das für uns erledigt. In anderen Fällen müssen wir als Entwickler aktiv werden, um dies zu ermöglichen.
Zahlungsabwicklung
Das bekannteste Beispiel ist das Problem der „doppelten Auszahlung“. Wenn der Browser eines Nutzers beim Bezahlen eines Fluges hängt, klickt er möglicherweise noch einmal auf „Bezahlen“. Eine Zahlungs-API, die einen Idempotenzschlüssel verwendet, sorgt dafür, dass der zweite Klick als Wiederholung erkannt wird. Das schützt das Bankkonto des Kunden und reduziert die Betriebskosten für die Bearbeitung von Rückerstattungen für doppelte Transaktionen.
- Maßnahmen durch Entwickler erforderlich: Sie müssen einen Idempotenzschlüssel (oft eine UUID) in Ihre API-Anfrage einfügen, damit der zweite Klick als Wiederholungsversuch erkannt wird und das Bankkonto des Kunden geschützt ist.
Infrastruktur als Code (IaC)
Tools wie Terraform und Ansible basieren auf Idempotenz. Wenn Sie ein Script ausführen, um einen 10 GB großen Speicher-Bucket zu erstellen, prüft das Tool den aktuellen Zustand Ihrer Cloud.
- Für Sie erledigt: Die Idempotenz wird vom IaC-Tool selbst verwaltet. Als Entwickler müssen Sie keine zusätzliche Logik schreiben, um doppelte Ressourcen zu vermeiden.
API-Entwicklung (REST)
Moderne Web-APIs implementieren oft den Idempotency-Key-Header (jetzt ein standardisierter IETF-Entwurf), damit Entwickler robustere Integrationen erstellen können.
- Entwickler müssen aktiv werden: Beim Erstellen des Backends müssen Sie die Logik implementieren, um diese Schlüssel abzufangen, nach vorherigen Versuchen zu suchen und die Antwort aus dem Cache zurückzugeben.
Datenbank-Upserts
Ein „Upsert“ (Update oder Insert) ist ein klassischer idempotenter Datenbankvorgang. Anstelle eines einfachen „Einfügen“ bedeutet „Upsert“: „Wenn dieser Datensatz vorhanden ist, aktualisiere ihn; wenn nicht, erstelle ihn.“
- Für Sie erledigt: Diese Logik wird nativ vom Datenbankmodul verarbeitet, sodass Datensätze immer in den richtigen Zustand überführt werden, unabhängig davon, wie oft das Script ausgeführt wird.
Zuverlässige Mikrodienste in Google Cloud entwickeln
Google Cloud bietet mehrere Tools, die Entwicklern die Implementierung dieser Muster erleichtern. Wenn Sie auf einer verwalteten Plattform aufbauen, müssen Sie weniger „Boilerplate“-Code schreiben, um Ihre Daten zu schützen.
- Cloud Run: Wenn Sie Cloud Run verwenden, um Ereignisse aus Pub/Sub zu verarbeiten, denken Sie daran, dass Pub/Sub Nachrichten standardmäßig mehr als einmal zustellen kann. Wenn Sie in Ihren Cloud Run-Diensten idempotenten Code schreiben, können Sie sicherstellen, dass Ihre KI-Agents oder Datenpipelines dasselbe Ereignis nicht zweimal verarbeiten.
- Hinweis zu Pub/Sub: Die Standardeinstellung ist die Push-basierte Zustellung, aber die genau einmalige Zustellung ist für Pull-basierte Abos verfügbar. Es ist hilfreich, diese beiden Typen zu kennen, um den richtigen Komplexitätsgrad für Ihren Dienst zu wählen.
Cloud SpannerZum Speichern Ihrer Idempotenzschlüssel benötigen Sie eine Datenbank, die entweder extrem schnell oder global konsistent ist.
Memorystore (Redis)eignet sich perfekt für das kurzfristige Caching von Schlüsseln (z. B. 24 Stunden), während Cloud Spanner die für Finanztransaktionen mit hohem Risiko erforderliche Verfügbarkeit von 99,999 % und starke Konsistenz bietet.
Bereit zum Erstellen?
Hier erfahren Sie, wie Sie resiliente, idempotente Dienste in Cloud Run bereitstellen.
Benötigen Sie Hilfe beim Einstieg?
Vertrieb kontaktierenMit einem zertifizierten Partner arbeiten
Partner findenMehr ansehen
Alle Produkte ansehen
