Shopify viis laovaru reserveerimise MySQL-i

Mida see video hõlmab

• Vana Redise koguse-loenduri mudel käsitles samaaegsust, kuid reservatsiooni puhastamine ja MySQL-i pearaamatu uuendamine ei saanud jagada ühtset lokaalset atomaarset tehingut.
• Asendus kasutab ühte rida iga saadaoleva ühiku kohta hoidlas, mis on piiratud 1000 ühikuga iga toote/asukoha kombinatsiooni kohta. Tühi hoidla võib käivitada reaalse varude täiendamise, kus samaaegsed päringud ootavad varude täiendamise luku taga.
• Komposiitne primaarvõti on (shop_id, inventory_item_id, inventory_group_id, id). Shopify vähendas oma prototüübis luku üldkulusid ja kasutas READ COMMITTED-i, et vältida lünkade lukke, mis blokeerisid varude täiendamist.
• Reserveerimine kustutab hoidla read enne reserveerimiskirjete sisestamist. Tehingu kinnitamine vabastab andmebaasilukud, samal ajal kui salvestatud hoidmine püsib üle makse; edukas makse nõuab pearaamatut ja eemaldab reserveeringu hilisemas atomaarses tehingus.
• MySQL-i dokumendid kirjeldavad SKIP LOCKED-i kui ebajärjekindlat vaadet, mis jätab lukustatud read välja. See ei loo täielikku laoseisu ega õiglast pööramist, kehtib ainult rea taseme lukkudele ja on ebaturvaline lausepõhiseks replikatsiooniks.
• Allika näide sisaldab expires_at-i, kuid Shopify ei dokumenteeri MySQL-i aegumise-puhastamise algoritmi. Video väljalaske/aegumise haru on selgitav elutsükli nõue.
• Ühenduse hoidmise aeg teises ostukorvi koodis oli viimane läbilaskevõime kitsaskoht. Shopify kirjutas varjatult mõlemasse süsteemi, võrdles tulemusi ja lülitas järk-järgult ümber Redise varukatkestiga.

Tõlgitud transkriptsioon

Tõlgitud ingliskeelsest originaaljutustusest. Saadaolevat heli ja subtiitreid kontrollib YouTube.

Miks viia reserveeringud MySQL-i?

0:00 Ostukorv vajab Redisi, et püsida kiire. Shopify viis laovarude reserveerimised MySQL-i, kasutades ühte rida ühiku kohta piiratud hoidlas. Miks valida MySQL? Kuidas lukke ohutult vahele jätta? See on The Daily Diff, kulisside taga. Ja miks kiired päringud ikka piirini jõudsid? Shopify on kaubandusplatvorm veebis ja isiklikult müümiseks. Redis on mälusisene andmesalvestussüsteem.

0:21 MySQL on relatsiooniline andmebaas ja Shopify hoidis oma laovaru pearaamatut juba seal. Reserveering hoiab lühidalt laovaru, kuni ostja maksab.

Miks oli kaks poodi riskantne?

0:29 Nende Redise mudel vähendas toote loendurit. Tasutud tellimuse nõudmine tähendas MySQL-i pearaamatu uuendamist ja Redise puhastamist. Need eraldi kirjutamised võisid jätta laovaru kaks korda müüdud või kättesaamatuks, kui see peaks olema müüdav. Vana mudelil puudus ka asukohateadlikkus. Asendus peab valima laovaru kusagilt, mis suudab tellimust täita. Valel kontinendil asuv ladu teeb suurepärase andmebaasikirje ja kohutava tarne lubaduse. Varasemad MySQL-i katsed kasutasid koguse rida, nii et konkureerivad ostukorvid ootasid järjekorras sama

Mis saab lukustatavaks ühikuks?

0:56 luku taga. Mõelge sametköie peale ümber tabeli lahtri. Rohkemate töötajate lisamine pikendab lihtsalt järjekorda. Shopify muutis lukustatavat objekti. Iga saadaolev ühik saab oma rea. Lukustav lugemine jätab vahele ühikud, mida teine tehing hoiab, ja valib teised sobivad ühikud. Erinevad töötajad saavad omandada erinevaid ridu, samas kui kuum loendur püsib neile teelt eemal.

Mis juhtub, kui hoidla tühjeneb?

1:15 See hoidla on piiratud tuhande reaga iga toote ja asukoha kohta. Varude täiendamine toimub pearaamatust. Kui see tühjeneb, täiendab reserveerimise rada seda kohapeal, konkureerivate päringutega ootamas varude täiendamise luku taga. Tühi hoidla ei tähenda tühja ladu. Reserveerimine kustutab valitud hoidla read, seejärel sisestab reserveerimiskirjed ühes tehingus. Kinnitamine vabastab andmebaasi lukud.

1:35 Tagasivõtmine tühistab muudatused. Reserveering säilib makse töötlemise ajal salvestatud olekuna. Edukalt tasutud makse nõuab pearaamatut ja eemaldab reserveeringu atomaarselt. Andmebaasi lukud ei pea kunagi maksevormi jälgima. Nende komposiitne primaarvõti algab poe, toote, grupi, seejärel ühiku identiteediga. Otsingu sobitamine vähendas nende prototüübis indeksi lukustamist. Nad kasutavad ka lugemiseks kinnitatud tehingut, et vältida lünkade lukke, mis blokeerisid hoidla

1:57 täiendamist, ja järjepidevat tabeli järjestust, et vältida tsüklilisi ooteid. Avaldatud näide salvestab aegumisaja. Mahajäetud maksed vajavad lõpuks laovaru vabastamist, muidu muutub ostukorv maaomanikuks. Shopify postitus jätab selle puhastamise algoritmi täpsustamata, nii et see diagramm näitab elutsükli nõuet. Siin on konks.

Mida SKIP LOCKED välja jätab?

2:14 SKIP LOCKED välistab lukustatud read, nii et juhend nimetab selle tulemust ebajärjekindlaks vaateks. See ei paku täielikku laoseisu ega õiglast pööramist. Hoidke kättesaadavuse otsus ja täiendamise reeglid selle ümber.

Kus oli tegelik piir?

2:26 Ja see piir? Muu ostukorvi kood hoidis andmebaasi ühendusi liiga kaua. Shopify märkis helistajad ja mõõtis ühenduse hoidmise aega, seejärel puhastas ostukorvi tee ja vaatas üle lõimede samaaegsuse. Kiired päringud võivad ikka järjekorras väljaspool päringut oodata.

Miks ma seda disaini kasutaksin?

2:38 Nad kirjutasid varjatult mõlemasse süsteemi, kus Redis oli autoriteetne, võrdlesid tulemusi, seejärel lülitasid järk-järgult ümber katkestuskoodiga. Minu otsus on SHIP IT. Ma kasutaksin jagatud tehingupiiri ja seda tagasipööratavat käivitust, kogu ostukorvi tee instrumenteerimisega. Kas teil on selle kohta küsimusi? Pange see kommentaaridesse. Ja see on tänane vahe.

2:54 Mina olen Niko Axrisist. Ühendage vastutustundlikult.

Allikad

1. We replaced Redis with MySQL for inventory reservations—and it scaledShopify Engineering — Emilie Noel
2. Simplified reservation SQL embedded in Shopify's articleShopify Engineering / CourtneySymons on GitHub Gist
3. MySQL 8.0 — Locking ReadsOracle / MySQL Reference Manual
4. MySQL 8.0 — Transaction Isolation LevelsOracle / MySQL Reference Manual
5. What Is Shopify and How Does It Work?Shopify
6. Redis quick startsRedis documentation
7. What is MySQL?Oracle / MySQL Reference Manual