Kétfázisú commit, izoláció és a határok újragondolása

Célok

A lecke végére el tudod magyarázni a kétfázisú commit működését és korlátait, meg tudod különböztetni az atomiságot az izolációtól, és értékelni tudod, mikor érdemes a szolgáltatáshatárt újragondolni.

Miért kell?

Ha a közös tranzakció hiányzik, két kérdés merül fel: lehet-e mégis atomi commitot kérni több résztvevőtől, és mi történik azzal a köztes állapottal, amelyet a saga más műveletek elé tár. Az első a kétfázisú commit, a második az üzleti izoláció kérdése.

Kétfázisú commit

A kétfázisú commit (two-phase commit, 2PC) egy koordinátorral egyezteti a résztvevők közös commitját. Az első szakaszban a koordinátor megkérdezi a résztvevőket, készek-e véglegesíteni; ők a commit pontig elvégzik a munkát, naplózzák, és igennel vagy nemmel szavaznak. A másodikban, ha mindenki igent mondott, a koordinátor véglegesít, különben visszagörget.

sequenceDiagram
  participant K as Koordinátor
  participant A as Résztvevő A
  participant B as Résztvevő B
  K->>A: Prepare
  K->>B: Prepare
  A-->>K: Ready
  B-->>K: Ready
  K->>A: Commit
  K->>B: Commit

A Wikipedia szerint a 2PC legnagyobb hátránya, hogy blokkoló protokoll: az a résztvevő, amely igennel szavazott, várni kényszerül a koordinátor döntésére, és ha a koordinátor tartósan kiesik, határozatlan ideig várhat. A várakozás alatt a zárak is megmaradnak.

A PostgreSQL dokumentációja a PREPARE TRANSACTION parancsot külső tranzakciókezelő számára létrehozott eszközként írja le, és kifejezetten nem alkalmazásokba szánja; hosszan előkészített állapotban hagyott tranzakció zárakat tart, akadályozza a takarítást, és szélsőséges esetben akár az adatbázis leállását is okozhatja. Ez jól mutatja, hogy a 2PC csak olyan résztvevőkkel használható, amelyek a protokollt támogatják: egy tetszőleges HTTP-végpont nem válik 2PC-résztvevővé.

A közös commitért cserébe erősebb futásidejű és infrastruktúra-függés jelenik meg.

Saga és izoláció

Sagánál a helyi tranzakciók már végrehajtódtak, amikor a következő lépés indul, ezért más művelet láthatja a köztes állapotot. Az atomicitás és az izoláció két külön kérdés: ha egy hibás folyamatot végül kompenzálnak, a köztes állapotot más műveletek már láthatták.

A köztes állapotra explicit üzleti izolációs szabály kell. Ilyen lehet az ideiglenes foglalás lejárattal, az állapothoz kötött műveletengedély vagy a verzióellenőrzés. A microservices.io szerint az izoláció hiányát a sagánál ellenintézkedésekkel kell kezelni. Ezek nem azonosak a közös adatbázis-tranzakció izolációjával.

Két párhuzamos saga ugyanarra az erőforrásra versenghet; az erőforrás gazdájának helyben atomi döntést kell hoznia. A késői kompenzáció sem érinthet vakon más műveletet: a konkrét foglaláshoz tartozó azonosító és az állapotellenőrzés véd attól, hogy egy régi kompenzáció új állapotot rontson el.

Összevetés

Szempont	Helyi tranzakció	2PC	Saga
Hatókör	Egy adatbázis	Több, protokollt támogató résztvevő	Több szolgáltatás
Atomicitás	Igen	Igen (a protokoll keretei közt)	Nem; kompenzáció
Izoláció	Igen	Igen	Nincs; üzleti szabállyal pótolandó
Rendelkezésre állás	Egy adatbázistól függ	A koordinátor és a résztvevők együtt; blokkolás lehetséges	Nincs blokkolás, de köztes állapotok
Bonyolultság	Alacsony	Infrastruktúra	Alkalmazási logika

A határ újragondolása

Ha két adat minden műveletben azonnali, közös invariánst igényel, érdemes megvizsgálni, valóban külön adatgazdához kell-e tartozniuk. A rossz felbontást nem javítja több infrastruktúra: egy moduláris monolit vagy egy nagyobb, kohézív szolgáltatás egyszerűbb és helyesebb lehet (2.4, 3.2). A külön szolgáltatás indoka lehet szabályozási vagy szervezeti követelmény is; ilyenkor vállalni kell a folyamatállapotot és az egyeztetést, és pontosan meg kell mondani, mi garantált.

Gyakori tévhitek

Állítás	Pontosítás
„A 2PC bármilyen szolgáltatással használható.”	Csak a protokollt támogató résztvevőkkel.
„A 2PC garantáltan folyamatosan működik.”	Blokkoló protokoll; a koordinátor kiesése várakozást okozhat.
„A saga izolált, mint egy tranzakció.”	Nincs izoláció; üzleti szabályokkal pótolandó.
„A rossz felbontást több infrastruktúra megoldja.”	Néha a határ összevonása a helyes válasz.

Röviden

• A 2PC közös commitot ad a protokollt támogató résztvevőknek, de blokkoló.
• A saga lemond az izolációról; azt üzleti szabályokkal (lejáratos foglalás, állapotellenőrzés, verzió) kell pótolni.
• Az atomiság és az izoláció külön kérdés.
• Ha két adat közös, azonnali invariánst igényel, a határ újragondolandó.

Ellenőrző kérdések

1. Miért blokkoló protokoll a 2PC?
2. Hogyan védi meg a rendszert a lejáratos foglalás a köztes állapottól?
3. Mikor érdemes két szolgáltatást egy adatgazdába vonni?

Források

• Two-phase commit protocol (Wikipedia) — a két szakasz, a blokkolás hátránya.
• PREPARE TRANSACTION (PostgreSQL) — egy konkrét előkészített tranzakció működése és figyelmeztetései.
• Saga pattern (microservices.io) — az izoláció hiánya és az ellenintézkedések.