Shopify သည် Inventory Reservations များကို MySQL သို့ ပြောင်းရွှေ့ခဲ့သည်။

ဤဗီဒီယိုတွင် ဖော်ပြထားသောအရာများ

• အဟောင်း Redis quantity-counter model သည် concurrency ကို ကိုင်တွယ်နိုင်သော်လည်း reservation cleanup နှင့် MySQL ledger update တို့သည် local atomic transaction တစ်ခုတည်းကို မျှဝေ၍မရပါ။
• အစားထိုးစနစ်သည် item/location ပေါင်းစပ်မှုတစ်ခုလျှင် ၁၀၀၀ ဖြင့် ကန့်သတ်ထားသော pool တွင် ရရှိနိုင်သော unit တစ်ခုစီအတွက် row တစ်ခုကို အသုံးပြုသည်။ empty pool သည် replenishment lock နောက်တွင် စောင့်ဆိုင်းနေသော concurrent request များနှင့်အတူ inline replenishment ကို စတင်နိုင်သည်။
• composite primary key မှာ (shop_id, inventory_item_id, inventory_group_id, id) ဖြစ်ပါတယ်။ Shopify သည် ၎င်း၏ prototype တွင် lock overhead ကို လျှော့ချခဲ့ပြီး replenishment ကို ပိတ်ဆို့သော gap lock များကို ရှောင်ရှားရန် READ COMMITTED ကို အသုံးပြုခဲ့သည်။
• Reserve သည် reservation record များ မထည့်သွင်းမီ pool row များကို ဖျက်သည်။ commit လုပ်ခြင်းသည် database lock များကို လွှတ်ပေးပြီး သိုလှောင်ထားသော hold သည် ငွေပေးချေမှုတစ်လျှောက် ဆက်လက်တည်ရှိသည်။ အောင်မြင်သော ငွေပေးချေမှုသည် ledger ကို တောင်းဆိုပြီး နောက်ပိုင်း atomic transaction တွင် reservation ကို ဖယ်ရှားသည်။
• MySQL စာရွက်စာတမ်းများက SKIP LOCKED ကို lock လုပ်ထားသော row များကို ဖယ်ရှားသည့် inconsistent view အဖြစ် ဖော်ပြသည်။ ၎င်းသည် ပြည့်စုံသော stock count သို့မဟုတ် မျှတသော အလှည့်ယူခြင်းကို မဖော်ပြဘဲ row-level lock များနှင့်သာ သက်ဆိုင်ပြီး statement-based replication အတွက် မလုံခြုံပါ။
• source example တွင် expires_at ပါဝင်သော်လည်း Shopify သည် MySQL expiration-cleanup algorithm ကို စာရွက်စာတမ်းမပြုပါ။ ဗီဒီယို၏ release/expiry branch သည် ရှင်းလင်းချက် lifecycle လိုအပ်ချက်တစ်ခုဖြစ်သည်။
• အခြား checkout code တွင် connection hold time သည် နောက်ဆုံး throughput bottleneck ဖြစ်သည်။ Shopify သည် စနစ်နှစ်ခုလုံးကို shadow-write လုပ်ခဲ့ပြီး ရလဒ်များကို နှိုင်းယှဉ်ကာ Redis kill-switch fallback ဖြင့် တဖြည်းဖြည်း ပြောင်းလဲခဲ့သည်။

ဘာသာပြန်ထားသော စာသားမှတ်တမ်း

မူရင်း အင်္ဂလိပ်စကားပြောမှ ဘာသာပြန်ထားသည်။ ရရှိနိုင်သော အသံနှင့် စာတန်းထိုးများကို YouTube မှ ထိန်းချုပ်ထားသည်။

MySQL ထဲကို Reservation တွေ ဘာကြောင့်ပြောင်းရွှေ့တာလဲ။

0:00 Checkout လုပ်ဖို့ Redis က မြန်နေဖို့လိုတယ်။ Shopify က inventory reservation တွေကို MySQL ထဲကို unit တစ်ခုစီအတွက် row တစ်ခုစီနဲ့ bounded pool ထဲကို ပြောင်းရွှေ့လိုက်တယ်။ ဘာလို့ MySQL ကို ရွေးတာလဲ။ lock တွေကို ဘယ်လိုလုံခြုံစွာ ကျော်သွားမလဲ။ ဒါကတော့ The Daily Diff ပါ၊ အတွင်းပိုင်းကို ဖော်ထုတ်ခြင်း။ ဘာလို့ မြန်ဆန်တဲ့ query တွေက ကန့်သတ်ချက်တစ်ခုကို ရောက်နေတုန်းလဲ။ Shopify က online နဲ့ လူကိုယ်တိုင်ရောင်းချဖို့အတွက် commerce platform တစ်ခုပါ။ Redis က in-memory data store တစ်ခုပါ။

0:21 MySQL က relational database တစ်ခုဖြစ်ပြီး Shopify က သူ့ရဲ့ inventory ledger ကို အဲဒီမှာ သိမ်းထားပြီးသား။ buyer က ငွေရှင်းနေချိန်မှာ reservation က stock ကို ခဏထိန်းထားပေးတယ်။

စတိုးဆိုင်နှစ်ခုက ဘာလို့အန္တရာယ်ရှိတာလဲ။

0:29 သူတို့ရဲ့ Redis model က item counter ကို လျှော့ချခဲ့တယ်။ ငွေရှင်းပြီးတဲ့ order ကို တောင်းဆိုတာက MySQL ledger ကို update လုပ်ပြီး Redis ကို ရှင်းလင်းတာကို ဆိုလိုတယ်။ အဲဒီ သီးခြားရေးသားမှုတွေကြောင့် stock တွေက နှစ်ခါရောင်းရတာ ဒါမှမဟုတ် ရောင်းချနိုင်ရမယ့်အချိန်မှာ မရနိုင်ဘဲ ဖြစ်နေနိုင်တယ်။ အဟောင်း model မှာ location awareness လည်း မရှိဘူး။ အစားထိုးစနစ်က order ကို ဖြည့်ဆည်းပေးနိုင်တဲ့ နေရာတစ်ခုကနေ stock ကို ရွေးချယ်ရမယ်။ မှားယွင်းတဲ့ တိုက်ကြီးပေါ်က ဂိုဒေါင်တစ်ခုက database entry အတွက် အလွန်ကောင်းပြီး ပို့ဆောင်မှုကတိကဝတ်အတွက် ဆိုးရွားတယ်။ အရင် MySQL ကြိုးပမ်းမှုတွေက quantity row ကို အသုံးပြုခဲ့တာကြောင့် ပြိုင်ဆိုင်နေတဲ့ checkout တွေက

Lockable unit က ဘာဖြစ်သွားတာလဲ။

0:56 lock တစ်ခုတည်းမှာ တန်းစီနေခဲ့တယ်။ spreadsheet cell ပတ်ပတ်လည်က velvet ကြိုးကို သတိရပါ။ worker တွေ ပိုထည့်တာက တန်းစီတာကို ရှည်စေရုံပဲ။ Shopify က lockable object ကို ပြောင်းလဲလိုက်တယ်။ ရနိုင်တဲ့ unit တစ်ခုစီမှာ သူ့ရဲ့ကိုယ်ပိုင် row ရရှိတယ်။ locking read က အခြား transaction တစ်ခုက ထိန်းချုပ်ထားတဲ့ unit တွေကို ကျော်သွားပြီး အခြားသင့်လျော်တဲ့ unit တွေကို ရွေးချယ်တယ်။ မတူညီတဲ့ worker တွေက မတူညီတဲ့ row တွေကို ရယူနိုင်တယ်။ hot counter က သူတို့ရဲ့ လမ်းကြောင်းကနေ ကင်းဝေးနေချိန်မှာပေါ့။

pool က ဗလာဖြစ်သွားရင် ဘာဖြစ်မလဲ။

1:15 အဲဒီ pool ကို item နဲ့ location တစ်ခုစီအတွက် row တစ်ထောင်မှာ ကန့်သတ်ထားတယ်။ Replenishment က ledger ကနေ ဆွဲထုတ်တယ်။ အကယ်၍ ဗလာဖြစ်သွားရင် reserve လမ်းကြောင်းက inline replenishment လုပ်ပြီး ပြိုင်ဆိုင်နေတဲ့ request တွေက replenishment lock နောက်မှာ စောင့်နေရတယ်။ Empty pool ဆိုတာ ဂိုဒေါင်ဗလာဖြစ်တာကို မဆိုလိုဘူး။ Reserve က ရွေးချယ်ထားတဲ့ pool row တွေကို ဖျက်ပြီးတော့ transaction ထဲမှာ reservation record တွေကို ထည့်သွင်းတယ်။ Commit လုပ်ခြင်းက database lock တွေကို လွှတ်ပေးတယ်။

1:35 Rollback က အပြောင်းအလဲတွေကို ပြန်ဖျက်တယ်။ Reservation က သိုလှောင်ထားတဲ့ state အဖြစ် ငွေပေးချေမှု လုပ်ငန်းစဉ်ကို ရှင်သန်တယ်။ အောင်မြင်တဲ့ ငွေပေးချေမှုက ledger ကို တောင်းဆိုပြီး reservation ကို atomically ဖယ်ရှားတယ်။ Database lock တွေက payment form ကို စောင့်ရှောက်ဖို့ မလိုတော့ဘူး။ သူတို့ရဲ့ composite primary key က shop, item, group, ပြီးတော့ unit identity နဲ့ စတယ်။ lookup ကို ကိုက်ညီတာက သူတို့ရဲ့ prototype မှာ index locking ကို လျှော့ချပေးခဲ့တယ်။ သူတို့က pool replenishment ကို ပိတ်ဆို့တဲ့ gap lock တွေကို ရှောင်ရှားဖို့ read committed ကိုလည်း အသုံးပြုပြီး

1:57 circular waits ကို တားဆီးဖို့ consistent table order ကို အသုံးပြုတယ်။ ထုတ်ဝေထားတဲ့ ဥပမာမှာ သက်တမ်းကုန်ဆုံးချိန်ကို မှတ်တမ်းတင်ထားတယ်။ စွန့်ပစ်ထားတဲ့ ငွေပေးချေမှုတွေမှာ stock ကို နောက်ဆုံးတော့ လွှတ်ပေးဖို့လိုတယ်၊ မဟုတ်ရင် shopping cart က အိမ်ပိုင်ရှင်ဖြစ်သွားလိမ့်မယ်။ Shopify ရဲ့ post မှာ အဲဒီ cleanup algorithm ကို မဖော်ပြထားဘူး။ ဒါကြောင့် ဒီကားချပ်က lifecycle လိုအပ်ချက်ကို ပြသထားတယ်။ ဒီမှာက ပြဿနာပဲ။

SKIP LOCKED က ဘာတွေချန်ထားခဲ့လဲ။

2:14 Skip locked က lock လုပ်ထားတဲ့ row တွေကို ချန်လှပ်ထားတာကြောင့် manual က သူ့ရဲ့ရလဒ်ကို inconsistent view လို့ ခေါ်တယ်။ ၎င်းသည် ပြည့်စုံသော stock count ကိုလည်း မပေးသလို မျှတသော အလှည့်ယူခြင်းကိုလည်း မပေးဘူး။ ရရှိနိုင်မှု ဆုံးဖြတ်ချက်နဲ့ replenishment rules တွေကို သူ့ပတ်ပတ်လည်မှာ ထားပါ။

တကယ့် ကန့်သတ်ချက်က ဘယ်မှာလဲ။

2:26 ပြီးတော့ အဲဒီ ကန့်သတ်ချက်ကော။ အခြား checkout code က database connection တွေကို အချိန်ကြာမြင့်စွာ ထိန်းထားခဲ့တယ်။ Shopify က caller တွေကို tag လုပ်ပြီး connection hold time ကို တိုင်းတာခဲ့တယ်။ ပြီးတော့ checkout path ကို ရှင်းလင်းပြီး thread concurrency ကို ပြန်လည်စစ်ဆေးခဲ့တယ်။ မြန်ဆန်တဲ့ query တွေက query အပြင်ဘက်မှာ တန်းစီနေတုန်းပဲ။

ဒီ design ကို ဘာလို့တင်ပို့သင့်တာလဲ။

2:38 သူတို့က စနစ်နှစ်ခုလုံးကို Redis ကို authoritative ထားပြီး shadow-write လုပ်ခဲ့တယ်။ ရလဒ်တွေကို နှိုင်းယှဉ်ပြီး kill switch နဲ့ တဖြည်းဖြည်း ပြောင်းလဲခဲ့တယ်။ ကျွန်တော့်ရဲ့ စီရင်ချက်က SHIP IT ပါ။ ကျွန်တော်က shared transaction boundary နဲ့ rollbackable rollout ကို တင်ပို့မှာပါ။ checkout path တစ်ခုလုံးကို instrument လုပ်ထားတယ်။ ဒီအကြောင်း မေးစရာရှိလား။ comment မှာ ထည့်လိုက်ပါ။ ဒါကတော့ ဒီနေ့အတွက် diff ပါ။

2:54 ကျွန်တော် Axrisi က Niko ပါ။ တာဝန်ယူမှုရှိစွာ ပေါင်းစည်းပါ။

ရင်းမြစ်များ

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