Shopify flyttet varebeholdningsreservasjoner til MySQL

Hva denne videoen dekker

• Den gamle Redis-kvantitets-tellermodellen håndterte samtidighet, men reservasjonsopprydding og MySQL-registeroppdateringen kunne ikke dele en enkelt lokal atomisk transaksjon.
• Erstatningen bruker én rad per tilgjengelig enhet i et basseng begrenset til 1000 per vare-/lokasjonskombinasjon. Et tomt basseng kan utløse innebygd påfylling med samtidige forespørsler som venter bak en påfyllingslås.
• Den sammensatte primærnøkkelen er (shop_id, inventory_item_id, inventory_group_id, id). Shopify reduserte låsekostnadene i prototypen og brukte READ COMMITTED for å unngå gaptabeller som blokkerte påfylling.
• Reserver sletter bassengrader før reservasjonsposter settes inn. Forpliktelsen frigjør databaselåser mens den lagrede holden vedvarer over betaling; vellykket betaling krever registeret og fjerner reservasjonen i en senere atomisk transaksjon.
• MySQL dokumenterer SKIP LOCKED som en inkonsekvent visning som utelater låste rader. Den etablerer verken en komplett beholdning eller rettferdig turfordeling, gjelder bare for radnivålåser og er usikker for uttalelsesbasert replikering.
• Kildeeksemplet inkluderer expires_at, men Shopify dokumenterer ikke MySQLs utløps-oppryddingsalgoritme. Videoens utgivelses-/utløpsgren er et forklarende livssykluskrav.
• Tilkoblingstid i annen utsjekkingskode var den siste flaskehalsen for gjennomstrømning. Shopify skyggeskrev begge systemene, sammenlignet resultater og byttet gradvis med en Redis kill-switch tilbakefall.

Oversatt transkripsjon

Oversatt fra den originale engelske fortellingen. Tilgjengelig lyd og undertekster kontrolleres av YouTube.

Hvorfor flytte reservasjoner til MySQL?

0:00 En utsjekk trenger Redis for å holde seg rask. Shopify flyttet varebeholdningsreservasjoner til MySQL ved å bruke én rad per enhet i et avgrenset basseng. Hvorfor velge MySQL? Hvordan hopper du trygt over låser? Dette er The Daily Diff, under panseret. Og hvorfor traff raske spørringer fortsatt et tak? Shopify er en handelsplattform for salg online og personlig. Redis er et minnebasert datalager.

0:21 MySQL er en relasjonsdatabase, og Shopify hadde allerede varebeholdningsregisteret sitt der. En reservasjon holder kortvarig beholdning mens en kjøper betaler.

Hvorfor var to butikker risikable?

0:29 Deres Redis-modell reduserte en vare-teller. Å kreve en betalt bestilling betydde å oppdatere MySQL-registeret og rydde opp i Redis. Disse separate skriveoperasjonene kunne føre til at lager ble solgt to ganger eller utilgjengelig når det skulle være salgbart. Den gamle modellen manglet også lokasjonsbevissthet. Erstatningen må velge lager fra et sted som kan oppfylle ordren. Et lager på feil kontinent gir en utmerket databaseoppføring og et forferdelig leveringsløfte. Tidligere MySQL-forsøk brukte en kvantitetsrad, så konkurrerende utsjekk sto i kø ved den

Hva blir den låsbare enheten?

0:56 samme låsen. Tenk på et fløyelsreip rundt en regnearkcelle. Å legge til flere arbeidere forlenger bare køen. Shopify endret det låsbare objektet. Hver tilgjengelige enhet får sin egen rad. En låsende lesing hopper over enheter en annen transaksjon holder og velger andre kvalifiserte enheter. Ulike arbeidere kan anskaffe forskjellige rader, mens den varme telleren holder seg unna veien deres.

Hva skjer når bassenget tømmes?

1:15 Dette bassenget er begrenset til tusen rader per vare og lokasjon. Påfylling trekker fra registeret. Hvis det tømmes, fyller reserve- banen på linje, med konkurrerende forespørsler som venter bak en påfyllingslås. Tomt basseng betyr ikke tomt lager. Reserve sletter valgte bassengrader, og setter deretter inn reservasjonsposter i en transaksjon. Commit frigjør databaselåsene.

1:35 Rollback angrer endringene. Reservasjonen overlever betalingsbehandling som lagret tilstand. Vellykket betaling krever registeret og fjerner reservasjonen atomisk. Databaselåser trenger aldri å passe på betalingsskjemaet. Deres sammensatte primærnøkkel starter med butikk, vare, gruppe, deretter enhetsidentitet. Å matche oppslaget reduserte indekslåsing i prototypen deres. De bruker også lesing forpliktet til å unngå gaptabeller som blokkerte basseng-

1:57 påfylling, og en konsistent tabellrekkefølge for å forhindre sirkulære venter. Det publiserte eksemplet registrerer et utløpstidspunkt. Forlatte betalinger trenger til slutt at lager frigjøres, ellers blir handlekurven en utleier. Shopifys innlegg lar denne oppryddingsalgoritmen være uspesifisert, så dette diagrammet viser livssykluskravet. Her er haken.

Hva utelater SKIP LOCKED?

2:14 Skip locked utelukker låste rader, så manualen kaller resultatet en inkonsekvent visning. Den gir verken en komplett beholdning eller rettferdig turfordeling. Behold tilgjengelighetsbeslutningen og påfyllingsreglene rundt den.

Hvor var det virkelige taket?

2:26 Og det taket? Annen utsjekkskode holdt databasetilkoblinger for lenge. Shopify merket anropere og målte tilkoblingstid, ryddet deretter opp i utsjekksbanen og reviderte trådsamtidighet. Raske spørringer kan fortsatt stå i kø utenfor spørringen.

Hvorfor skulle jeg SHIP IT dette designet?

2:38 De skyggeskrev begge systemene med Redis autoritativt, sammenlignet resultater, og byttet deretter gradvis med en kill switch. Min dom er SHIP IT. Jeg ville SHIP IT den delte transaksjonsgrensen og den tilbakekallbare utrullingen, med hele utsjekksbanen instrumentert. Har du et spørsmål om dette? Legg det i kommentarene. Og det er differansen for i dag.

2:54 Jeg er Niko fra Axrisi. Slå sammen ansvarlig.

Kilder

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