Idempotenz Erklärt: Ein Leitfaden für Zuverlässiges Systemdesign

Abstraktes Konzept

Idempotenz ist ein Konzept in der Mathematik und Informatik, das häufig in der abstrakten Algebra vorkommt.

In der Programmierung ist eine idempotente Operation dadurch gekennzeichnet, dass die mehrmalige Ausführung die gleiche Wirkung hat wie die einmalige Ausführung. Eine idempotente Funktion oder Methode ist eine, die wiederholt mit den gleichen Parametern ausgeführt werden kann, während sie das gleiche Ergebnis liefert. Diese Funktionen verändern den Systemzustand nicht, und wiederholte Ausführungen verursachen keine unbeabsichtigten Änderungen. Zum Beispiel sind Funktionen wie getUsername() und setTrue() idempotent.

Einfach ausgedrückt: Egal wie oft eine Operation ausgeführt wird, ihre Wirkung oder ihr Rückgabeergebnis bleibt gleich.

Beispiele:

• Wenn ein Frontend-Formular mehrmals übermittelt wird, sollte das Backend nur ein Ergebnis generieren.
• Wenn eine Zahlungsanforderung initiiert wird, sollte das Konto des Benutzers nur einmal belastet werden. Selbst bei Netzwerk-Wiederholungsversuchen oder Systemfehlern, die mehrere Einreichungen verursachen, sollte nur eine Abbuchung erfolgen.
• Wenn eine Nachricht gesendet wird, sollte sie nur einmal gesendet werden. Wenn dieselbe SMS mehrmals gesendet wird, kann dies Benutzer frustrieren.
• Bei der Erstellung einer Geschäftsbestellung sollte jede Anfrage zur Erstellung von nur einer Bestellung führen, um doppelte Datensätze zu vermeiden.

Es gibt viele solcher Szenarien, in denen Idempotenz unerlässlich ist.

Techniken zur Implementierung von Idempotenz

Lese- (Abfrage-) Operationen

Eine Abfrageoperation, ob einmal oder mehrmals ausgeführt, liefert das gleiche Ergebnis, solange die zugrunde liegenden Daten unverändert bleiben. Dies macht SELECT-Abfragen natürlich idempotent.

Löschoperationen

Löschoperationen sind ebenfalls idempotent. Unabhängig davon, ob eine Löschung einmal oder mehrmals ausgeführt wird, werden die Daten entfernt. (Der Rückgabewert kann jedoch abweichen: Wenn die Daten fehlen, gibt die Löschung 0 zurück; wenn mehrere Datensätze vorhanden sind, werden mehrere Zeilen beeinflusst.)

Eindeutige Indizierung zur Verhinderung von Dirty Data

Wie können wir beispielsweise in einem Finanzsystem, in dem jeder Benutzer nur ein Finanzkonto haben sollte, verhindern, dass mehrere Konten für einen einzelnen Benutzer erstellt werden?

Durch Hinzufügen eines eindeutigen Indexes für das Benutzer-ID-Feld in der Finanzkontentabelle kann nur eine Anfrage erfolgreich sein, wenn versucht wird, ein Konto zu erstellen. Nachfolgende Anfragen werfen einen eindeutigen Constraint-Verletzungsfehler aus, z. B. org.springframework.dao.DuplicateKeyException. Das System kann dann einfach die Datenbank erneut abfragen, um zu bestätigen, ob die Daten bereits vorhanden sind, und das entsprechende Ergebnis zurückgeben.

Token-Mechanismus zur Verhinderung doppelter Formularübermittlungen

Anforderung: Die Daten auf einer Seite sollen nur einmal übermittelt werden.

Ursache: Doppelte Klicks, Netzwerk-Wiederholungsversuche oder erneute Einreichungen, die durch Nginx-Wiederholungsversuche ausgelöst werden, können dazu führen, dass dieselben Daten mehrmals verarbeitet werden.

Lösung:

• In einer Cluster-Umgebung: Verwenden Sie ein Token in Kombination mit Redis.
• In einer einzelnen JVM-Umgebung: Verwenden Sie ein Token in Kombination mit Redis oder ein in JVM-Speicher gespeichertes Token.

Prozess:

1. Fordern Sie vor der Datenübermittlung ein Token vom Dienst an, das mit einer Gültigkeitsdauer in Redis oder im JVM-Speicher gespeichert wird.
2. Bei der Übermittlung verifiziert das Backend das Token, löscht es und generiert ein neues Token für die nächste Anfrage.

Token-Eigenschaften:

• Muss vor der Übermittlung angefordert werden.
• Kann nur einmal verwendet werden.
• Kann als Ratenbegrenzungsmechanismus dienen.

Wichtig: Redis sollte eine Löschoperation verwenden, um das Token zu überprüfen. Wenn das Löschen erfolgreich ist, wird das Token als gültig betrachtet. Die Verwendung von SELECT + DELETE kann zu Nebenläufigkeitsproblemen führen und wird nicht empfohlen.

Pessimistische Sperre

Erwerben einer Sperre beim Abrufen von Daten:

SELECT * FROM table_xxx WHERE id='xxx' FOR UPDATE;

Hinweis: Das Feld id muss ein Primärschlüssel oder ein eindeutiger Index sein; Andernfalls sperrt die Abfrage die gesamte Tabelle, was zu Leistungsproblemen führen kann.

Pessimistische Sperren werden im Allgemeinen mit Transaktionen verwendet, und die Daten bleiben für die Dauer der Transaktion gesperrt. Je länger die Sperre gehalten wird, desto größer sind die potenziellen Auswirkungen auf die Leistung. Verwenden Sie sie daher basierend auf den spezifischen Anforderungen.

Optimistische Sperre

Die optimistische Sperre sperrt Daten nur zum Zeitpunkt einer Aktualisierung und vermeidet unnötige Sperren zu anderen Zeiten. Im Vergleich zur pessimistischen Sperre bietet sie eine höhere Effizienz.

Es gibt mehrere Möglichkeiten, die optimistische Sperre zu implementieren, z. B. mithilfe einer Versionsnummer oder bedingungsbasierter Einschränkungen:

1. Versionsnummer-Ansatz:

   UPDATE table_xxx SET name=#name#, version=version+1 WHERE version=#version#

2. Bedingungsbasierter Ansatz:

   UPDATE table_xxx SET avai_amount=avai_amount-#subAmount# WHERE avai_amount-#subAmount# >= 0

   • Die Bedingung avai_amount - subAmount >= 0 gewährleistet sichere Aktualisierungen, ohne dass eine Versionsnummer erforderlich ist.
   • Dies ist ideal für Bestandsmodelle, bei denen der Lagerbestand nach Bedarf ab- und zurückgebucht wird.
   • Es bietet eine bessere Leistung.

Bewährte Methoden:

• Verwenden Sie Primärschlüssel oder eindeutige Indizes in UPDATE-Abfragen, um Tabellensperren zu vermeiden. Die obigen Abfragen sollten wie folgt geändert werden:

  UPDATE table_xxx SET name=#name#, version=version+1 WHERE id=#id# AND version=#version#
  
  UPDATE table_xxx SET avai_amount=avai_amount-#subAmount# WHERE id=#id# AND avai_amount-#subAmount# >= 0

Verteilte Sperre

Beim Einfügen von Daten in einem verteilten System kann es schwierig sein, einen global eindeutigen Index zu erzwingen (z. B. aufgrund des Fehlens eines universellen eindeutigen Schlüssels über verteilte Knoten hinweg).

In solchen Fällen kann eine verteilte Sperre mit Redis oder Zookeeper implementiert werden, um die gleichzeitige Dateneingabe oder -aktualisierung zu verwalten. Das System erwirbt eine Sperre, führt dieOperation aus und gibt dann die Sperre frei. Dieser Ansatz hilft, gleichzeitige Schreibvorgänge zu verhindern, und ist eine gängige Lösung in verteilten Systemen.

SELECT + INSERT-Muster

Für Backend-Systeme mit geringer Parallelität oder geplanten Jobaufgaben kann Idempotenz sichergestellt werden, indem vor dem Fortfahren überprüft wird, ob die Operation bereits ausgeführt wurde.

1. Fragen Sie zuerst die Datenbank nach kritischen Daten ab, um festzustellen, ob die Operation bereits ausgeführt wurde.
2. Wenn sie noch nicht ausgeführt wurde, fahren Sie mit der Verarbeitung fort.

Hinweis: Vermeiden Sie die Verwendung dieses Ansatzes in Szenarien mit hoher Parallelität.

State-Machine-Idempotenz

In Geschäftsanwendungen, die Auftragsbearbeitung oder Aufgabenausführung beinhalten, müssen Zustandsübergänge sorgfältig verwaltet werden.

• Geschäftsdatensätze haben normalerweise ein Zustandsfeld, und Übergänge erfolgen basierend auf vordefinierten endlichen Zustandsautomaten.
• Wenn eine Anfrage versucht, von einem älteren Zustand in einen bereits aktualisierten Zustand überzugehen, sollte sie abgelehnt werden.
• Dies gewährleistet Idempotenz bei Zustandsübergängen.

Wichtige Überlegung: Für auftragsbasierte Workflows, bei denen sich Zustände im Laufe der Zeit entwickeln, ist ein solides Verständnis von Zustandsautomaten unerlässlich, um robuste Geschäftssysteme zu entwerfen.

Sicherstellung der Idempotenz in API-Aufrufen

Beispielsweise verlangt eine Bank, die eine Zahlungs-API bereitstellt, von Händlern, dass sie zwei Felder in ihre Anfrage aufnehmen:

• source: Der Ursprung der Anfrage.
• seq: Eine eindeutige Sequenznummer.

Durch Erzwingen eines eindeutigen Indexes für source + seq in der Datenbank können doppelte Zahlungen verhindert werden, wodurch sichergestellt wird, dass nur eine Anfrage in gleichzeitigen Szenarien verarbeitet wird.

Kernpunkte:

So unterstützen Sie Idempotenz in externen APIs:

1. Erfordern Sie zwei Schlüsselfelder: source und seq.
2. Erzwingen Sie eine eindeutige Einschränkung für diese Felder im System des Dienstanbieters.
3. Überprüfen Sie vor der Verarbeitung einer Anfrage, ob diese bereits bearbeitet wurde.
   • Wenn sie bereits verarbeitet wurde, geben Sie das vorhandene Ergebnis zurück.
   • Wenn sie noch nicht verarbeitet wurde, fahren Sie mit der Ausführung fort.

Bewährte Methode: Fragen Sie immer ab, ob eine Anfrage verarbeitet wurde, bevor Sie neue Datensätze einfügen. Das direkte Einfügen von Daten ohne Prüfung kann zu Fehlern führen, obwohl die Operation möglicherweise bereits erfolgreich war.

Abschließende Gedanken

Idempotenz ist ein grundlegendes Prinzip für gutes Softwaredesign. Sie ist eine wichtige Überlegung beim Entwurf von Systemen mit hoher Zuverlässigkeit, insbesondere in Branchen wie Zahlungsplattformen von Drittanbietern, Banken und Fintech, in denen Genauigkeit von größter Bedeutung ist. Probleme wie doppelte Abbuchungen oder mehrfache Auszahlungen können äußerst schwierig zu beheben sein und die Benutzererfahrung erheblich beeinträchtigen.

Durch die Implementierung von idempotenten Operationen können Entwickler robuste, fehlertolerante Systeme erstellen, die Konsistenz, Korrektheit und eine nahtlose Benutzererfahrung gewährleisten.

---

Wir sind Leapcell, Ihre erste Wahl für das Hosten von Backend-Projekten.

Leapcell ist die Next-Gen-Serverless-Plattform für Webhosting, asynchrone Aufgaben und Redis:

Multi-Language-Unterstützung

• Entwickeln Sie mit Node.js, Python, Go oder Rust.

Stellen Sie unbegrenzt Projekte kostenlos bereit

• zahlen Sie nur für die Nutzung - keine Anfragen, keine Gebühren.

Unschlagbare Kosteneffizienz

• Pay-as-you-go ohne Leerlaufgebühren.
• Beispiel: 25 US-Dollar unterstützen 6,94 Millionen Anfragen bei einer durchschnittlichen Antwortzeit von 60 ms.

Optimierte Entwicklererfahrung

• Intuitive Benutzeroberfläche für mühelose Einrichtung.
• Vollständig automatisierte CI/CD-Pipelines und GitOps-Integration.
• Echtzeitmetriken und -protokollierung für umsetzbare Erkenntnisse.

Mühelose Skalierbarkeit und hohe Leistung

• Auto-Scaling zur einfachen Bewältigung hoher Parallelität.
• Null Betriebsaufwand - konzentrieren Sie sich einfach auf den Aufbau.

Erfahren Sie mehr in der Dokumentation!

Folgen Sie uns auf X: @LeapcellHQ