Уписи у више региона: где се измена заиста потврђује?

Два сервера апликације у два региона, један клијент који пише преко VPN-а и питање које нико није записао: која компонента одлучује да се упис догодио? Рутирање доводи захтев до процеса. Граница трансакције одлучује када промена постаје трајна и видљива. То су различити послови које обављају различити системи, а јаз између њих је место где живи већина грешака при упису у више региона.

Почните од пословног правила, не од карте

Почните реченицом о пословном правилу, а не о географији: која читања и уписи морају заједно да успеју и које истовремене промене морају бити немогуће док се то дешава. За резервацију залиха то значи да провера залиха и резервација или обе ступају на снагу или ниједна, и ниједна друга поруџбина не сме да потроши исту јединицу између.

Управо тај средњи ред тимови прескачу. Атомичност без довољне изолације допушта двема трансакцијама да се свака исправно потврди и ипак произведе стање које посао сматра немогућим, а касније то не поправља никаква логика поновног покушаја.

Једна ауторитативна граница побеђује два регионална сервера

Регионални сервери апликације могу да остану где јесу, ако операцију предају сервису који је извршава унутар једне подржане границе трансакције. Слој апликације постаје рутер намере; слој података поседује истину.

Држите ту границу кратком и близу података које дотиче. Трансакција која остаје отворена док човек одговара на упит или док позив прелази два региона проводи време држећи браве и повећавајући шансу да нешто друго исцури за њом. Тај квар изгледа као проблем базе података и у ствари је проблем пројектовања обучен у такво. Премештање одлуке у слој података обично га потпуно уклања.

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 између региона мења како пакети путују и како се квар показује. Он не проширује границу трансакције ни за један ред, колико год тунел изгледао здрав. Мешање тога двога ствара архитектуре у којима свака компонента прође сопствену проверу, а подаци се и даље не слажу.

Две базе података не постају један систем

Две независно управљане базе података не добијају заједничког менаџера трансакција зато што клијенти могу да достигну обе. Ако је послу заиста потребна атомска обавеза преко тог пара, механизам координације, учесници и поступак опоравка морају бити изабрани и квалификовани, а не претпостављени.

Размислите о тренутку када учесник или веза нестане након што је посао припремљен. Подржано дистрибуирано потврђивање може да остави неизвесно стање коме су потребни поступак опоравка и људска одлука, и не долази са обећањем да ће сваки регион остати уписив кроз сваку поделу.

Ако је уместо тога прихватљива асинхрона координација, реците то изричито и запишите међустања посла и правила усаглашавања. Ланац локално потврђених корака са компензацијом је легитиман дизајн; једноставно није једна атомска трансакција под другим именом.

Пројектујте поновни покушај пре првог прекида

Клијент може да изгуби одговор након што је операција потврђена, па позивалац не може да третира истек времена као квар. Сачувајте трајни идентитет захтева и пре поновног покушаја измене користите исход сервиса или механизам идемпотенције, иначе поновни покушај постаје други упис.

Аутоматски повратни позиви трансакција такође могу да се изврше више од једном након прекида који се може поновити, што их чини лошим домом за неповратне спољне ефекте. Држите их изван повратног позива осим ако ток посла за њих дефинише изричит безбедан протокол. Иста опрезност важи за све што кошта новац или шаље поруку. Двоструко задужење је много тежи разговор од двоструког реда дневника.

Прихватање треба да поново одигра четири сценарија: два клијента који се такмиче за исти ред, прекид који сервис означава као поновљив, потврду чији одговор никада не стигне и губитак региона или везе између њих. Запишите потврђени пословни резултат и нерешена стања поред дизајна рутирања, да нико не замени мрежу са компонентом која даје гаранцију.