Shopify presunul rezervácie zásob do MySQL

Čo toto video pokrýva

• Starý model počítadla množstva v Redis zvládal súbežnosť, ale čistenie rezervácií a aktualizácia knihy v MySQL nemohli zdieľať jednu lokálnu atomickú transakciu.
• Náhrada používa jeden riadok na dostupnú jednotku vo fonde s limitom 1 000 na kombináciu položky a miesta. Prázdny fond môže spustiť okamžité dopĺňanie, pričom súbežné požiadavky čakajú za zámkom dopĺňania.
• Kompozitný primárny kľúč je (shop_id, inventory_item_id, inventory_group_id, id). Shopify znížil réžiu zámkov vo svojom prototype a použil READ COMMITTED, aby sa vyhol zámkom medzier, ktoré blokovali dopĺňanie.
• Rezervácia vymaže riadky fondu pred vložením záznamov rezervácií. Potvrdenie uvoľní zámky databázy, zatiaľ čo uložené podržanie pretrváva počas platby; úspešná platba si nárokuje knihu a odstráni rezerváciu v neskoršej atomickej transakcii.
• MySQL dokumentuje SKIP LOCKED ako nekonzistentný pohľad, ktorý vynecháva uzamknuté riadky. Nezaručuje úplný počet zásob ani spravodlivé striedanie, vzťahuje sa len na zámky na úrovni riadkov a je nebezpečný pre replikáciu založenú na príkazoch.
• Príklad zdroja obsahuje expires_at, ale Shopify nedokumentuje algoritmus čistenia expirácie v MySQL. Vetva uvoľnenia/exspirácie vo videu je vysvetľujúcou požiadavkou životného cyklu.
• Čas udržania spojenia v inom kóde pre platby bol posledným úzkym hrdlom priepustnosti. Shopify zapisoval do oboch systémov (shadow-write), porovnával výsledky a postupne prešiel na nový systém s prepínačom na Redis v prípade zlyhania.

Preložený prepis

Preložené z pôvodného anglického rozprávania. Dostupný zvuk a titulky sú kontrolované službou YouTube.

Prečo presunúť rezervácie do MySQL?

0:00 Pokladňa potrebuje Redis, aby zostala rýchla. Shopify presunul rezervácie zásob do MySQL, pričom použil jeden riadok na jednotku v ohraničenom fonde. Prečo zvoliť MySQL? Ako bezpečne preskočiť zámky? Toto je The Daily Diff, pod kapotou. A prečo rýchle dotazy stále narážali na strop? Shopify je obchodná platforma na predaj online a osobne. Redis je dátové úložisko v pamäti.

0:21 MySQL je relačná databáza a Shopify už tam uchovával svoju knihu zásob. Rezervácia krátkodobo drží zásoby, kým kupujúci zaplatí.

Prečo boli dva sklady riskantné?

0:29 Ich model Redis znižoval počítadlo položiek. Nárokovanie zaplatenej objednávky znamenalo aktualizáciu knihy MySQL a vyčistenie Redis. Tieto samostatné zápisy mohli spôsobiť, že zásoby boli predané dvakrát alebo nedostupné, keď by mali byť predajné. Starému modelu chýbala aj informovanosť o polohe. Náhrada musí vybrať zásoby z miesta, ktoré môže objednávku splniť. Sklad na nesprávnom kontinente je vynikajúci záznam v databáze a strašný sľub doručenia. Predchádzajúce pokusy s MySQL používali riadok množstva, takže konkurenčné platby čakali na ten

Čo sa stane uzamykateľnou jednotkou?

0:56 istý zámok. Predstavte si zamatovú šnúru okolo bunky tabuľky. Pridávanie ďalších pracovníkov len predlžuje front. Shopify zmenil uzamykateľný objekt. Každá dostupná jednotka dostane svoj vlastný riadok. Uzamykacie čítanie preskakuje jednotky, ktoré drží iná transakcia a vyberá iné oprávnené jednotky. Rôzni pracovníci môžu získať rôzne riadky, zatiaľ čo horúce počítadlo im nestojí v ceste.

Čo sa stane, keď sa fond vyprázdni?

1:15 Tento fond je ohraničený na tisíc riadkov na položku a umiestnenie. Dopĺňanie čerpá z knihy. Ak sa vyprázdni, cesta rezervácie dopĺňa okamžite, pričom konkurenčné požiadavky čakajú za zámkom dopĺňania. Prázdny fond neznamená prázdny sklad. Rezervácia vymaže vybrané riadky fondu a potom vloží záznamy rezervácií do transakcie. Potvrdenie uvoľní zámky databázy.

1:35 Zrušenie transakcie vráti zmeny späť. Rezervácia prežije spracovanie platby ako uložený stav. Úspešná platba si nárokuje knihu a atomicky odstráni rezerváciu. Zámky databázy nikdy nemusia dohliadať na platobný formulár. Ich zložený primárny kľúč začína obchodom, položkou, skupinou, potom identitou jednotky. Zladenie vyhľadávania znížilo uzamykanie indexov v ich prototype. Používajú tiež read committed, aby sa vyhli zámkom medzier, ktoré blokovali dopĺňanie fondu,

1:57 a konzistentné poradie tabuliek, aby sa zabránilo kruhovým čakaniam. Publikovaný príklad zaznamenáva čas exspirácie. Opustené platby potrebujú nakoniec uvoľniť zásoby, inak sa nákupný košík stane prenajímateľom. Príspevok Shopify tento algoritmus čistenia nešpecifikuje, takže táto schéma zobrazuje požiadavku životného cyklu. Tu je háčik.

Čo vynecháva SKIP LOCKED?

2:14 Skip locked vylučuje uzamknuté riadky, takže manuál nazýva jeho výsledok nekonzistentným pohľadom. Neposkytuje ani úplný počet zásob, ani spravodlivé striedanie. Udržujte rozhodnutie o dostupnosti a pravidlá dopĺňania okolo neho.

Kde bol skutočný strop?

2:26 A ten strop? Iný kód pre platby držal databázové spojenia príliš dlho. Shopify označil volajúcich a meral čas udržania spojenia, potom vyčistil cestu pre platby a prehodnotil súbežnosť vlákien. Rýchle dotazy sa môžu stále radiť mimo dotazu.

Prečo by som tento dizajn odoslal?

2:38 Oba systémy zapisovali (shadow-write) s autoritatívnym Redisom, porovnali výsledky a potom postupne prešli na nový systém s núdzovým prepínačom. Môj verdikt je SHIP IT. Odoslal by som zdieľanú hranicu transakcií a to roll-backovateľné nasadenie, s celou cestou pre platby instrumentovanou. Máte otázku k tomuto? Napíšte ju do komentárov. A to je dnešný rozdiel.

2:54 Som Niko z Axrisi. Zlučujte zodpovedne.

Zdroje

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