Verteilte Transaktionen
Mechanismen, die sicherstellen, dass eine Reihe von Datenbankoperationen über mehrere unabhängige Knoten hinweg entweder alle erfolgreich sind (Commit) oder alle rückgängig gemacht werden (Rollback) — atomar.
Das CAP-Theorem (Brewer, 2000): Ein verteiltes System kann nur zwei von drei garantieren — Consistency, Availability, Partition Tolerance.
graph LR
Center["Verteilte Transaktionen"]:::main
Rel_decentralized_derivatives_pricing_models["decentralized-derivatives-pricing-models"]:::related -.-> Center
click Rel_decentralized_derivatives_pricing_models "/terms/decentralized-derivatives-pricing-models"
Rel_transaction_sharding["transaction-sharding"]:::related -.-> Center
click Rel_transaction_sharding "/terms/transaction-sharding"
Rel_decentralized_exchange_dex_order_book["decentralized-exchange-dex-order-book"]:::related -.-> Center
click Rel_decentralized_exchange_dex_order_book "/terms/decentralized-exchange-dex-order-book"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 Erkläre es wie einem 5-Jährigen
Stell dir vor, du kaufst ein Konzertticket online. Die Website muss zwei Dinge gleichzeitig tun: (1) Geld von deiner Bank abbuchen, (2) dir das Ticket geben. Wenn der Bankrechner das Geld abbucht, aber der Ticketrechner abstürzt, hast du bezahlt aber nichts bekommen. Eine verteilte Transaktion ist die Regel: 'Entweder beides gelingt, oder beides wird komplett rückgängig gemacht — als wäre nichts passiert.' Alles oder nichts, über mehrere Computer hinweg.
🤓 Expert Deep Dive
2PC — Blocking-Protokoll: Der Coordinator sendet PREPARE an alle Teilnehmer. Crasht der Coordinator nach dem Erhalt aller YES-Stimmen, aber vor dem COMMIT, halten Teilnehmer unbegrenzt exklusive Locks. SAGA-Muster: Jeder Schritt T_i hat eine kompensierende Transaktion C_i. Bei Fehler in T_3 werden C_2, dann C_1 ausgeführt. SAGAs opfern Isolation für Verfügbarkeit. HTLC: Alice sperrt BTC mit hash(secret); Bob sperrt ETH mit demselben Hash. Wenn Alice den Secret preisgibt, kann Bob ihn nutzen. CAP-Theorem: Konsistenz vs. Verfügbarkeit bei Netzwerkpartitionen.
❓ Häufig gestellte Fragen
What is the main problem with Two-Phase Commit (2PC)?
It is a blocking protocol. If the coordinator crashes after collecting all 'YES' votes but before sending the final COMMIT or ABORT decision, all participant nodes freeze, holding database locks indefinitely, until the coordinator recovers.
What is the SAGA pattern and why is it preferred in microservices?
A SAGA breaks a long transaction into smaller local transactions, each with a compensating transaction that undoes it. It avoids distributed locks, making services more available, but sacrifices strict isolation (intermediate states may be visible to other services).
How does a Hash Time Lock Contract (HTLC) enable trustless atomic swaps?
Both parties lock their assets using the same cryptographic secret hash. The first party reveals the secret to claim the other's asset, and this revelation automatically unlocks the secret for the second party to claim the first's asset. If either party doesn't act within the time limit, funds are refunded.