Kirjoitukset useassa alueessa: mihin muutos oikeastaan vahvistetaan?
Reititys vie pyynnön alueelle; vain transaktion raja tekee kirjoituksista atomisia. Nimeä invariantti, valitse omistaja ja suunnittele uudelleenyritys sen ympärille.
Kaksi sovelluspalvelinta kahdessa alueessa, yksi asiakas joka kirjoittaa VPN:n kautta, ja kysymys jota kukaan ei kirjoittanut: mikä komponentti päättää, että kirjoitus tapahtui? Reititys vie pyynnön prosessille. Transaktion raja päättää, milloin muutoksesta tulee pysyvä ja näkyvä. Ne ovat eri tehtäviä, joita eri järjestelmät suorittavat, ja niiden välinen kuilu on paikka, jossa suurin osa monialueisten kirjoitusten virheistä asuu.
Aloita liiketoimintasäännöstä, älä kartasta
Aloita lauseella liiketoimintasäännöstä, älä maantieteestä: mitkä lukemiset ja kirjoitukset onnistuvat yhdessä ja mitkä samanaikaiset muutokset on oltava mahdottomia sen aikana. Varastovarauksessa se tarkoittaa, että varastotarkistus ja varaus joko molemmat astuvat voimaan tai kumpikaan ei, eikä toinen tilaus saa kuluttaa samaa yksikköä välissä.
| 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 |
Juuri tuon keskimmäisen rivin tiimit ohittavat. Atomialisuus ilman riittävää eristystä sallii kahden transaktion kumpikin vahvistua oikein ja silti tuottaa tilan, jota liiketoiminta pitää mahdottomana, eikä mikään määrä uudelleenyrityslogiikkaa korjaa sitä jälkeenpäin.
Yksi valtuutettu raja voittaa kaksi alueellista palvelinta
Alueelliset sovelluspalvelimet voivat pysyä paikallaan, kunhan ne toimittavat operaation palvelulle, joka suorittaa sen yhden tuetun transaktiorajan sisällä. Sovelluskerroksesta tulee aikomuksen reititin; datakerros omistaa totuuden.
Pidä tuo raja lyhyenä ja lähellä dataa, jota se koskettaa. Transaktio, joka pidetään auki, kun ihminen vastaa kehotteeseen tai kun kutsu ylittää kaksi aluetta, kuluttaa aikansa lukkoja pitäen ja kasvattaa mahdollisuutta, että jokin muu vanhenee sen takana. Se virhe näyttää tietokantaongelmalta ja on todellisuudessa suunnitteluongelma, joka on pukeutunut sellaiseksi. Päätöksen siirtäminen datakerrokseen poistaa sen yleensä kokonaan.
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;Lue tuo luonnos rajana, älä suorituskykysuosituksena. Pointti on, että tarkistus ja lisäys jakavat yhden vahvistuksen, joten samanaikainen tilaus joko näkee varaston kulutetuksi tai ei näe sitä ollenkaan.
Mitä replikoitu tietokanta antaa ja mitä ei
Replikoitu tietokanta voi tarjota laajemman rajan, kun sen oma transaktiomalli tukee sitä. Spanner dokumentoi atomiset luku-kirjoitustransaktiot yhden tietokannan sisällä taulujen yli, määritellyllä eristyksellä ja uudelleenyrityskäyttäytymisellä. Se on takuu, jonka luet, testaat ja johon tarkoituksella nojaat.
Se on myös takuu, joka tulee tuotteesta, ei reitistä. Alueiden välinen VPN muuttaa sitä, miten paketit matkustavat ja miten viat ilmenevät. Se ei laajenna transaktiorajaa yhtään rivillä, niin terveeltä tunneli kuin vaikuttaakin. Näiden kahden sekoittaminen tuottaa arkkitehtuureja, joissa jokainen komponentti läpäisee oman tarkistuksensa ja data on silti ristiriidassa.
Kaksi tietokantaa ei muutu yhdeksi järjestelmäksi
Kaksi itsenäisesti hallittua tietokantaa eivät saa yhteistä transaktiohallintaa siksi, että asiakkaat pääsevät molempiin. Jos liiketoiminta todella tarvitsee atomisen sitoumuksen tämän parin yli, koordinointimekanismi, osallistujat ja palautumisprosessi on kaikki valittava ja kvalifioitava sen sijaan, että ne oletettaisiin.
Ajattele hetkeä, jolloin osallistuja tai linkki katoaa sen jälkeen, kun työ on valmisteltu. Tuettu hajautettu vahvistus voi jättää epävarman tilan, joka vaatii palautumismenettelyn ja inhimillisen päätöksen, eikä se lupaa, että jokainen alue pysyy kirjoitettavana jokaisen jakautumisen läpi.
Jos sen sijaan asynkroninen koordinointi on hyväksyttävää, sano se selvästi ja kirjoita ylös välilliset liiketoimintatilat sekä täsmäytyssäännöt. Ketju paikallisesti vahvistettuja vaiheita kompensaatiolla on laillinen suunnittelu; se ei vain ole yksi atominen transaktio toisella nimellä.
Suunnittele uudelleenyritys ennen ensimmäistä katkoa
Asiakas voi menettää vastauksen sen jälkeen, kun operaatio on vahvistettu, joten kutsuja ei voi pitää aikakatkaisua epäonnistumisena. Säilytä pysyvä pyyntöidentiteetti ja käytä palvelun tulosta tai idempotenssimekanismia ennen muutoksen uudelleenyritystä, muuten uudelleenyrityksestä tulee toinen kirjoitus.
Automaattiset transaktion takaisinkutsut voivat myös suorittua useammin kuin kerran uudelleenyrityskelpoisen keskeytyksen jälkeen, mikä tekee niistä huonon kodin peruuttamattomille ulkoisille vaikutuksille. Pidä ne takaisinkutsun ulkopuolella, ellei työnkulku määrittele niille nimenomaista turvallista protokollaa. Sama varovaisuus koskee kaikkea, mikä maksaa rahaa tai lähettää viestin. Kaksinkertainen veloitus on paljon vaikeampi keskustelu kuin kaksinkertainen lokirivi.
Hyväksynnän pitäisi toistaa neljä skenaariota: kaksi asiakasta kilpailemassa samasta rivistä, keskeytys jonka palvelu sanoo olevan uudelleenyrityskelpoinen, vahvistus jonka vastaus ei koskaan saavu, ja alueen tai niiden välisen linkin menetys. Kirjaa vahvistettu liiketoimintatulos ja ratkaisemattomat tilat reitityssuunnittelun viereen, jotta kukaan ei sekoita verkkoa komponenttiin, joka takuun tarjoaa.