+− THE DAILY DIFFdev & AI news
SHIP IT

Shopify перанесла рэзервацыі інвентара ў MySQL

Shopify перанесла сваю сістэму рэзервацыі інвентара з Redis у базу дадзеных MySQL, якая ўжо ўтрымлівала кнігу інвентара.

Shopify перанесла сваю сістэму рэзервацыі інвентара з Redis у базу дадзеных MySQL, якая ўжо ўтрымлівала кнігу інвентара. Абмежаваны пул асобна блакіруемых радкоў адзінак дазваляе адначасовым афармленням заказаў выкарыстоўваць SKIP LOCKED для выбару розных прыдатных адзінак. Дызайн таксама залежыць ад межаў транзакцый, кампаноўкі першаснага ключа, правілаў папаўнення і назірання за часам утрымання злучэння падчас афармлення заказа.

Чытаць пісьмовае выданне (англійская) ↗

Што ахоплівае гэта відэа

  • Старая мадэль лічыльніка колькасці Redis апрацоўвала паралельнасць, але ачыстка рэзервацыі і абнаўленне кнігі MySQL не маглі выкарыстоўваць адну лакальную атамную транзакцыю.
  • Замена выкарыстоўвае адзін радок на даступную адзінку ў пуле, абмежаваным 1000 на камбінацыю тавару/месцазнаходжання. Пусты пул можа выклікаць убудаванае папаўненне з адначасовымі запытамі, якія чакаюць за блакіроўкай папаўнення.
  • Кампазітны першасны ключ: (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 Адмена адмяняе змены. Рэзервацыя захоўваецца падчас апрацоўкі плацяжу як захаваны стан. Паспяховая аплата пацвярджае кнігу і атамна выдаляе рэзервацыю. Блакіроўкам базы дадзеных ніколі не трэба кантраляваць форму аплаты. Іх кампазітны першасны ключ пачынаецца з крамы, тавару, групы, затым ідэнтычнасці адзінкі. Супадзенне пошуку знізіла блакіроўку індэкса ў іх прататыпе. Яны таксама выкарыстоўваюць READ COMMITTED, каб пазбегнуць блакіровак прамежкаў, якія блакіравалі

1:57 папаўненне пула, і паслядоўны парадак табліц для прадухілення цыклічных чаканняў. Апублікаваны прыклад запісвае час заканчэння тэрміну дзеяння. Пакінутыя плацяжы патрабуюць канчатковага вызвалення запасаў, інакш кошык становіцца арэндадаўцам. Паведамленне Shopify пакідае алгарытм ачысткі неўдакладненым, таму гэтая дыяграма паказвае патрабаванне жыццёвага цыкла. Вось у чым загвоздка.

Што прапускае SKIP LOCKED?

2:14 SKIP LOCKED выключае заблакіраваныя радкі, таму кіраўніцтва называе яго вынік непаслядоўным праглядам. Ён не забяспечвае ні поўнага падліку запасаў, ні справядлівага размеркавання чэрг. Захоўвайце рашэнне аб даступнасці і правілы папаўнення вакол яго.

Дзе была сапраўдная мяжа?

2:26 А тая мяжа? Іншы код афармлення заказу занадта доўга ўтрымліваў злучэнні з базай дадзеных. Shopify пазначала выклікальнікаў і вымярала час утрымання злучэння, затым ачысціла шлях афармлення заказу і перагледзела паралельнасць патокаў. Хуткія запыты ўсё яшчэ могуць станавіцца ў чаргу за межамі запыту.

Чаму я павінен пастаўляць гэты дызайн?

2:38 Яны цень-запісвалі абедзве сістэмы з аўтарытэтным Redis, параўноўвалі вынікі, затым паступова пераключаліся з выключальнікам аварыйнага адключэння. Мой вердыкт - SHIP IT. Я б адправіў агульную мяжу транзакцый і той адкатваемы разгортванне, з усім інструментаваным шляхам афармлення заказу. Ёсць пытанне наконт гэтага? Пакладзіце яго ў каментарыі. І гэта розніца на сёння.

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

Звязаныя відэа