Shopify færði birgðabókanir í MySQL

Það sem þetta myndband fjallar um

• Gamla Redis magnteljara líkanið annaði samfara notkun, en hreinsun bókunar og uppfærsla á MySQL bókhaldi gátu ekki deilt einni staðbundinni óháðri færslu.
• Í staðinn er notuð ein lína fyrir hverja tiltæka einingu í hópi sem er takmarkaður við 1.000 fyrir hverja vöru/staðsetningarsamsetningu. Tómur hópur getur kveikt á áfyllingu á staðnum þar sem samfara beiðnir bíða á bak við áfyllingarlás.
• Samsetti frumlykillinn er (shop_id, inventory_item_id, inventory_group_id, id). Shopify minnkaði læsingarálag í frumgerð sinni og notaði READ COMMITTED til að forðast bilalæsingar sem stöðvuðu áfyllingu.
• Bókanir eyða hóplínum áður en bókunarfærslur eru settar inn. Skuldsetning losar gagnagrunnslása á meðan haldið varir yfir greiðslu; vel heppnuð greiðsla krefst bókhaldsins og fjarlægir bókunina í síðari sjálfstæðri færslu.
• MySQL skjalfestir SKIP LOCKED sem ósamræmi sem sleppir læstum línum. Það staðfestir hvorki fullkomið birgðahald né sanngjarna röð, á aðeins við um læsingar á línum og er ótryggt fyrir afritun sem byggir á yfirlýsingum.
• Dæmið inniheldur expires_at, en Shopify skjalfestir ekki MySQL fyrninga-hreinsunaralgrímið. Greinin um losun/fyrningu í myndbandinu er skýrandi lífsferilskrafa.
• Tengingartími í öðrum afgreiðslukóða var endanlegur flöskuháls í gegnumstreymi. Shopify skrifaði bæði kerfin í skugga, bar saman niðurstöður og skipti smám saman með Redis "kill-switch" varaleið.

Þýtt afrit

Þýtt úr upprunalegri enskri frásögn. Tiltækt hljóð og textar eru stjórnaðir af YouTube.

Hvers vegna að færa bókanir í MySQL?

0:00 Afgreiðsla þarf Redis til að vera hröð. Shopify færði birgðabókanir í MySQL með einni línu á hverja einingu í takmörkuðum hópi. Hvers vegna að velja MySQL? Hvernig sleppir þú læsingum á öruggan hátt? Þetta er The Daily Diff, undir yfirborðinu. Og hvers vegna náðu hraðar fyrirspurnir samt þaki? Shopify er viðskiptavettvangur til að selja á netinu og í eigin persónu. Redis er gagnageymsla í minni.

0:21 MySQL er sambandsgagnagrunnur og Shopify geymdi birgðabókhald sitt þegar þar. Bókun heldur stuttlega á lager á meðan kaupandi borgar.

Hvers vegna voru tvær verslanir áhættusamar?

0:29 Redis líkanið þeirra fækkaði í vörutalningu. Að heimta greidda pöntun þýddi að uppfæra MySQL bókhaldið og hreinsa Redis. Þessi aðskildu skrif gátu valdið því að lager var seldur tvisvar eða ófáanlegur þegar hann ætti að vera seljanlegur. Gamla líkanið skorti einnig staðsetningarvitund. Skipta þarf um lager frá einhverjum stað sem getur uppfyllt pöntunina. Vöruhús á röngum heimsálfu er frábær gagnagrunnsfærsla og hræðilegt loforð um afhendingu. Fyrri tilraunir með MySQL notuðu magnalínu, svo keppandi afgreiðslur biðu í röð við sama

Hvað verður læsanleg eining?

0:56 lásinn. Hugsaðu þér flauelsreipi utan um töflureit. Að bæta við fleiri starfsmönnum lengir bara biðröðina. Shopify breytti læsanlega hlutnum. Hver tiltæk eining fær sína eigin línu. Læsingarlestur sleppir einingum sem önnur færsla heldur og velur aðrar gjaldgengar einingar. Mismunandi starfsmenn geta eignast mismunandi línur, á meðan heitur teljarinn er ekki fyrir þeim.

Hvað gerist þegar hópurinn tæmist?

1:15 Sá hópur er takmarkaður við þúsund línur á hverja vöru og staðsetningu. Áfylling dregur úr bókhaldinu. Ef hún tæmist, fyllir bókunarleiðin á línu, með keppandi beiðnum sem bíða á bak við áfyllingarlás. Tómur hópur þýðir ekki tómt vöruhús. Bókun eyðir völdum hóplínum, setur síðan bókunarfærslur inn í færslu. Skuldsetning losar gagnagrunnslásana.

1:35 Afturköllun afturkallar breytingarnar. Bókunin lifir greiðsluvinnslu af sem geymt ástand. Vel heppnuð greiðsla heimtar bókhaldið og fjarlægir bókunina sjálfstætt. Gagnagrunnslásar þurfa aldrei að passa greiðsluformið. Samsetti frumlykillinn þeirra byrjar á búð, vöru, hópi, síðan einingarauðkenni. Að passa uppflettingu minnkaði læsingar á vísitölu í frumgerð þeirra. Þeir nota einnig "read committed" til að forðast "gap locks" sem lokuðu áfyllingu á hópi,

1:57 og samræmda töfluröð til að koma í veg fyrir hringlaga bið. Útgefna dæmið skráir fyrningartíma. Yfirgefna greiðslur þurfa að lokum að losa lager, annars verður innkaupakörfan leigusali. Færsla Shopify skilgreinir ekki þetta hreinsunarkerfi, svo þetta skýringarmynd sýnir kröfu um lífsferil. Hér er snúningurinn.

Hvað sleppir SKIP LOCKED?

2:14 Skip locked útilokar læstar línur, svo handbókin kallar niðurstöðu sína ósamræmi útsýni. Það veitir hvorki fullkomið birgðahald né sanngjarna röð. Haltu ákvörðun um framboð og áfyllingarreglur í kringum það.

Hvar var raunverulegt þak?

2:26 Og þetta þak? Annar afgreiðslukóði hélt gagnagrunnstengingum of lengi. Shopify merkti hringjendur og mældi tengingartíma, hreinsaði síðan afgreiðsluleiðina og endurskoðaði samfara þræði. Hraðar fyrirspurnir geta samt beðið utan fyrirspurnarinnar.

Hvers vegna ætti ég að senda þessa hönnun?

2:38 Þeir skrifuðu báðar kerfin í skugga með Redis sem yfirvald, báru saman niðurstöður og skiptu síðan smám saman með rofa til að drepa. Dómur minn er SHIP IT. Ég myndi SHIP IT, sameiginlegu færslumörkin og þessa afturkræfu útfærslu, með allri afgreiðsluleiðinni útfærðri. Ertu með spurningu um þetta? Settu hana í athugasemdirnar. Og það er The Daily Diff í dag.

2:54 Ég er Niko frá Axrisi. Sameinaðu á ábyrgan hátt.

Heimildir

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