+− THE DAILY DIFFdev & AI news
SHIP IT

Shopify ги премести резервациите на залихи во MySQL

Shopify го премести својот систем за резервација на залихи од Redis во MySQL базата на податоци што веќе го содржеше евиденцијата за залихи.

Shopify го премести својот систем за резервација на залихи од Redis во MySQL базата на податоци што веќе го содржеше евиденцијата за залихи. Ограничен фонд од поединечно заклучувачки редови на единици им овозможува на истовремените наплати да користат SKIP LOCKED за да изберат различни соодветни единици. Дизајнот зависи и од границите на трансакциите, распоредот на примарниот клуч, правилата за надополнување и набљудувањето на времето на задржување на врската низ наплатата.

Прочитајте го пишаното издание (англиски) ↗

Што покрива ова видео

  • Стариот модел на Redis со бројач на количини се справуваше со истовременост, но чистењето на резервациите и ажурирањето на MySQL евиденцијата не можеа да споделат една локална атомска трансакција.
  • Замената користи еден ред по достапна единица во фонд ограничен на 1.000 по комбинација на артикал/локација. Празен фонд може да предизвика внатрешно надополнување со истовремени барања кои чекаат зад брава за надополнување.
  • Композитниот примарен клуч е (shop_id, inventory_item_id, inventory_group_id, id). Shopify ја намали надземната брава во својот прототип и користеше READ COMMITTED за да избегне празнини брави кои го блокираа надополнувањето.
  • Резервираните бришења ги отстрануваат редовите од фондот пред да вметнат записи за резервација. Потврдувањето ги ослободува бравите на базата на податоци додека зачуваната задршка опстојува низ плаќањето; успешното плаќање ја презема евиденцијата и ја отстранува резервацијата во подоцнежна атомска трансакција.
  • MySQL го документира SKIP LOCKED како недоследен приказ кој ги испушта заклучените редови. Тоа не воспоставува целосен број на залихи или правично менување, се применува само на брави на ниво на ред и е небезбедно за репликација базирана на изјави.
  • Изворниот пример вклучува expires_at, но Shopify не го документира алгоритмот за чистење на истекот на MySQL. Гранката за ослободување/истекување на видеото е објаснувачки услов за животен циклус.
  • Времето на задржување на врската во другиот код за наплата беше последниот тесно грло на пропусната моќ. Shopify ги пишуваше и двата системи, ги спореди резултатите и постепено се префрли со Redis прекинувач за исклучување како резервна опција.

Преведен транскрипт

Преведено од оригиналната англиска нарација. Достапното аудио и наслови се контролирани од YouTube.

Зошто да ги преместите резервациите во MySQL?

0:00 За наплата е потребно Redis за да остане брз. Shopify ги премести резервациите на залихи во MySQL користејќи еден ред по единица во ограничен фонд. Зошто да изберете MySQL? Како безбедно да ги прескокнете бравите? Ова е The Daily Diff, под хауба. И зошто брзите барања сепак удрија во плафон? Shopify е комерцијална платформа за продажба онлајн и лично. Redis е продавница за податоци во меморија.

0:21 MySQL е релациона база на податоци, а Shopify веќе го чуваше својот инвентар таму. Резервацијата кратко време ја задржува стоката додека купувачот плаќа.

Зошто две продавници беа ризични?

0:29 Нивниот модел на Redis го намалуваше бројачот на ставки. Преземањето на платена нарачка значеше ажурирање на MySQL евиденцијата и чистење на Redis. Тие одделни записи можеа да ја остават стоката продадена двапати или недостапна кога треба да биде продажна. Стариот модел исто така немаше свест за локација. Замената мора да избере залиха од некаде што може да ја исполни нарачката. Склад на погрешен континент прави одличен запис во базата на податоци и ужасно ветување за испорака. Претходните обиди на MySQL користеа ред со количини, така што конкурентните наплати се редеа на

Што станува единица за заклучување?

0:56 истата брава. Размислете за кадифено јаже околу ќелија на табела. Додавањето повеќе работници само ја продолжува редицата. Shopify го смени објектот што може да се заклучи. Секоја достапна единица добива свој ред. Читањето со заклучување ги прескокнува единиците што ги држи друга трансакција и избира други соодветни единици. Различни работници можат да стекнат различни редови, додека жешкиот бројач останува надвор од нивниот пат.

Што се случува кога фондот ќе се испразни?

1:15 Тој фонд е ограничен на илјада редови по ставка и локација. Надополнувањето се врши од евиденцијата. Ако се испразни, резервната патека се надополнува внатрешно, со конкурентни барања кои чекаат зад брава за надополнување. Празен фонд не значи празен склад. Резервацијата ги брише избраните редови од фондот, а потоа вметнува записи за резервација во трансакција. Потврдата ги ослободува бравите на базата на податоци.

1:35 Враќањето наназад ги поништува промените. Резервацијата преживува обработка на плаќање како зачувана состојба. Успешното плаќање ја презема евиденцијата и атомски ја отстранува резервацијата. Бравите на базата на податоци никогаш не треба да го надгледуваат формуларот за плаќање. Нивниот композитен примарен клуч започнува со продавница, ставка, група, потоа идентитет на единица. Совпаѓањето на пребарувањето го намали заклучувањето на индексот во нивниот прототип. Тие исто така користат читање посветено за да избегнат брави на празнини кои го блокираа надополнувањето

1:57 на фондот, и доследен редослед на табела за да спречат кружни чекања. Објавениот пример евидентира време на истекување. Напуштените плаќања треба да се ослободат од залиха на крајот, или кошничката за купување станува сопственик. Објавата на Shopify го остава тој алгоритам за чистење неодреден, така што овој дијаграм го покажува барањето за животен циклус. Еве го уловот.

Што испушта SKIP LOCKED?

2:14 Skip locked исклучува заклучени редови, така што прирачникот го нарекува неговиот резултат недоследен приказ. Тоа не обезбедува ниту целосен број на залихи ниту правично менување. Задржете ја одлуката за достапност и правилата за надополнување околу неа.

Каде беше вистинскиот плафон?

2:26 А тој плафон? Друг код за наплата предолго ги држеше врските со базата на податоци. Shopify ги означи повикувачите и го измери времето на задржување на врската, потоа го исчисти патот за наплата и повторно ја разгледа истовременоста на нишките. Брзите барања сè уште можат да чекаат надвор од барањето.

Зошто би го испорачал овој дизајн?

2:38 Тие ги пишуваа и двата системи со Redis како авторитативен, ги споредија резултатите, а потоа постепено се префрлија со прекинувач за убивање. Мојата пресуда е испратете го. Би ја испратил споделената граница на трансакции и тоа повратно распоредување, со целиот пат за наплата инструментализиран. Имате прашање за ова? Ставете го во коментарите. И тоа е разликата за денес.

2:54 Јас сум Нико од Axrisi. Спојувајте одговорно.

Извори

  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

Поврзани видеа

under-the-hood · mk · 24 сеп. 2026 г.

SAML, под хаубата: потписот во внатрешноста на писмото

SAML ве најавува во речиси секоја работна апликација, а неговиот потпис живее во XML-от што го потпишува. Под хаубата: танцот за најавување помеѓу апликацијата, прелистувачот и давателот на идентитет,

3:02 ↗