Több régiós írások: hol történik meg valójában a véglegesítés?
Az útválasztás eljuttatja a kérést egy régióba; csak egy tranzakcióhatár tesz atomicitás. Nevezze meg az invariánst, válassza ki a tulajdonost, majd az újrapróbálkozást is ehhez tervezze.
Két alkalmazásszerver két régióban, egy ügyfél amely VPN-en keresztül ír, és egy kérdés amelyet senki nem írt le: melyik komponens dönti el, hogy az írás megtörtént? Az útválasztás eljuttatja a kérést egy folyamathoz. Egy tranzakcióhatár dönti el, mikor válik a változás tartóssá és láthatóvá. Ezek különböző feladatok, amelyeket különböző rendszerek látnak el, és a köztük lévő szakadék az, ahol a több régiós írások legtöbb hibája él.
Az üzleti szabályból induljon, ne a térképből
Egy, az üzleti szabályról szóló mondattal kezdje, ne a földrajzról: mely olvasásoknak és írásoknak kell együtt sikerülniük, és mely egyidejű változásoknak kell lehetetlennek lenniük eközben. Egy készletfoglalásnál ez azt jelenti, hogy a készletellenőrzés és a foglalás vagy mindkettő érvénybe lép, vagy egyik sem, és egyetlen második rendelés sem használhatja fel ugyanazt az egységet közben.
| Requirement | What satisfies it | What does not |
|---|---|---|
| All-or-nothing application | A transaction inside one owning system | A VPN path between regions |
| No double spend | Isolation strong enough to exclude the conflict | Atomicity alone |
| Survive a region loss | Replication the database itself documents | Two independent databases behind one client |
Pont ezt a középső sort hagyják ki a csapatok. Az atomicitás megfelelő elkülönítés nélkül lehetővé teszi, hogy két tranzakció külön-külön helyesen véglegesüljön, és mégis olyan állapotot hozzon létre, amelyet az üzlet lehetetlennek tart, és utána semmilyen újrapróbálkozási logika nem javítja meg.
Egy hiteles határ legyőzi a két regionális szervert
A regionális alkalmazásszerverek maradhatnak a helyükön, amíg a műveletet olyan szolgáltatásnak adják át, amely egyetlen támogatott tranzakcióhatáron belül hajtja végre. Az alkalmazási réteg a szándék irányítójává válik; az adatréteg birtokolja az igazságot.
Tartsa ezt a határt rövidnek és közel ahhoz az adathoz, amelyet érint. Az a tranzakció, amelyet nyitva tartanak, míg egy ember válaszol egy felszólításra, vagy míg egy hívás két régiót szel át, az idejét zárak tartásával tölti, és növeli annak esélyét, hogy mögötte valami más lejár. Ez a hiba adatbázis-problémának látszik, és valójában egy ilyennek álcázott tervezési probléma. A döntés adatrétegbe mozgatása általában teljesen megszünteti.
BEGIN;
UPDATE inventory SET reserved = reserved + 1
WHERE sku = 'A-100' AND available >= 1;
INSERT INTO reservation (sku, order_id) VALUES ('A-100', 'ord-9f');
COMMIT;Ezt a vázlatot határként olvassa, nem teljesítményajánlásként. A lényeg az, hogy az ellenőrzés és a beszúrás egy véglegesítést oszt meg, így egy egyidejű rendelés vagy felhasználtnak látja a készletet, vagy egyáltalán nem látja.
Mit ad és mit nem ad egy replikált adatbázis
Egy replikált adatbázis szélesebb határt nyújthat, amikor a saját tranzakciós modellje támogatja. A Spanner atomi olvasási-írási tranzakciókat dokumentál egyetlen adatbázison belül, táblákon át, meghatározott elkülönítéssel és újrapróbálkozási viselkedéssel. Ez olyan garancia, amelyet elolvas, tesztel, és amelyre szándékosan támaszkodik.
Ez egyben olyan garancia, amely a terméktől jön, nem az útvonaltól. A régiók közötti VPN megváltoztatja, hogyan utaznak a csomagok, és hogyan mutatkoznak meg a hibák. Egyetlen sorral sem hosszabbítja meg a tranzakcióhatárt, akármilyen egészségesnek tűnik az alagút. A kettő összekeverése olyan architektúrákat hoz létre, ahol minden komponens átmegy a saját ellenőrzésén, és az adatok mégsem egyeznek.
Két adatbázis nem válik egyetlen rendszerré
Két függetlenül kezelt adatbázis nem kap közös tranzakciókezelőt attól, hogy az ügyfelek mindkettőt elérik. Ha az üzlet valóban atomi kötelezettségvállalást igényel a pár fölött, a koordinációs mechanizmust, a résztvevőket és a helyreállítási folyamatot mind ki kell választani és minősíteni kell, nem pedig feltételezni.
Gondoljon arra a pillanatra, amikor egy résztvevő vagy egy kapcsolat eltűnik, miután a munkát előkészítették. Egy támogatott elosztott véglegesítés bizonytalan állapotot hagyhat maga után, amely helyreállítási eljárást és emberi döntést igényel, és nem ígéri meg, hogy minden régió írható marad minden felosztás során.
Ha ehelyett az aszinkron koordináció elfogadható, mondja ki egyértelműen, és írja le a köztes üzleti állapotokat és az egyeztetési szabályokat. A helyben véglegesített lépések lánca kompenzációval legitim tervezés; egyszerűen nem egyetlen atomi tranzakció más néven.
Tervezze meg az újrapróbálkozást az első kiesés előtt
Az ügyfél elveszítheti a választ, miután a művelet véglegesült, ezért a hívó nem tekintheti az időtúllépést hibának. Őrizzen meg egy tartós kérésazonosítót, és a módosítás újrapróbálkozása előtt használja a szolgáltatás eredményét vagy egy idempotenciamechanizmust, különben az újrapróbálkozás második írássá válik.
Az automatikus tranzakciós visszahívások egy újrapróbálható megszakítás után többször is lefuthatnak, ami rossz otthonná teszi őket visszafordíthatatlan külső hatások számára. Tartsa azokat a visszahíváson kívül, kivéve ha a munkafolyamat kifejezett biztonságos protokollt határoz meg számukra. Ugyanez az óvatosság vonatkozik mindenre, ami pénzbe kerül vagy üzenetet küld. A dupla terhelés sokkal nehezebb beszélgetés, mint egy dupla naplósor.
Az átvételnek négy forgatókönyvet kell újrajátszania: két ügyfél verseng ugyanazért a sorért, egy megszakítás amelyről a szolgáltatás azt mondja újrapróbálható, egy véglegesítés amelynek válasza soha nem érkezik meg, és egy régió vagy a köztük lévő kapcsolat elvesztése. Rögzítse a véglegesített üzleti eredményt és a megoldatlan állapotokat az útválasztási tervezés mellett, hogy senki ne tévessze össze a hálózatot a garanciát nyújtó komponenssel.