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 Отменянето връща промените. Резервацията оцелява при обработката на плащането като съхранено състояние. Успешното плащане заявява регистъра и премахва резервацията атомарно. Заключванията на базата данни никога не трябва да наблюдават формата за плащане. Техният композитен първичен ключ започва с магазин, артикул, група, след това идентичност на единицата. Съвпадението на търсенето намали заключването на индекси в техния прототип. Те също така използват четене на потвърдени данни, за да избегнат заключванията на пропуски, които блокираха попълването на пула,
1:57 и последователен ред на таблицата, за да предотвратят циклични изчаквания. Публикуваният пример записва време на изтичане. Изоставените плащания се нуждаят от освободена наличност в крайна сметка, или пазарската количка става наемодател. Публикацията на Shopify оставя този алгоритъм за почистване неуточнен, така че тази диаграма показва изискването за жизнен цикъл. Ето уловката.
Какво пропуска SKIP LOCKED?
2:14 Skip locked изключва заключените редове, така че ръководството нарича резултата му непоследователен изглед. Той не предоставя нито пълен брой наличност, нито справедливо редуване. Запазете решението за наличност и правилата за попълване около него.
Къде беше истинският таван?
2:26 А този таван? Друг код за плащане задържаше връзките с базата данни твърде дълго. Shopify маркира обаждащите се и измери времето за задържане на връзката, след което почисти пътя за плащане и преразгледа едновременността на нишките. Бързите заявки все още могат да се наредят на опашка извън заявката.
Защо бих изпратил този дизайн?
2:38 Те паралелно писаха и в двете системи с авторитетен Redis, сравниха резултатите, след което преминаха постепенно с превключвател за аварийно изключване. Моята присъда е „изпрати“. Бих изпратил споделената граница на транзакция и това отказуемо внедряване, с целия път на плащане инструментализиран. Имате ли въпрос относно това? Поставете го в коментарите. И това е разликата за днес.
2:54 Аз съм Нико от Axrisi. Обединявайте отговорно.
Източници
- We replaced Redis with MySQL for inventory reservations—and it scaledShopify Engineering — Emilie Noel
- Simplified reservation SQL embedded in Shopify's articleShopify Engineering / CourtneySymons on GitHub Gist
- MySQL 8.0 — Locking ReadsOracle / MySQL Reference Manual
- MySQL 8.0 — Transaction Isolation LevelsOracle / MySQL Reference Manual
- What Is Shopify and How Does It Work?Shopify
- Redis quick startsRedis documentation
- What is MySQL?Oracle / MySQL Reference Manual



