Mehrphasige Transaktionen: Implementierung fehlertoleranter Operationen in DBMS

Robuste Transaktionen aufbauen: Idempotente Operationen in der Praxis

Mehrphasige Transaktionen gewährleisten die Datenintegrität bei Ausfällen durch idempotente Operationen und ein Statusprotokoll. Dieser Ansatz funktioniert mit jeder Datenbank, einschließlich MongoDB, und verhindert Datenverlust durch Stromausfälle oder Systemabstürze.

So funktionieren mehrphasige Transaktionen

Transaktionen werden in aufeinanderfolgende Phasen zerlegt, die jeweils in einer separaten TRANSACTIONS-Tabelle protokolliert werden. Wichtige Status:

• blocking — Konten sperren, um parallele Operationen zu verhindern.
• save_balance — Ursprüngliche Kontostände als Snapshot ins Protokoll speichern.
• main — Kernüberweisung der Gelder ausführen.
• unlock — Kontensperren nach Abschluss freigeben.
• finished — Endstatus für erfolgreiche Transaktionen.

Idempotenz stellt sicher, dass das Wiederholen einer Phase nach einem Ausfall die Daten nicht korrumpiert. Beispiel: A := B + 1 ist idempotent, A := A + 1 nicht – letzteres lässt sich aber in zwei idempotente Schritte zerlegen.

Implementierungsschritte mit Code-Beispielen

Überweisen wir 250 € vom Konto von Assange zu Agent Y. Ausgangsdaten in der ACCOUNTS-Tabelle:

| ID | NAME | BALANCE | TR_ID |

|----|----------|---------|-------|

| 34 | Assange | 300 | null |

| 78 | Agent Y | 7 | null |

1. Konten sperren (STATUS='blocking')

Zuerst eine TRANSACTIONS-Zeile anlegen:

| ID | FROM_ID | TO_ID | AMOUNT | FROM_BALANCE | TO_BALANCE | STATUS |

|----|---------|-------|--------|--------------|------------|----------|

| 172| 34 | 78 | 250 | null | null | blocking |

Sperrung mit atomaren Befehlen, z. B. in MongoDB:

db.accounts.updateOne(
  { ID: 34, TR_ID: null },
  { $set: { TR_ID: 172 } }
);

Wird kein Dokument aktualisiert, ist die Sperre fehlgeschlagen – erneut versuchen oder abbrechen. IDs vorher sortieren, um Deadlocks zu vermeiden.

2. Kontostände sichern (STATUS='save_balance')

Nach der Sperrung originale Stände in TRANSACTIONS kopieren – idempotent per Design:

db.transactions.updateOne(
  { ID: 172 },
  { $set: { FROM_BALANCE: 300, TO_BALANCE: 7, STATUS: 'save_balance' } }
);

3. Überweisung ausführen (STATUS='main')

Kernoperation nutzt gespeicherte Stände für Idempotenz:

db.accounts.updateOne(
  { ID: 34, TR_ID: 172 },
  { $set: { BALANCE: 50 } } // 300 - 250
);

db.accounts.updateOne(
  { ID: 78, TR_ID: 172 },
  { $set: { BALANCE: 257 } } // 7 + 250
);

Status erst auf 'unlock' setzen, wenn Änderungen wirksam sind.

4. Entsperren und Abschließen (STATUS='unlock')

Sperren mit TR_ID-Prüfung freigeben:

db.accounts.updateOne(
  { ID: 34, TR_ID: 172 },
  { $set: { TR_ID: null } }
);

Nach Entsperrung beider Konten Status auf 'finished' setzen.

Vorteile und Einschränkungen

Wichtige Vorteile:

• Fehlertoleranz: Erholt sich von jedem Ausfall ohne Datenverlust.
• Idempotenz: Sicheres Wiederholen von Operationen, essenziell für verteilte Systeme.
• Flexibilität: Funktioniert bei allen Datenbanken, nicht nur MongoDB.
• Konsistenz: Erhält Datenintegrität in jeder Phase.
• Performance: Zusätzliches Logging kann bremsen.

Nachteile sind erhöhte Komplexität und Protokoll-Overhead. Für Finanz-Apps oder kritische Systeme lohnt es sich.

Tipps für Entwickler

• Nutzen Sie atomare DB-Operationen für Sperren und Updates.
• Bauen Sie Retry-Logik für fehlgeschlagene Sperren ein.
• Testen Sie Absturz-Szenarien, z. B. plötzliche Prozess-Kills.
• Sortieren Sie IDs, um Deadlock-Risiken zu minimieren.

So erreichen Sie 2PC-Niveau-Reliabilität mit NoSQL-Flexibilität.

— Editorial Team