Shopify ने इन्व्हेंटरी आरक्षण MySQL मध्ये हलवले

या व्हिडिओमध्ये काय समाविष्ट आहे

• जुने Redis क्वांटिटी-काउंटर मॉडेल एकाचवेळी व्यवहार हाताळत असे, परंतु आरक्षण स्वच्छता आणि MySQL लेजर अपडेट एकाच स्थानिक अणू व्यवहारामध्ये सामायिक केले जाऊ शकत नव्हते.
• बदललेल्या प्रणालीमध्ये प्रति आयटम/स्थान कॉम्बिनेशनसाठी 1,000 पर्यंत मर्यादित असलेल्या पूलमध्ये प्रत्येक उपलब्ध युनिटसाठी एक पंक्ती वापरली जाते. रिकाम्या पूलमुळे पुनर्भरणासाठी concurrent विनंत्या पुनर्भरणाच्या लॉकमागे वाट पाहतात.
• कंपोजिट प्राइमरी की (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 अधिकृत असताना दोन्ही प्रणालींवर शॅडो-राइट केले, निष्कर्षांची तुलना केली, नंतर किल स्विचसह हळूहळू स्विच केले. माझा निकाल 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