A kulcs a tranzakcióknál a konzisztencia. Ez a legnagyobb előnye, és ennek biztosításához szükséges az atomicitás és az izoláció. A konzisztencia biztosítása okozza a hátrányait. Ha két tranzakció átfedve fut és ugyanazon adatokat módosítana, akkor az egyik tranzakció végrehajtását minimum blokkolni kell, de sok esetben az egyik tranzakciót rollback-elni kell. Emiatt egy-egy tranzakciónak időben minél rövidebbnek kell lennie. A harmadik hátránya, hogy elosztott rendszereknél nagyon nehéz teljesíteni a fenti kritériumokat.
Saga:
Tevékenység sorozat végrehajtása, probléma esetén az addig végrehajtott tevékenységek hatásait kompenzálja. A tevékenység sorozat végrehajtása lehet lineáris és párhuzamos is, illetve a kettő keveréke. Saga esetén nem csak a tranzakcióban résztvevő tevékenységeket kell megadni, hanem minden tevékenységhez egy kompenzációs tevékenységet is, ami hiba esetén az adott tevékenység hatásait kompenzálja. Tehát itt hiba esetén a kiindulási állapot nem biztos, hogy visszaáll. Később meglátjuk, hogy ez nem hátrány, hanem inkább előny.
Hátránya, hogy itt nem minden pillanatban konzisztensek az adatok, sőt extrém esetben szinte sohasem. A való életben ez igazából nem is nagy probléma és az üzleti életben sokkal nagyobb a hozadéka azon előnyöknek, amiket nyerünk azzal, hogy nem ragaszkodunk ennyire a konzisztenciához.
Mik is az előnyei?
- A tevékenységsorozat hossza időben lehet tetszőlegesen nagy: percek, órák, napok vagy akár hetek, hónapok is.
- Az egyes tevékenység sorozatok futhatnak egymás mellett, egyik a másikat nem blokkolja és nagyon ritkán akadályozza meg teljesen a végrehajtását.
- Elosztott rendszereknél is könnyen megvalósítható.
- Probléma esetén a már végrehajtott tevékenységek kompenzációjára egy megoldás az eredeti állapot visszaállítása, de általában van ennél jobb megoldás is. Itt mi adhatjuk meg a kompenzáció mikéntjét.
Nézzünk egy példát!
Két bankszámla közötti pénz átutalás.
Egyidejű utalások: X -> Y, Y -> Z, Z -> X.
Tranzakció esetén az egyidejű utalásokat szépen egymás után kell végrehajtani, ez azt jelenti, hogy a végrehajtás ideje az egyes tranzakciók idejének összege lesz. Extrém esetben, ha a végrehajtás során folyamatosan konkurens utalások érkeznek, akkor az átutalási idő nagyon hosszúra nyúlhat.
Saga esetén ezek lehetnek az egyes tevékenységek:
T1: A forrás számláról levonjuk az összeget, ha lehet. Ha nem, akkor probléma van, lezárjuk a Saga-t (nincs mit kompenzálni)
T2: A cél számlára ráírjuk az összeget. Ha probléma merül fel, akkor CT1-gyel kompenzálunk, majd lezárjuk a Saga-t.
CT1: A forrás számlára visszaírjuk a levont összeget.
T1 és T2-őt itt egymás után futtatjuk.
Ebben az esetben amikor T1 levonta az összeget, de T2 még nem adta hozzá, addig inkonzisztens állapotban van, de ez igazán nem jelent hátrányt egyik résztvevőnek sem.
Az egyidejű átutalásokat párhuzamosan lehet végrehajtani, így a végrehajtási ideje a leglassabb ideje lesz.
Itt pl. ha folyamatosan jönnek a tranzakciók, akkor sosem lesz konzisztens állapotban minden adat, de a nagy részük abban lesz, csak az éppen végrehajtás alatt állók nem.
Később esetleg még írok másik példát is.
- enpassant blogja
- A hozzászóláshoz be kell jelentkezni
- 1026 megtekintés
Hozzászólások
Nagyon jó cikkek, már várom a következőt, köszönöm!
Üdv,
Marci
- A hozzászóláshoz be kell jelentkezni
Tettem fel egy példát, ahol egy foglalásra látunk példát Saga-val. A feladat A-ból B-be repülőjegyet foglalni, B-ben egy szobát foglalni és egy autót bérelni. A TravelAgencySequential-ben lineárisan foglalunk egymás után, a TravelAgency-ben pedig párhuzamosan.
A megvalósítás Scala nyelven Akka segítségével történt.
- A hozzászóláshoz be kell jelentkezni
Saga eseten: T2-vel milyen problema merulhet fel, ami nem merulhet fel CT1 eseten? Ha ct1 nem vegrehajthato (soha pl: szamla megszunt), akkor marad az inkonzisztens allapot.
- A hozzászóláshoz be kell jelentkezni
A T2 bár hasonló, mint a CT1, de ott nem kellenek szigorú ellenőrzések, pl. ha van olyan feltétel, hogy egy számlára csak bizonyos számlákról lehet rá utalni, akkor ezt kompenzációnál már nem kell vizsgálni.
Számla megszűnés talán nem jó példa, mert a megszüntetést addig szerintem nem véglegesítik, amíg vannak a számlának függő "tranzakciói". Természetesen nagyon fontos, hogy lehetőleg olyan kompenzációkat tervezzünk, amiket szinte mindig végre lehet hajtani.
A kompenzációk nem mindig kompenzálnak tökéletesen, inkonzisztens állapot is előfordulhat, de az kevesebb kárt okoz az üzletnek, mint ha kevesebb forgalom lenne, ezért vállalják be. Pl., ha elosztott rendszerben jegyeket árulnak két helyen és megszűnik a két hely közötti kommunikáció, akkor a konzisztens állapotot csak úgy lehet fenntartani, ha egyik helyen sem árulnak jegyeket addig, amíg helyre nem áll a kommunikáció. Lehet az az üzleti döntés, hogy sokkal jobban megéri, az utolsó ismert állapot szerint tovább árulni a jegyeket esetlegesen azt kockáztatva, hogy több jegyet adnak el, mint ahány férőhely van. Fel lehet hívni a figyelmet ilyenkor, hogy a vásárlás még nem végleges, azt visszavonhatják.
- A hozzászóláshoz be kell jelentkezni