Distributed Transactions
Les transactions distribuées coordonnent les mises à jour sur plusieurs ressources pour maintenir l'atomicité, la cohérence, l'isolation et la durabilité dans un système distribué.
Les transactions distribuées coordonnent les mises à jour sur plusieurs ressources, souvent hétérogènes, pour accomplir une seule opération logique. Elles visent à préserver les propriétés ACID sur des resource managers qui ne partagent pas de datastore commun. Les approches de coordination courantes incluent le two-phase commit (2PC), le three-phase commit (3PC), ou les compensating transactions (Sagas) pour les workflows de longue durée. Les préoccupations clés incluent le coordination blocking, les single points of failure, la latence, et la gestion des partial failures avec rollback ou compensation. La conception pratique utilise souvent un transaction manager et des resource managers qui supportent des interfaces standardisées telles que XA/JTA ou DTC, et peut s'appuyer sur des outbox patterns, des idempotent operations, et du logging pour l'auditabilité. Dans les architectures de microservices contemporaines, le strong global ACID est souvent échangé contre l'eventual consistency avec des compensating actions pour améliorer la disponibilité et la latence.
graph LR
Center["Distributed Transactions"]:::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;
🧒 Explique-moi comme si j'avais 5 ans
Generated ELI5 content
🤓 Expert Deep Dive
Generated expert content
❓ Questions fréquentes
What is a distributed transaction?
A transaction that spans multiple networked resources and coordinates to appear atomic across all participants.
What does ACID mean in this context?
Atomicity, Consistency, Isolation, and Durability, applied across multiple resources through coordination protocols.
What is two-phase commit (2PC)?
A protocol with a prepare phase and a commit phase to ensure all participants commit or roll back together.
What about sagas and compensating actions?
Sagas sequence local transactions with compensating actions to achieve long-running distributed transactions without locking all resources.
What are common failure modes?
Coordinator failure, participant failure, network partitions, and lock contention can lead to blocking or partial commits.
When should you use 2PC vs sagas?
Use 2PC for short, strongly consistent, bounded transactions; use sagas for long-running processes requiring high availability and eventual consistency.
What are alternatives to strict ACID?
Eventual consistency models, compensating actions, and idempotent design patterns.