Повеќерегионално пишување: каде всушност се потврдува промената?
Рутирањето носи барање до регион; само границата на трансакцијата го прави пишувањето атомско. Наведете го инвариантот, изберете сопственик и потоа дизајнирајте го повторувањето околу него.
Два сервери за апликации во два региони, еден клиент што пишува преку VPN и прашање што никој не го запишал: која компонента одлучува дека пишувањето се случило? Рутирањето го носи барањето до процес. Границата на трансакцијата одлучува кога промената станува трајна и видлива. Тоа се различни работи што ги вршат различни системи, и јазот меѓу нив е местото каде што живеат повеќето грешки при повеќерегионално пишување.
Почнете од деловното правило, не од картата
Почнете со реченица за деловното правило наместо за географијата: кои читања и пишувања мора да успеат заедно и кои истовремени промени мора да бидат невозможни додека тоа се случува. За резервација на залихи тоа значи дека проверката на залихите и резервацијата или двете стапуваат на сила или ниту една, и ниту една втора нарачка не смее да ја потроши истата единица меѓу нив.
| 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 |
Токму тој среден ред тимовите го прескокнуваат. Атомичноста без доволна изолација им дозволува на две трансакции секоја правилно да се потврди и сепак да создадат состојба што бизнисот ја смета за невозможна, и подоцна тоа не го поправа никаква логика за повторување.
Една авторитетна граница победува два регионални сервери
Регионалните сервери за апликации можат да останат каде што се, додека операцијата ја поднесуваат до услуга што ја извршува во рамки на една поддржана граница на трансакција. Апликацискиот слој станува рутер на намерата; податочниот слој ја поседува вистината.
Држете ја таа граница кратка и блиску до податоците што ги допира. Трансакцијата што се држи отворена додека човек одговара на барање или додека повик преминува два региони, го поминува времето држејќи заклучувања и зголемувајќи ја шансата нешто друго да истече зад неа. Тој неуспех изгледа како проблем со база на податоци и всушност е проблем со дизајнот облечен како таков. Преместувањето на одлуката во податочниот слој обично целосно го отстранува.
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;Читајте ја таа скица како граница, а не како препорака за перформанси. Поентата е дека проверката и вметнувањето делат едно потврдување, па истовремена нарачка или гледа залихите потрошени или воопшто не ги гледа.
Што дава и што не дава реплицирана база на податоци
Реплицираната база на податоци може да обезбеди поширока граница кога нејзиниот сопствен модел на трансакции го поддржува тоа. Spanner документира атомски трансакции за читање и пишување во една база на податоци низ табели, со дефинирана изолација и однесување при повторување. Тоа е гаранција што ја читате, тестирате и намерно се потпирате на неа.
Тоа е и гаранција што доаѓа од производот, а не од маршрутата. VPN меѓу региони менува како патуваат пакетите и како се појавуваат дефектите. Тој не ја продолжува границата на трансакцијата ниту за еден ред, колку и да изгледа здраво тунелот. Мешањето на двете создава архитектури во кои секоја компонента ја поминува сопствената проверка, а податоците се уште не се совпаѓаат.
Две бази на податоци не стануваат еден систем
Две независно управувани бази на податоци не добиваат заеднички менаџер на трансакции затоа што клиентите можат да стигнат до двете. Ако на бизнисот навистина му треба атомска обврска низ парот, механизмот за координација, учесниците и процесот за враќање мора да бидат избрани и квалификувани, а не претпоставени.
Размислете за моментот кога учесник или врска исчезнува откако работата е подготвена. Поддржаното дистрибуирано потврдување може да остави неизвесна состојба на која ѝ треба процедура за враќање и човечка одлука, и не доаѓа со ветување дека секој регион ќе остане запишлив низ секое поделба.
Ако наместо тоа е прифатлива асинхрона координација, кажете го тоа експлицитно и запишете ги меѓусебните деловни состојби и правилата за усогласување. Синџирот од локално потврдени чекори со компензација е легитимен дизајн; едноставно не е една атомска трансакција под друго име.
Дизајнирајте го повторувањето пред првиот прекин
Клиентот може да го загуби одговорот откако операцијата е потврдена, па повикувачот не може да го смета истекот на времето за неуспех. Зачувајте трајен идентитет на барањето и пред да повторите промена користете го резултатот на услугата или механизам за идемпотентност, инаку повторувањето станува второ пишување.
Автоматските повратни повици на трансакции исто така можат да се извршат повеќе од еднаш по повторлив прекин, што ги прави лош дом за неповратни надворешни ефекти. Држете ги надвор од повратниот повик, освен ако работниот тек за нив дефинира експлицитен безбеден протокол. Истото внимание важи за се што чини пари или испраќа порака. Двојното наплатување е многу потежок разговор од двојна линија во дневник.
Приемот треба да повтори четири сценарија: два клиенти што се натпреваруваат за истиот ред, прекин што услугата го нарекува повторлив, потврда чиј одговор никогаш не пристигнува, и губење на регион или на врската меѓу нив. Запишете го потврдениот деловен резултат и нерешените состојби до дизајнот на рутирањето, за никој да не ја замени мрежата со компонентата што ја дава гаранцијата.