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

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

• Стари 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-а на MySQL са прекидачем за враћање.

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

Преведено са оригиналне енглеске нарације. Доступни аудио и титлови контролисани су од стране 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 Поништавање поништава промене. Резервација преживљава обраду плаћања као сачувано стање. Успешно плаћање потражује књигу и атомски уклања резервацију. Закључавања базе података никада не морају да надгледају формулар за плаћање. Њихов композитни примарни кључ почиње са продавницом, ставком, групом, затим идентитетом јединице. Поклапање претраге смањило је закључавање индекса у њиховом прототипу. Такође користе "read committed" да би избегли закључавања празнина која су блокирала допуну

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

Шта SKIP LOCKED изоставља?

2:14 Skip locked искључује закључане редове, па упутство његов резултат назива недоследним погледом. Не пружа ни потпун број залиха ни фер редослед. Држите одлуку о доступности и правила допуне око ње.

Где је био прави плафон?

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

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

2:38 Они су истовремено писали у оба система са Redis-ом као ауторитативним, упоредили резултате, а затим постепено прешли са прекидачем за искључивање. Моја пресуда је SHIP IT. Испоручио бих заједничку границу трансакција и ту повратну примену, са инструментацијом целог пута наплате. Имате питање о овоме? Поставите га у коментарима. И то је The Daily Diff за данас.

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