Jawaban singkat untuk pertanyaan yang paling sering diajukan pembaca tentang topik ini.
Two-phase commit vs saga untuk distributed transaction: bagaimana 2PC memblokir dan menahan lock, apa yang ditawarkan PREPARE TRANSACTION, dan kapan saga lebih cocok.
Matthews Wong
Software Engineer
Ringkasan Utama
Pakai two-phase commit bila semua participant mendukung prepare, Anda mengoperasikan semuanya, dan transaksinya singkat: atomicity all-or-nothing, tetapi memblokir dan menahan lock jika coordinator mati. Pakai saga bila langkah melintasi service atau vendor: tiap langkah di-commit lokal dan kegagalan memicu compensating action, mengorbankan isolation demi availability.
ERP carwash seperti Qilap menerima pembayaran, mengurangi stok shampoo dan wax, lalu menandai tiket cuci sebagai lunas. Di satu database Postgres itu cukup satu BEGIN dan satu COMMIT, tanpa perlu dipikirkan. Begitu pembayaran ada di gateway dan stok ada di service lain, kalimat yang sama berubah menjadi distributed transaction, dan pertanyaan sebenarnya adalah apa yang terjadi ketika satu sisi berhasil dan sisi lain gagal.
Post ini membandingkan dua jawaban standar, two-phase commit dan saga pattern, dengan contoh checkout tiga langkah. Rujukannya adalah dokumentasi PostgreSQL, artikel Wikipedia tentang two-phase commit, microservices.io, dan paper Sagas yang asli. Implementasi saga di NestJS ada di post saya sebelumnya; post ini fokus pada cara memilih di antara keduanya.
Seorang coordinator memecah satu distributed commit menjadi dua fase. Di fase prepare, ia bertanya ke setiap participant apakah bisa commit; masing-masing membuat perubahannya durable, tetap memegang lock, lalu memberi suara yes atau no. Di fase commit, bila semua suara yes, coordinator menyuruh semuanya commit; bila ada suara no atau suara yang tak pernah datang, semuanya disuruh rollback.
// Two-phase commit, coordinator side. Three participants: orders-db, stock-db, payments-ledger.
// Phase 1: prepare. Each participant makes its work durable, KEEPS its locks, and votes.
votes = [orders.prepare(txid), stock.prepare(txid), payments.prepare(txid)] // 3 requests + 3 votes
log.write(txid, allYes(votes) ? "COMMIT" : "ABORT") // the decision must survive a coordinator crash
// Phase 2: the decision is delivered. Locks are released only when this arrives.
for (p of participants) p.finish(txid, decision) // 3 requests + 3 acksContoh hitungan dengan tiga participant: database orders, database stok, dan ledger pembayaran. Prepare butuh 3 request dan 3 vote, keputusan butuh 3 request dan 3 acknowledgement, jadi satu checkout adalah 3 + 3 + 3 + 3 = 12 pesan, ditambah coordinator menulis keputusannya ke log di antara kedua fase. Angkanya kurang penting dibanding jedanya: participant memegang lock sejak memberi vote yes sampai keputusan tiba, dan jeda itulah harga seluruh protokol.
Two-phase commit adalah protokol yang memblokir. Wikipedia menyebutnya kelemahan terbesar: participant yang sudah memberi vote yes harus menunggu coordinator, dan bila coordinator gagal permanen, sebagian participant tidak akan pernah menyelesaikan transaksinya.
Participant dalam kondisi itu tidak bisa memutuskan sendiri, sebab yang lain mungkin sudah diberi perintah sebaliknya. Maka setiap row yang dikunci tetap terkunci. Jika coordinator mati 5 menit, setiap row yang disentuh checkout in-doubt tidak bisa ditulis selama 5 x 60 = 300 detik, dan setiap order lain yang butuh row stok yang sama mengantre di belakangnya. Satu proses mati menjadi antrean lock di beberapa database, dan itulah harga sebenarnya dari 2PC.
Prepared transaction sengaja bertahan melewati restart, jadi tidak ada yang meng-timeout-kannya untuk Anda. Harus selalu ada seseorang atau sesuatu yang menyelesaikannya dengan commit atau rollback.
Bisa, lewat PREPARE TRANSACTION, COMMIT PREPARED, dan ROLLBACK PREPARED. Dokumentasi menyebut prepared transaction disimpan penuh di disk dan bisa di-commit dari session mana pun, bukan hanya session yang membuatnya. Fiturnya mati secara default: max_prepared_transactions bernilai default 0 dan hanya bisa diatur saat server start, jadi mengaktifkannya butuh restart.
-- postgresql.conf (restart required, the default is 0 = feature disabled)
-- max_prepared_transactions = 10
-- Session 1: the stock database's half of the checkout
BEGIN;
UPDATE stock SET qty = qty - 2 WHERE sku = 'WAX-500' AND qty >= 2;
PREPARE TRANSACTION 'checkout-42-stock'; -- no longer tied to this session; state is on disk
-- Any session, even after a crash and restart: what is in doubt right now?
SELECT gid, prepared, owner, database FROM pg_prepared_xacts;
-- The coordinator saw every vote come back yes, so it finishes (from ANY session):
COMMIT PREPARED 'checkout-42-stock';
-- ...or, if any other participant voted no:
-- ROLLBACK PREPARED 'checkout-42-stock';
-- Until one of those runs, the UPDATE above still holds its row lock on WAX-500.Halaman dokumentasi yang sama tegas bahwa PREPARE TRANSACTION tidak ditujukan untuk aplikasi. Fitur ini ada untuk external transaction manager, dan X/Open XA disebut sebagai contoh standarnya. Dokumentasi juga memperingatkan bahwa prepared transaction yang dibiarkan lama tetap memegang lock, mengganggu VACUUM, dan dalam kasus ekstrem bisa membuat database shutdown demi mencegah transaction ID wraparound. Tanpa transaction manager yang menutupnya dengan cepat, dokumentasi menyarankan membiarkan max_prepared_transactions di nol.
Jika tetap mengaktifkannya, dokumentasi menyarankan nilai minimal sebesar max_connections agar tiap session bisa punya satu prepared transaction yang menunggu. Tambahan dari saya: pasang alert untuk setiap row di pg_prepared_xacts yang lebih tua dari semenit, karena coordinator yang sehat selesai dalam hitungan milidetik.
Saga mengganti satu distributed transaction dengan serangkaian local transaction, masing-masing langsung di-commit di service-nya sendiri. Jika sebuah langkah gagal karena aturan bisnis, saga menjalankan compensating transaction yang membatalkan langkah-langkah sebelumnya, seperti dijelaskan microservices.io. Idenya berasal dari paper Sagas tahun 1987 oleh Garcia-Molina dan Salem, yang ditulis untuk long lived transaction yang kalau tidak akan menahan lock berjam-jam atau berhari-hari. Ada dua cara mengoordinasikan langkahnya.
Untuk checkout tiga langkah saya memilih orchestration, karena jalur kegagalan adalah bagian yang perlu dibaca dan diuji. Choreography cocok untuk dua atau tiga service dengan alur yang jarang berubah. Implementasi NestJS ada di post saya sebelumnya: Saga pattern untuk distributed transaction di NestJS
Setiap langkah membawa undo-nya sendiri, dan undo itu adalah transaksi forward yang baru, bukan rollback. Ia tidak bisa menghapus fakta bahwa pembayaran pernah di-authorise; ia hanya bisa melakukan void atau refund. Karena itu compensation harus idempotent dan di-retry sampai berhasil: gangguan yang menggagalkan langkah itu mungkin masih berlangsung. Mekanismenya dibahas di post idempotency keys. Sketsa di bawah menyimpan daftar langkah yang selesai lalu membongkarnya dari belakang.
type Step<C> = {
name: string;
run: (ctx: C) => Promise<void>;
compensate: (ctx: C) => Promise<void>; // a NEW forward action: void, refund, release. Not a rollback.
};
const checkout: Step<Ctx>[] = [
{ name: "reserve-stock", run: reserveStock, compensate: releaseStock },
{ name: "authorise-payment", run: authorisePayment, compensate: voidAuthorisation },
{ name: "confirm-order", run: confirmOrder, compensate: cancelOrder },
];
async function runSaga(steps: Step<Ctx>[], ctx: Ctx) {
const done: Step<Ctx>[] = [];
for (const step of steps) {
try {
await step.run(ctx);
done.push(step); // persist this list: a crash mid-saga must be resumable
} catch (err) {
// Undo in reverse order. Retry each compensation until it succeeds, and make it idempotent,
// because the outage that failed the step may still be going on.
for (const prev of done.reverse()) await retryForever(() => prev.compensate(ctx));
throw err;
}
}
}Contoh kegagalan: tiga langkah, reserve stock, authorise payment, confirm order. Jika confirm order melempar error, saga menjalankan dua compensation secara terbalik, void authorisation lalu release stock. Kasus terburuknya 3 + 2 = 5 local transaction, dan tak satu pun menahan lock melintasi network call. Urutkan langkah supaya yang tidak bisa dibatalkan, seperti mengirim receipt, berjalan paling akhir. Itu aturan praktis saya, bukan teorema.
Saga hanya atomic secara eventual, dan tidak punya isolation. Paper Sagas menggambarkan rangkaian transaksi yang bisa saling berselang-seling dengan pekerjaan lain, sehingga transaksi lain melihat state perantara. Di antara langkah 1 dan sebuah compensation, stok yang di-reserve terlihat oleh semua orang.
Contoh hitungan: stok 10 unit. Saga A me-reserve 6, tersisa 4. Saga B meminta 5, melihat 4, dan diberi tahu stok habis. Lalu pembayaran A gagal dan compensation-nya mengembalikan 6 unit, 4 + 6 = 10, yang sebenarnya cukup untuk B. B ditolak berdasarkan state yang tidak pernah menjadi nyata. Tiga countermeasure umum mengurangi dampaknya.
Tidak ada yang lebih baik secara umum. Keduanya berada di titik berbeda pada pertukaran antara isolation dan availability, dan perbandingan di bawah adalah titik awal saya.
| Dimensi | Two-phase commit | Saga |
|---|---|---|
| Atomicity | Semua participant commit atau tidak sama sekali, diputuskan satu coordinator | Tiap langkah di-commit sendiri; keseluruhan atomic hanya secara eventual, lewat compensation |
| Isolation | Lock ditahan sampai ada keputusan, jadi state sebagian tetap tersembunyi | Tidak ada: state sebagian terlihat, jadi perlu semantic lock |
| Saat ada yang gagal | Coordinator crash membuat participant in-doubt terblokir sambil menahan lock | Langkah gagal memicu compensation; tidak ada lock yang ditahan antar langkah |
| Syarat participant | Setiap participant harus mendukung prepare, seperti PostgreSQL atau resource XA | Service apa pun dengan local transaction dan undo, termasuk HTTP API dan gateway |
| Paling cocok untuk | Beberapa database yang Anda operasikan sendiri, dengan transaksi singkat | Alur lintas service atau pihak ketiga dan proses bisnis yang berjalan lama |
| Biaya utama | Availability, ditambah prepared transaction yang harus dijaga seseorang | Usaha desain: compensation, idempotency, dan penanganan anomali |
Jalankan pertanyaan berikut berurutan dan berhenti pada jawaban pertama yang menentukan.
Mulailah dengan mencoba menghindari distributed transaction sama sekali. Jika tak terhindarkan, pilih two-phase commit hanya bila Anda mengendalikan semua participant dan bisa menerima blocking, dan pilih saga bila langkah melintasi service atau vendor dan Anda bisa menulis undo yang aman untuk tiap langkah. Apa pun pilihannya, pekerjaan belum selesai sampai ada alert ketika prepared transaction atau saga yang setengah jalan tertinggal.
Post terkait