شاپائف نے انوینٹری ریزرویشنز کو MySQL میں منتقل کر دیا
شاپائف نے اپنے انوینٹری ریزرویشن سسٹم کو ریڈیس سے MySQL ڈیٹا بیس میں منتقل کر دیا جو پہلے سے ہی انوینٹری لیجر رکھتا تھا۔
شاپائف نے اپنے انوینٹری ریزرویشن سسٹم کو ریڈیس سے MySQL ڈیٹا بیس میں منتقل کر دیا جو پہلے سے ہی انوینٹری لیجر رکھتا تھا۔ انفرادی طور پر لاک کی جانے والی یونٹ قطاروں کا ایک محدود پول کنکرنٹ چیک آؤٹ کو SKIP LOCKED استعمال کرنے دیتا ہے تاکہ مختلف اہل یونٹس کو منتخب کیا جا سکے۔ ڈیزائن لین دین کی حدود، پرائمری کلیدی ترتیب، دوبارہ بھرنے کے قواعد اور چیک آؤٹ میں کنکشن کے انعقاد کے وقت کا مشاہدہ کرنے پر بھی منحصر ہے۔
تحریری ایڈیشن پڑھیں (انگریزی) ↗
اس ویڈیو میں کیا شامل ہے
- پرانا ریڈیس کوانٹٹی کاؤنٹر ماڈل ہم آہنگی کو ہینڈل کرتا تھا، لیکن ریزرویشن کی صفائی اور MySQL لیجر اپ ڈیٹ ایک واحد مقامی ایٹمی لین دین کو شیئر نہیں کر سکتے تھے۔
- متبادل میں ہر دستیاب یونٹ کے لیے ایک قطار استعمال ہوتی ہے جو ہر آئٹم/مقام کے مجموعہ کے لیے 1,000 پر محدود ہے۔ ایک خالی پول دوبارہ بھرنے کے لاک کے پیچھے انتظار کرنے والی کنکرنٹ درخواستوں کے ساتھ ان لائن دوبارہ بھرنے کو متحرک کر سکتا ہے۔
- جامع پرائمری کلید (shop_id, inventory_item_id, inventory_group_id, id) ہے۔ شاپائف نے اپنے پروٹوٹائپ میں لاک اوور ہیڈ کو کم کیا اور READ COMMITTED کا استعمال کیا تاکہ گیپ لاکس سے بچا جا سکے جو دوبارہ بھرنے میں رکاوٹ بنتے تھے۔
- ریزرویشن ریکارڈ داخل کرنے سے پہلے ریزرو ڈیلیٹ پول قطاروں کو حذف کرتا ہے۔ کمٹ کرنے سے ڈیٹا بیس لاکس جاری ہوتے ہیں جبکہ ذخیرہ شدہ ہولڈ ادائیگی کے دوران برقرار رہتا ہے؛ کامیاب ادائیگی لیجر کا دعوی کرتی ہے اور بعد میں ایک ایٹمی لین دین میں ریزرویشن کو ہٹاتی ہے۔
- MySQL SKIP LOCKED کو ایک متضاد ویو کے طور پر دستاویز کرتا ہے جو لاک کی گئی قطاروں کو چھوڑ دیتا ہے۔ یہ مکمل اسٹاک گنتی یا منصفانہ باری لینے کو قائم نہیں کرتا، صرف قطار کی سطح کے لاکس پر لاگو ہوتا ہے اور سٹیٹمنٹ پر مبنی نقل کے لیے غیر محفوظ ہے۔
- ماخذ مثال میں expires_at شامل ہے، لیکن شاپائف MySQL کی میعاد ختم ہونے والی صفائی کے الگورتھم کو دستاویز نہیں کرتا ہے۔ ویڈیو کی ریلیز/میعاد ختم ہونے کی برانچ ایک وضاحتی لائف سائیکل کی ضرورت ہے۔
- دیگر چیک آؤٹ کوڈ میں کنکشن ہولڈ کا وقت آخری تھرو پٹ رکاوٹ تھا۔ شاپائف نے دونوں سسٹمز کو شیڈو رائٹ کیا، نتائج کا موازنہ کیا اور ریڈیس کِل سوئچ فال بیک کے ساتھ بتدریج منتقل ہوا۔
ترجمہ شدہ ٹرانسکرپٹ
اصل انگریزی بیان سے ترجمہ کیا گیا۔ دستیاب آڈیو اور کیپشنز یوٹیوب کے زیر انتظام ہیں۔
ریزرویشنز کو MySQL میں کیوں منتقل کریں؟
0:00 چیک آؤٹ کو تیز رہنے کے لیے ریڈیس کی ضرورت ہے۔ شاپائف نے انوینٹری ریزرویشنز کو MySQL میں منتقل کیا جس میں فی یونٹ ایک قطار استعمال کی گئی محدود پول۔ MySQL کا انتخاب کیوں کریں؟ لاک کو محفوظ طریقے سے کیسے چھوڑیں؟ یہ The Daily Diff ہے، اندرونی طور پر۔ اور تیز رفتار سوالات ابھی بھی حد کو کیوں چھوتے تھے؟ شاپائف آن لائن اور ذاتی طور پر فروخت کے لیے ایک کامرس پلیٹ فارم ہے۔ ریڈیس ایک ان میموری ڈیٹا اسٹور ہے۔
0:21 MySQL ایک ریلیشنل ڈیٹا بیس ہے، اور شاپائف پہلے ہی اپنی انوینٹری لیجر کو وہاں رکھتا تھا۔ ایک ریزرویشن خریدار کے ادائیگی کے دوران اسٹاک کو مختصر طور پر روکتا ہے۔
دو اسٹورز خطرناک کیوں تھے؟
0:29 ان کے ریڈیس ماڈل نے آئٹم کاؤنٹر کو کم کیا۔ ادائیگی شدہ آرڈر کا دعوی کرنے کا مطلب تھا MySQL لیجر کو اپ ڈیٹ کرنا اور ریڈیس کو صاف کرنا۔ وہ الگ الگ تحریریں اسٹاک کو دو بار فروخت کر سکتی تھیں یا جب اسے فروخت کے قابل ہونا چاہیے تو اسے دستیاب نہ کر سکتی تھیں۔ پرانے ماڈل میں مقام کی آگاہی بھی نہیں تھی۔ متبادل کو کسی ایسی جگہ سے اسٹاک کا انتخاب کرنا چاہیے جو آرڈر کو پورا کر سکے۔ غلط براعظم پر ایک گودام ایک بہترین ڈیٹا بیس اندراج بناتا ہے اور ایک خوفناک ڈیلیوری کا وعدہ۔ پہلے کی MySQL کوششوں میں کوانٹٹی قطار استعمال کی گئی تھی، لہذا مقابلہ کرنے والے چیک آؤٹ اسی
لاک کی جانے والی یونٹ کیا بنتی ہے؟
0:56 لاک پر قطار میں کھڑے تھے۔ ایک اسپریڈشیٹ سیل کے گرد مخملی رسی کا تصور کریں۔ مزید کارکنوں کو شامل کرنا صرف قطار کو لمبا کرتا ہے۔ شاپائف نے لاک کی جانے والی آبجیکٹ کو تبدیل کیا۔ ہر دستیاب یونٹ کو اپنی قطار ملتی ہے۔ ایک لاکنگ ریڈ دوسرے یونٹس کو چھوڑ دیتا ہے جو دوسرے لین دین کے پاس ہیں اور دوسرے اہل یونٹس کو منتخب کرتا ہے۔ مختلف کارکن مختلف قطاریں حاصل کر سکتے ہیں، جبکہ ہاٹ کاؤنٹر ان کے راستے سے دور رہتا ہے۔
جب پول خالی ہو جاتا ہے تو کیا ہوتا ہے؟
1:15 یہ پول ہر آئٹم اور مقام کے لیے ایک ہزار قطاروں پر محدود ہے۔ دوبارہ بھرنا لیجر سے ہوتا ہے۔ اگر یہ خالی ہو جاتا ہے، تو ریزرو راستہ ان لائن دوبارہ بھرتا ہے، مقابلہ کرنے والی درخواستیں دوبارہ بھرنے کے لاک کے پیچھے انتظار کر رہی ہیں۔ خالی پول کا مطلب خالی گودام نہیں ہے۔ ریزرو منتخب پول قطاروں کو حذف کرتا ہے، پھر ایک لین دین میں ریزرویشن ریکارڈ داخل کرتا ہے۔ کمٹ کرنے سے ڈیٹا بیس لاکس جاری ہوتے ہیں۔
1:35 رول بیک تبدیلیوں کو کالعدم کرتا ہے۔ ریزرویشن ادائیگی کے عمل کے دوران ذخیرہ شدہ حالت کے طور پر زندہ رہتی ہے۔ کامیاب ادائیگی لیجر کا دعوی کرتی ہے اور ریزرویشن کو ایٹمی طور پر ہٹاتی ہے۔ ڈیٹا بیس لاکس کو کبھی بھی ادائیگی کے فارم کی دیکھ بھال کرنے کی ضرورت نہیں ہوتی۔ ان کی جامع پرائمری کلید دکان، آئٹم، گروپ، پھر یونٹ کی شناخت سے شروع ہوتی ہے۔ لوک اپ کو میچ کرنے سے ان کے پروٹوٹائپ میں انڈیکس لاکنگ کم ہوئی۔ انہوں نے گیپ لاکس سے بچنے کے لیے ریڈ کمٹڈ بھی استعمال کیا جو پول کو
1:57 دوبارہ بھرنے میں رکاوٹ بنتے تھے، اور سرکلر انتظار کو روکنے کے لیے ایک مستقل ٹیبل آرڈر استعمال کیا۔ شائع شدہ مثال ایک میعاد ختم ہونے کا وقت ریکارڈ کرتی ہے۔ چھوڑی گئی ادائیگیوں کے لیے آخر کار اسٹاک کو جاری کرنے کی ضرورت ہوتی ہے، ورنہ شاپنگ کارٹ ایک جاگیردار بن جاتی ہے۔ شاپائف کی پوسٹ اس صفائی کے الگورتھم کو غیر متعین چھوڑ دیتی ہے، لہذا یہ ڈایاگرام لائف سائیکل کی ضرورت کو ظاہر کرتا ہے۔ یہاں پکڑ ہے۔
SKIP LOCKED کیا چھوڑ دیتا ہے؟
2:14 چھوڑ دیا گیا لاک کی گئی قطاروں کو خارج کرتا ہے، لہذا دستی اس کے نتیجے کو ایک متضاد ویو کہتا ہے۔ یہ نہ تو مکمل اسٹاک گنتی فراہم کرتا ہے اور نہ ہی منصفانہ باری لینے کو۔ دستیابی کا فیصلہ اور دوبارہ بھرنے کے قواعد کو اس کے ارد گرد رکھیں۔
اصل حد کہاں تھی؟
2:26 اور وہ حد؟ دیگر چیک آؤٹ کوڈ ڈیٹا بیس کنکشنز کو بہت زیادہ دیر تک روکے ہوئے تھا۔ شاپائف نے کال کرنے والوں کو ٹیگ کیا اور کنکشن ہولڈ کا وقت ناپا، پھر چیک آؤٹ پاتھ کو صاف کیا اور تھریڈ ہم آہنگی پر دوبارہ غور کیا۔ تیز رفتار سوالات ابھی بھی سوال کے باہر قطار میں کھڑے ہو سکتے ہیں۔
میں اس ڈیزائن کو کیوں بھیجوں؟
2:38 انہوں نے دونوں سسٹمز کو ریڈیس کے ساتھ مستند طور پر شیڈو رائٹ کیا، نتائج کا موازنہ کیا، پھر کِل سوئچ کے ساتھ بتدریج منتقل ہوئے۔ میرا فیصلہ SHIP IT ہے۔ میں مشترکہ لین دین کی حد اور اس رول بیک ایبل رول آؤٹ کو بھیجوں گا، جس میں پورا چیک آؤٹ پاتھ انسٹرو مینٹڈ ہو۔ اس کے بارے میں کوئی سوال ہے؟ اسے کمنٹس میں لکھیں۔ اور یہ آج کا diff ہے۔
2:54 میں Axrisi سے Niko ہوں۔ ذمہ داری سے ضم کریں۔
ذرائع
- 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



