Shopify inventar sifarişlərini MySQL-ə köçürdü

Bu videoda nələr əhatə olunur

• Köhnə Redis kəmiyyət-sayğac modeli eyni zamanda işləməyi idarə edirdi, lakin sifarişin təmizlənməsi və MySQL defterinin yenilənməsi tək bir yerli atomik əməliyyatı paylaşa bilmədi.
• Əvəzedici hər bir məhsul/yer kombinasiyası üçün 1000 ilə məhdudlaşdırılmış hovuzda mövcud hər vahid üçün bir sətirdən istifadə edir. Boş bir hovuz, doldurma kilidinin arxasında gözləyən eyni vaxtda sorğularla sətirdaxili doldurmanı tətikləyə bilər.
• Kompozit ilkin açar (shop_id, inventory_item_id, inventory_group_id, id)-dir. Shopify prototipində kilid yüklənməsini azaltdı və doldurmanı bloklayan boşluq kilidlərindən qaçmaq üçün READ COMMITTED-dən istifadə etdi.
• Sifariş, sifariş qeydlərini daxil etməzdən əvvəl hovuz sətirlərini silir. Təsdiq etmə verilənlər bazası kilidlərini buraxır, saxlanılan tutum ödəniş boyunca davam edir; uğurlu ödəniş defteri tələb edir və sifarişi sonrakı atomik əməliyyatda ləğv edir.
• MySQL SKIP LOCKED-u kilidlənmiş sətirləri istisna edən qeyri-ardıcıl görünüş kimi sənədləşdirir. O, tam fond sayını və ya ədalətli növbələşməni müəyyən etmir, yalnız səviyyəli kilidlərə tətbiq olunur və ifadələrə əsaslanan replikasiya üçün təhlükəlidir.
• Mənbə nümunəsi expires_at-ı ehtiva edir, lakin Shopify MySQL son istifadə təmizləmə alqoritmini sənədləşdirmir. Videonun buraxılış/son istifadə qolu izahlı həyat dövrü tələbidir.
• Digər ödəniş kodunda əlaqənin saxlanma müddəti son nəticədə məhsuldarlıq daralması idi. Shopify hər iki sistemi kölgə-yazdı, nəticələri müqayisə etdi və Redis-in təcili söndürmə keçidi ilə tədricən keçdi.

Tərcümə olunmuş transkript

Orijinal ingilis dilindəki nəqldən tərcümə edilmişdir. Mövcud audio və subtitrlər YouTube tərəfindən idarə olunur.

Niyə sifarişləri MySQL-ə köçürməli?

0:00 Ödəniş Redis-in sürətli qalmasına ehtiyac duyur. Shopify inventar sifarişlərini MySQL-ə bir vahid üçün bir sətirdən istifadə edərək köçürdü məhdud hovuzda. Niyə MySQL-i seçməli? Kilidləri təhlükəsiz şəkildə necə atlatmaq olar? Bu, The Daily Diff, pərdə arxasında. Və niyə sürətli sorğular hələ də tavana dəyirdi? Shopify onlayn və şəxsən satış üçün bir ticarət platformasıdır. Redis yaddaşda məlumat anbarıdır.

0:21 MySQL bir əlaqəli verilənlər bazasıdır və Shopify artıq inventar defterini orada saxlayırdı. Bir sifariş alıcı ödəniş edərkən qısa müddətə ehtiyatı saxlayır.

Niyə iki mağaza riskli idi?

0:29 Onların Redis modeli bir məhsul sayğacını azaldırdı. Ödənilmiş sifarişi tələb etmək MySQL defterini yeniləmək və Redis-i təmizləmək demək idi. Bu ayrı yazılışlar ehtiyatı iki dəfə satılmış və ya satıla bilən olması lazım olduğu halda mövcud olmayan vəziyyətdə qoya bilərdi. Köhnə modeldə yerləşmə məlumatı da yox idi. Əvəzetmə sifarişi yerinə yetirə biləcək bir yerdən ehtiyat seçməlidir. Yanlış qitədəki bir anbar əla bir verilənlər bazası girişi və dəhşətli bir çatdırılma vədi verir. Əvvəlki MySQL cəhdləri bir kəmiyyət sətrindən istifadə edirdi, buna görə də rəqabət aparan ödənişlər eyni kiliddə növbəyə dururdu.

Kilidlənə bilən vahid nə olur?

0:56 Bir cədvəl hücrəsi ətrafındakı məxmər ipi düşünün. Daha çox işçi əlavə etmək sadəcə növbəni uzadır. Shopify kilidlənə bilən obyekti dəyişdi. Hər mövcud vahid öz sətrini alır. Bir kilidləmə oxumaq digər əməliyyatın tutduğu vahidləri atlayır və digər uyğun vahidləri seçir. Fərqli işçilər fərqli sətirləri əldə edə bilərlər, isti sayğac isə onlara mane olmaz. Hovuz hər bir məhsul və yer üçün min sətir ilə məhdudlaşdırılır.

Hovuz boşaldıqda nə baş verir?

1:15 Doldurma defterdən çəkilir. Boşaldıqda, sifariş yolu sətirdaxili doldurur, rəqabət aparan sorğular isə doldurma kilidinin arxasında gözləyir. Boş hovuz boş anbar demək deyil. Sifariş seçilmiş hovuz sətirlərini silir, sonra bir əməliyyatda sifariş qeydlərini daxil edir. Təsdiq etmə verilənlər bazası kilidlərini buraxır. Geri qaytarma dəyişiklikləri ləğv edir. Sifariş ödəniş prosesi boyunca saxlanılan vəziyyət kimi qalır. Uğurlu ödəniş defteri tələb edir və sifarişi atomik şəkildə ləğv edir.

1:35 Verilənlər bazası kilidləri heç vaxt ödəniş formasını nəzarətdə saxlamağa ehtiyac duymur. Onların kompozit ilkin açarı mağaza, məhsul, qrup, sonra vahid kimliyi ilə başlayır. Axtarışı uyğunlaşdırmaq prototipdə indeks kilidlənməsini azaltdı. Onlar həmçinin boşluq kilidlərindən qaçmaq üçün oxumaq üçün təsdiqlənmişdən istifadə edirlər ki, bu da hovuz doldurmasını blokladı və dairəvi gözləmələrin qarşısını almaq üçün ardıcıl cədvəl sifarişindən istifadə etdilər. Nəşr olunan nümunə son istifadə müddətini qeyd edir. Tərk edilmiş ödənişlərin ehtiyatı sonda buraxılmalıdır, əks halda alış-veriş səbəti bir ev sahibinə çevrilir. Shopify-ın yazısı bu təmizləmə alqoritmini qeyri-müəyyən buraxır, buna görə bu diaqram həyat dövrü tələbini göstərir. Budur əsas məqam.

1:57 Skip locked kilidlənmiş sətirləri istisna edir, buna görə də təlimat onun nəticəsini qeyri-ardıcıl görünüş adlandırır. Nə tam ehtiyat sayını, nə də ədalətli növbələşməni təmin edir. Mövcudluq qərarını və doldurma qaydalarını onun ətrafında saxlayın. Və o tavan? Digər ödəniş kodu verilənlər bazası əlaqələrini çox uzun müddət saxlayırdı. Shopify zəng edənləri etiketlədi və əlaqənin saxlanma müddətini ölçdü,

SKIP LOCKED nəyi nəzərdən qaçırır?

2:14 sonra ödəniş yolunu təmizlədi və axınların eyni zamanda işləməsini nəzərdən keçirdi. Sürətli sorğular hələ də sorğudan kənarda növbəyə dura bilər. Onlar hər iki sistemi Redis avtoritet olmaqla kölgə-yazdı,

Əsl tavan harada idi?

2:26 nəticələri müqayisə etdi, sonra təcili söndürmə keçidi ilə tədricən keçdi. Mənim hökmüm SHIP IT-dir. Mən paylaşılan əməliyyat sərhədini və geri qaytarıla bilən tətbiqi SHIP IT edərdim, bütün ödəniş yolu alətlərlə təmin olunmuş halda. Bununla bağlı bir sualınız varmı?

Niyə bu dizaynı SHIP IT etməliyəm?

2:38 Şərhlərdə qeyd edin. Və bugünkü The Daily Diff budur. Mən Axrisi-dən Niko. Məsuliyyətlə birləşdirin. Shopify inventar sifarişlərini Redis-dən MySQL-ə köçürdü. Bir vahid üçün bir sətir dizaynı eyni zamanda ödənişlərin fərqli uyğun vahidləri seçmək üçün SKIP LOCKED-dan istifadə etməsinə imkan verir. Dizayn əməliyyat sərhədlərindən, ilkin açar düzülüşündən və doldurma qaydalarından asılıdır. Qeyri-ardıcıl görünüşlər, tam fond sayı və ya ədalətli növbələşmə təmin etmir.

2:54 Bağlantı saxlanma müddətini müşahidə etmək və ödəniş yolunu təmizləmək performansı yaxşılaşdırdı. Gölməçənin boşaldılması anbarın boşaldılması demək deyil.

Mənbələr

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