Многорегионални записи: къде всъщност се потвърждава транзакцията?
Маршрутизирането доставя заявката до регион; само границата на транзакция прави записа атомарен. Назовете инварианта, изберете собственика и после проектирайте повторението около него.
Два сървъра за приложения в два региона, един клиент, който пише през 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 между региони променя как пътуват пакетите и как се проявяват отказите. Той не разширява границата на транзакция с нито един ред, колкото и здравословно да изглежда тунелът. Объркването на двете поражда архитектури, в които всеки компонент минава собствената си проверка, а данните все още се разминават.
Две бази данни не стават една система
Две независимо управлявани бази данни не придобиват споделен мениджър на транзакции, защото клиентите могат да достигнат и двете. Ако бизнесът наистина се нуждае от атомарен ангажимент между двете, механизмът за координация, участниците и процесът на възстановяване трябва да бъдат избрани и квалифицирани, а не приети за даденост.
Помислете за момента, в който участник или връзка изчезне, след като работата е подготвена. Поддържано разпределено потвърждение може да остави несигурно състояние, което изисква процедура за възстановяване и човешко решение, и то не дава обещание, че всеки регион остава достъпен за запис през всяко разделяне.
Ако вместо това е приемлива асинхронна координация, кажете го изрично и запишете междинните бизнес състояния плюс правилата за съгласуване. Верига от локално потвърдени стъпки с компенсация е законен дизайн; тя просто не е една атомарна транзакция под друго име.
Проектирайте повторението преди първия срив
Клиентът може да загуби отговора, след като операцията е потвърдена, затова извикващият не може да приеме изтичането на време за отказ. Пазете устойчива идентичност на заявката и използвайте резултата на услугата или механизъм за идемпотентност, преди да повторите промяна, иначе повторението се превръща във втори запис.
Автоматичните обратни извиквания на транзакции също могат да се изпълнят повече от веднъж след повторяемо прекъсване, което ги прави лош дом за необратими външни ефекти. Дръжте ги извън обратното извикване, освен ако работният процес не дефинира изричен безопасен протокол за тях. Същото внимание важи за всичко, което струва пари или изпраща съобщение. Дублираното таксуване е много по-труден разговор от дублиран ред в журнала.
Приемането трябва да преиграе четири сценария: два клиента, състезаващи се за един и същ ред, прекъсване, за което услугата казва, че може да се повтори, потвърждение, чийто отговор никога не пристига, и загуба на регион или на връзката между тях. Запишете потвърдения бизнес резултат и нерешените състояния до дизайна на маршрутизацията, за да не сбърка никой мрежата с компонента, който осигурява гаранцията.