Шматрэгіянальныя запісы: дзе насамрэч фіксуецца змена?

Два серверы праграмы ў двух рэгіёнах, адзін кліент, які піша праз 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 паміж рэгіёнамі змяняе тое, як падарожнічаюць пакеты і як праяўляюць сябе адмовы. Ён не пашырае мяжу транзакцыі ні на адзін радок, як бы здарова тунэль ні выглядаў. Змешванне гэтых двух спараджае архітэктуры, дзе кожны кампанент праходзіць уласную праверку, а даныя ўсё яшчэ супярэчаць.

Дзве базы даных не становяцца адной сістэмай

Дзве незалежна кіраваныя базы даных не набываюць агульнага мэнэджара транзакцый ад таго, што кліенты могуць дасягнуць абедзвюх. Калі бізнесу сапраўды патрэбна атамнае абавязанне паміж імі, механізм каардынацыі, удзельнікі і працэс аднаўлення мусяць быць абраныя і правераныя, а не прынятыя як дадзенае.

Падумайце пра момант, калі ўдзельнік або сувязь знікае пасля таго, як праца была падрыхтаваная. Падтрымоўваная размеркаваная фіксацыя можа пакінуць нявызначаны стан, які патрабуе працэдуры аднаўлення і чалавечага рашэння, і яна не абяцае, што кожны рэгіён застанецца даступным для запісу праз кожнае раздзяленне.

Калі замест гэтага дапушчальная асінхронная каардынацыя, скажыце пра гэта адкрыта і запішыце прамежкавыя бізнес-станы разам з правіламі згаднення. Ланцуг лакальна зафіксаваных крокаў з кампенсацыяй — законны дызайн; гэта проста не адна атамная транзакцыя ў іншым убранні.

Спраектуйце паўтор да першага збою

Кліент можа страціць адказ пасля таго, як аперацыя зафіксаваная, таму выклікальнік не можа лічыць тайм-аўт адмовай. Захоўвайце ўстойлівую ідэнтычнасць запыту і выкарыстоўвайце вынік сэрвісу або механізм ідэмпатэнтнасці перад паўторам змены, інакш паўтор становіцца другім запісам.

Аўтаматычныя зваротныя выклікі транзакцый таксама могуць выконвацца больш за адзін раз пасля паўторнага перарывання, што робіць іх дрэнным месцам для незваротных знешніх эфектаў. Трымайце іх па-за зваротным выклікам, калі працоўны працэс не вызначае для іх яўны бяспечны пратакол. Тая ж асцярога датычыцца ўсяго, што каштуе грошай або адпраўляе паведамленне. Двайное спісанне — куды цяжэйшая размова, чым двайны радок журнала.

Прыёмка павінна прайграць чатыры сцэнарыі: два кліенты, якія спаборнічаюць за адзін радок, перарыванне, якое сэрвіс называе паўторным, фіксацыя, адказ на якую ніколі не прыходзіць, і страта рэгіёна або сувязі паміж імі. Запішыце зафіксаваны бізнес-вынік і нявырашаныя станы побач з дызайнам маршрутызацыі, каб ніхто не прыняў сетку за кампанент, які дае гарантыю.