Shopify pārcēla krājumu rezervācijas uz MySQL
Shopify pārcēla savu krājumu rezervācijas sistēmu no Redis uz MySQL datubāzi, kurā jau atradās krājumu virsgrāmata.
Shopify pārcēla savu krājumu rezervācijas sistēmu no Redis uz MySQL datubāzi, kurā jau atradās krājumu virsgrāmata. Ierobežots individuāli bloķējamu vienību rindu kopums ļauj vienlaicīgām norēķinu operācijām izmantot SKIP LOCKED, lai izvēlētos dažādas piemērotas vienības. Dizains ir atkarīgs arī no darījumu robežām, primārās atslēgas izkārtojuma, krājumu papildināšanas noteikumiem un savienojuma uzturēšanas laika novērošanas norēķinu laikā.
Lasiet rakstisko izdevumu (angļu valodā) ↗
Ko aptver šis video
- Vecais Redis daudzuma skaitītāja modelis apstrādāja paralēlismu, taču rezervāciju tīrīšana un MySQL virsgrāmatas atjaunināšana nevarēja dalīties vienā vietējā atomiskā darījumā.
- Aizstājējs izmanto vienu rindu katrai pieejamai vienībai kopumā, kas ierobežots līdz 1000 vienībām katrai preces/atrašanās vietas kombinācijai. Tukšs kopums var aktivizēt papildināšanu tieši, ar vienlaicīgiem pieprasījumiem, kas gaida aiz papildināšanas bloķētāja.
- Saliktā primārā atslēga ir (shop_id, inventory_item_id, inventory_group_id, id). Shopify samazināja bloķēšanas pieskaitāmās izmaksas savā prototipā un izmantoja READ COMMITTED, lai izvairītos no spraugu bloķētājiem, kas bloķēja papildināšanu.
- Rezervācijas dzēš kopuma rindas pirms rezervācijas ierakstu ievietošanas. Apstiprināšana atbrīvo datubāzes bloķētājus, kamēr saglabātais aizturējums pastāv visā maksājuma laikā; veiksmīgs maksājums pieprasa virsgrāmatu un noņem rezervāciju vēlākā atomiskā darījumā.
- MySQL dokumentācija apraksta SKIP LOCKED kā nekonsekventu skatu, kas izlaiž bloķētās rindas. Tas nenodrošina pilnīgu krājumu uzskaiti vai taisnīgu kārtas ņemšanu, attiecas tikai uz rindu līmeņa bloķētājiem un ir nedrošs uz paziņojumiem balstītai replikācijai.
- Avota piemērā ir iekļauts expires_at, taču Shopify nedokumentē MySQL derīguma termiņa beigu tīrīšanas algoritmu. Video atbrīvošanas/derīguma termiņa beigu atzars ir skaidrojoša dzīves cikla prasība.
- Savienojuma uzturēšanas laiks citā norēķinu kodā bija pēdējais caurlaidības vājais punkts. Shopify "ēnu rakstīja" abas sistēmas, salīdzināja rezultātus un pakāpeniski pārslēdzās ar Redis atjaunošanas slēdža atgriešanos.
Tulkotais transkripts
Tulkojums no oriģinālā angļu stāstījuma. Pieejamais audio un subtitri tiek kontrolēti no YouTube.
Kāpēc pārcelt rezervācijas uz MySQL?
0:00 Norēķiniem ir nepieciešams Redis, lai tie paliktu ātri. Shopify pārcēla krājumu rezervācijas uz MySQL, izmantojot vienu rindu katrai vienībai ierobežotā kopumā. Kāpēc izvēlēties MySQL? Kā droši izlaist bloķētājus? Šis ir The Daily Diff, aiz kulisēm. Un kāpēc ātri vaicājumi joprojām sasniedza griestus? Shopify ir tirdzniecības platforma pārdošanai tiešsaistē un klātienē. Redis ir atmiņā balstīta datu krātuve.
0:21 MySQL ir relāciju datubāze, un Shopify jau glabāja savu krājumu virsgrāmatu tur. Rezervācija īslaicīgi aiztur krājumus, kamēr pircējs maksā.
Kāpēc divi veikali bija riskanti?
0:29 Viņu Redis modelis samazināja preces skaitītāju. Apmaksāta pasūtījuma pieprasīšana nozīmēja MySQL virsgrāmatas atjaunināšanu un Redis tīrīšanu. Šie atsevišķie ieraksti varēja atstāt krājumus pārdotus divreiz vai nepieejamus, kad tiem vajadzētu būt pārdodamiem. Vecajam modelim trūka arī atrašanās vietas apzināšanās. Aizstājējam jāizvēlas krājumi no vietas, kas var izpildīt pasūtījumu. Noliktava nepareizajā kontinentā ir lielisks datubāzes ieraksts un briesmīgs piegādes solījums. Agrākie MySQL mēģinājumi izmantoja daudzuma rindu, tāpēc konkurējošie norēķini stāvēja rindā pie tā paša
Kas kļūst par bloķējamo vienību?
0:56 bloķētāja. Iedomājieties samta virvi ap izklājlapas šūnu. Vairāku darbinieku pievienošana tikai pagarina rindu. Shopify mainīja bloķējamo objektu. Katrs pieejamais vienums saņem savu rindu. Bloķējoša lasīšana izlaiž vienības, ko tur cita darbība, un atlasa citas piemērotas vienības. Dažādi darbinieki var iegūt dažādas rindas, kamēr karstais skaitītājs paliek ārpus viņu ceļa.
Kas notiek, kad kopums iztukšojas?
1:15 Šis kopums ir ierobežots ar tūkstoš rindām katrai precei un atrašanās vietai. Papildināšana tiek veikta no virsgrāmatas. Ja tas iztukšojas, rezerves ceļš papildina tieši, ar konkurējošiem pieprasījumiem, kas gaida aiz papildināšanas bloķētāja. Tukšs kopums nenozīmē tukšu noliktavu. Rezervācija dzēš atlasītās kopuma rindas, pēc tam ievieto rezervācijas ierakstus darījumā. Apstiprināšana atbrīvo datubāzes bloķētājus.
1:35 Atjaunošana atceļ izmaiņas. Rezervācija pārdzīvo maksājuma apstrādi kā saglabātu stāvokli. Veiksmīgs maksājums pieprasa virsgrāmatu un atomiski noņem rezervāciju. Datubāzes bloķētājiem nekad nav jāuzrauga maksājuma forma. Viņu saliktā primārā atslēga sākas ar veikalu, preci, grupu, pēc tam vienības identitāti. Meklēšanas saskaņošana samazināja indeksu bloķēšanu viņu prototipā. Viņi arī izmanto lasīšanas apstiprinājumu, lai izvairītos no spraugu bloķētājiem, kas bloķēja kopuma
1:57 papildināšanu, un konsekventu tabulas secību, lai novērstu apļveida gaidīšanu. Publicētajā piemērā ir ierakstīts derīguma termiņš. Pamestiem maksājumiem galu galā ir jāatbrīvo krājumi, vai arī iepirkumu grozs kļūst par īpašnieku. Shopify ieraksts atstāj šo tīrīšanas algoritmu nenoteiktu, tāpēc šī diagramma parāda dzīves cikla prasības. Te ir āķis.
Ko SKIP LOCKED atstāj ārpusē?
2:14 Skip locked izslēdz bloķētās rindas, tāpēc rokasgrāmata tās rezultātu sauc par nekonsekventu skatu. Tas nenodrošina ne pilnīgu krājumu uzskaiti, ne taisnīgu kārtas ņemšanu. Saglabājiet pieejamības lēmumu un papildināšanas noteikumus ap to.
Kur bija patiesais griests?
2:26 Un tie griesti? Cits norēķinu kods turēja datubāzes savienojumus pārāk ilgi. Shopify atzīmēja zvanītājus un mērīja savienojuma uzturēšanas laiku, pēc tam iztīrīja norēķinu ceļu un pārskatīja pavedienu paralēlismu. Ātri vaicājumi joprojām var stāvēt rindā ārpus vaicājuma.
Kāpēc es nosūtītu šo dizainu?
2:38 Viņi ēnu rakstīja abas sistēmas ar Redis kā autoritatīvu, salīdzināja rezultātus, pēc tam pakāpeniski pārslēdzās ar avārijas slēdzi. Mans spriedums ir sūtīt to. Es nosūtītu kopīgo darījumu robežu un to atceļamo ieviešanu, ar visu norēķinu ceļu instrumentētu. Vai jums ir jautājums par to? Ierakstiet to komentāros. Un tas ir šodienas atšķirība.
2:54 Esmu Niko no Axrisi. Apvienojiet atbildīgi.
Avoti
- We replaced Redis with MySQL for inventory reservations—and it scaledShopify Engineering — Emilie Noel
- Simplified reservation SQL embedded in Shopify's articleShopify Engineering / CourtneySymons on GitHub Gist
- MySQL 8.0 — Locking ReadsOracle / MySQL Reference Manual
- MySQL 8.0 — Transaction Isolation LevelsOracle / MySQL Reference Manual
- What Is Shopify and How Does It Work?Shopify
- Redis quick startsRedis documentation
- What is MySQL?Oracle / MySQL Reference Manual



