आज हम इस बारे में बात करेंगे कि कैसे लोडिंग "की-वैल्यू" सेवाओं को डिजाइन करने के लिए अपने दृष्टिकोण को बदल दिया है। आप सीखेंगे कि कई वर्षों पहले हमारे द्वारा इस तरह की सेवाओं का निर्माण किया गया था (डेटाबेस के रूप में रिपॉजिटरी और डेटा के लिए एक विशेष डेमन के रूप में डेटा का उपयोग करके), हमें किन कठिनाइयों का सामना करना पड़ा और किस वास्तुकला के परिणामस्वरूप हम सामने आए समस्याओं को हल करते हैं।
आधुनिक इंटरनेट परियोजनाएं सक्रिय रूप से आंतरिक सेवाओं का उपयोग करती हैं जो कुंजी द्वारा मूल्यों तक पहुंच की अनुमति देती हैं। यह या तो तैयार समाधान या इन-हाउस विकास हो सकता है। 2006 के बाद से, बुश विशेषज्ञों ने ऐसी कई सेवाओं का निर्माण किया है, जिनमें शामिल हैं:
- एक ऐसी सेवा जो अपने पहचानकर्ता द्वारा उपयोगकर्ता डेटा के स्थान पर रिपोर्ट करती है;
- एक सेवा जो उपयोगकर्ता प्रोफ़ाइल में कॉल की संख्या के बारे में जानकारी संग्रहीत करती है;
- उपयोगकर्ता के हितों की सूची;
- उपयोगकर्ता के स्थान को निर्धारित करने के लिए कई "जियोसर्विस"।
उनकी विविधता के बावजूद, एक एकीकृत डिजाइन दृष्टिकोण लागू किया गया था, जिसके अनुसार सेवा में निम्नलिखित घटक शामिल होने चाहिए:
- एक रिपॉजिटरी डेटाबेस जो डेटा के संदर्भ संस्करण को संग्रहीत करता है।
- एक तेज़ C या C ++ डेमन जो डेटा अनुरोधों को संसाधित करता है और रिपॉजिटरी डेटाबेस के साथ अद्यतन किया जाता है।
- PHP कक्षाएं जो डेमॉन और रिपॉजिटरी बेस के साथ काम प्रदान करती हैं।
यह हमारे लिए महत्वपूर्ण था कि कोई भी सेवा बड़ी संख्या में एक साथ अनुरोधों को संभाल सकती थी, इसलिए केवल एक MySQL पर आधारित एक समाधान उपयुक्त नहीं था। यहां से एक अतिरिक्त घटक तेजी से डेमॉन के रूप में प्रकट हुआ, जिसे मेमकेड सिस्टम द्वारा प्रतिस्थापित नहीं किया जा सकता था, क्योंकि हमें विशिष्ट डेटा सूचकांकों का उपयोग करने की आवश्यकता है।
2010 के अंत में, एक
जापानी शिल्पकार द्वारा लिखी गई
हैंडलरसॉकेट MySQL प्लग-इन ने MySQL में संग्रहीत डेटा के साथ NoSQL प्रदान किया। 2011 के वसंत में, पहले से ही, विशेषज्ञों ने नई तकनीक पर अपना ध्यान केंद्रित किया, जिससे कंपनी के "प्रमुख-मूल्य" सेवाओं के विकास और समर्थन को आसान बनाने की उम्मीद की गई।
"पहले"
नए दोस्तों की खोज करने के लिए नेटवर्क में, बड़ी संख्या में उपयोगकर्ताओं ने ईमेल द्वारा विभिन्न सूचनाएं प्राप्त करने वाले उपयोगकर्ताओं की एक बड़ी संख्या दर्ज की। और इनमें से प्रत्येक उपयोगकर्ता के पास उन सूचनाओं के प्रकार को चुनने का अवसर है, जिन्हें वह प्राप्त करना चाहता है। तदनुसार, आपको मेल सेटिंग्स को कहीं स्टोर करने और इस डेटा तक पहुंच प्रदान करने की आवश्यकता है। उनसे अनुरोधों के 99% से अधिक अनुरोध पढ़े जाते हैं। मुख्य "पाठक" ई-मेल के स्क्रिप्ट-जनरेटर और प्रेषक हैं, जो इन आंकड़ों के आधार पर किसी विशिष्ट उपयोगकर्ता के एक निश्चित प्रकार के पत्राचार भेजने की संभावना या अक्षमता पर निर्णय लेते हैं। सबसे पहले, डेटा को संग्रहीत करने के लिए केवल डेटाबेस का उपयोग किया गया था, लेकिन यह पढ़ने के अनुरोधों की बढ़ती संख्या के साथ सामना करना बंद कर दिया। इस भार को हटाने के लिए, एक विशेष डेमॉन बनाया गया था - EmailNotification।
"पुराना स्कूल" सेवा कार्यान्वयन
सेवा का एक प्रमुख घटक सी-डेमन था, जो मेमोरी में सभी सेटिंग्स को संग्रहीत करता है और उन्हें टीसीपी पर सरलतम प्रोटोकॉल के माध्यम से पढ़ने और लिखने की सुविधा प्रदान करता है। इसके अलावा, इस डेमन ने हिट आंकड़े एकत्र किए, जिस पर हमने ग्राफ़ बनाए।
पहले, सेवा की वास्तुकला काफी सरल थी और इस तरह दिखती थी:
डेटाबेस में एक डीबी सर्वर पर सेटिंग्स को लगातार संग्रहीत किया गया था, और सी-डेमन ने दूसरे पर काम किया। शुरुआत में, डेमन ने डेटाबेस से सभी डेटा का चयन किया और उस पर एक सूचकांक (
जूडी एरे ) का निर्माण किया। प्रारंभिक प्रक्रिया में लगभग 15 मिनट लगे, लेकिन चूंकि इस ऑपरेशन को सेवा के पूरे अस्तित्व के दौरान केवल कुछ समय की आवश्यकता थी, इसलिए यह एक महत्वपूर्ण कमी नहीं थी। इस प्रक्रिया में, क्लाइंट (सीएलआई स्क्रिप्ट, वेब और अन्य सेवाओं) ने एक विशेष एपीआई के माध्यम से डेमॉन तक पहुंच बनाई, उदाहरण के लिए, यह पूछते हुए कि क्या इस उपयोगकर्ता को यह पत्र भेजा जा सकता है या नहीं, और डेमॉन ने अंतर्निहित तर्क का उपयोग करते हुए, इसकी स्मृति में एक सेटिंग की तलाश की और एक उत्तर जारी किया। । "लेखक ग्राहक" ने डेमन को एक विशिष्ट उपयोगकर्ता के लिए कुछ सेटिंग्स बदलने का निर्देश दिया।
MySQL को डेटा लिखने का कार्य पूरी तरह से EmailNotification API की जिम्मेदारी थी। उसी समय, डेटा सिंक्रनाइज़ेशन संभावित रूप से हो सकता है, उदाहरण के लिए, जब एक रिकॉर्ड सफलतापूर्वक डेटाबेस में पारित हो गया, लेकिन डेमॉन, या इसके विपरीत नहीं गया। हालाँकि, इस सेवा ने बहुत अच्छा काम किया। 2007 तक, वहाँ एक "थोड़ा परेशानी" थी, अर्थात्, एक दूसरा डेटा सेंटर दिखाई दिया, भौगोलिक रूप से पहले से दूरस्थ और नई दुनिया के उपयोगकर्ताओं की सेवा करने के लिए डिज़ाइन किया गया। यह तुरंत स्पष्ट हो गया कि नई साइट पर वास्तु समाधान के सामान्य दोहराव के साथ तिरस्कृत नहीं किया जा सकता है। चूंकि दोनों साइटों से एक ही उपयोगकर्ता को पत्र भेजे जा सकते हैं, इसलिए यह आवश्यक है कि दोनों सेवाएं एक ही डेटा पर काम करें।
सौभाग्य से, विशेष रूप से ऐसे मामलों के लिए, कंपनी के पास CPQ ईवेंट्स (CPQ - क्रॉस प्लेटफ़ॉर्म क्यू, क्रॉस-प्लेटफ़ॉर्म कतारें। Approx। लेखक) की एक प्रणाली है, जो आपको साइटों के बीच घटनाओं के बारे में जानकारी प्रसारित करने के लिए जल्दी और सबसे महत्वपूर्ण रूप से गारंटी और दिए गए अनुक्रम में अनुमति देता है। परिणामस्वरूप, दो साइटों पर, सेवा वास्तुकला ने निम्न रूप लिया:
अब कोई भी लिखित अनुरोध न केवल स्थानीय साइट के आधार और सी-डेमन, बल्कि सीपीक्यू तक भी गया। CPQ ने अनुरोध को किसी अन्य साइट की आसन्न कतार में भेज दिया, और उसने पहले से ही उसी साइट पर EmailNotification API के माध्यम से रिकॉर्डिंग अनुरोध वापस कर दिया।
सिस्टम अधिक जटिल हो गया, लेकिन फिर भी कई वर्षों तक लगातार काम करता रहा। और यदि साइटों पर डेटा में कोई विसंगति नहीं है तो सब कुछ ठीक होगा। उपलब्ध साइटों के दो आधारों में अलग-अलग संख्या में सेटिंग्स थीं। और हालांकि यह अंतर 0.1% से कम था, "स्वच्छता और सुरक्षा" की सनसनी हो गई थी। इसके अलावा, हमने पाया कि अंतर न केवल साइटों के ठिकानों के बीच दिखाई दिया, बल्कि यह उसी साइट के भीतर आधार और सी-दानव के बीच मौजूद था। मुझे यह सोचना था कि सेवा को और अधिक विश्वसनीय कैसे बनाया जाए।
नया तरीका
प्रारंभ में, EmailNotification सेवा के लिए दो बुनियादी आवश्यकताएं थीं: पहला, प्रसंस्करण की उच्च गति रीड रिक्वेस्ट, जिसे सी-डेमन ने बहुत अच्छा किया; दूसरा उन दोनों साइटों के डेटा की पहचान है जिनके साथ समस्याएं थीं। सिंक्रनाइज़ेशन के साथ संघर्ष करने के बजाय, हमने सरलीकरण के मार्ग का अनुसरण करते हुए सेवा की वास्तुकला को पूरी तरह से फिर से करने का फैसला किया:
सबसे पहले, हमने MySQL से HandlerSocket प्लगइन को कनेक्ट किया और डेटाबेस के साथ काम करने के लिए हमारे API को सिखाया। इसके लिए धन्यवाद, हम सी-दानव के उपयोग से इनकार करने में सक्षम थे। फिर, एपीआई को सरल बनाने के बाद, हमने योजनाओं के बीच सीपीक्यू सेवा को हटा दिया, इसे साइटों के बीच अच्छी तरह से स्थापित "मास्टर-मास्टर" प्रतिकृति के साथ बदल दिया। नतीजतन, हमें एक बहुत ही सरल और विश्वसनीय सर्किट मिला, जिसमें निम्नलिखित फायदे हैं:
- प्रतिकृति पारदर्शी है, आंतरिक सीपीक्यू सेवा के साथ काम करने वाले किसी भी कोड की आवश्यकता नहीं है। उसी समय, साइटों के बीच अपडेट को स्थानांतरित करने में देरी कुछ सेकंड से घटकर एक सेकंड के अंश तक हो गई।
- परमाणु डेटा रिकॉर्डिंग (अंत में!)। यदि हैंडलर सॉकेट को लिखने के लिए EmailNotification API अनुरोध सफलतापूर्वक पूरा हो गया है, तो कार्य पूरा हो गया है, रिकॉर्डिंग बिल्कुल दूसरी साइट पर दोहराई जाएगी, और हमें इसके बारे में किसी अन्य घटक को सूचित करने की आवश्यकता नहीं है।
क्या हमें एक नई योजना पर स्विच करने में समस्या है? कोई गंभीर नहीं हैं। AUTO_INCREMENT को पहले से ही हैंडलरसॉकेट प्लगइन, कम्पोजिट इंडेक्स वर्क, ENUM के साथ-साथ सपोर्ट मिलता है, आपको बस टाइमस्टैम्प फील्ड में से एक के लिए CURRENT_TIMESTAMP डिफ़ॉल्ट मान को छोड़ना होगा।
जैसा कि आप जानते हैं, हैंडलरसॉकेट का लाभ अपने काम की गति में नहीं है - यह प्रभावशाली होने के बजाय स्वीकार्य है, लेकिन प्रति इकाई समय में बड़ी संख्या में अनुरोधों के तहत काम करने की क्षमता में है। यह देखते हुए कि अब सेवा एक साइट पर प्रति सेकंड केवल 2 - 2.5 हजार अनुरोधों पर कार्य करती है, हमारे पास सुरक्षा का एक बड़ा मार्जिन है।
लेकिन उन लोगों के लिए जो विशेष रूप से हैंडलरसॉकेट प्लग-इन की गति में रुचि रखते हैं, हम तीन आदेशों के औसत निष्पादन समय के साथ एक ग्राफ देंगे: हैंडलरसॉकेट से कनेक्ट करना, सूचकांक को खोलना और उस पर डेटा का चयन करना (मिलीसेकेंड में वाई अक्ष पर मान):
अंतिम शब्द
पिछले एक साल में, बैटर ने हैंडलरसॉकेट को लगातार डेटा स्टोरेज के साथ "की-वैल्यू" रिपॉजिटरी के रूप में उपयोग करने के लिए इस्तेमाल किया। यह हमें सरल और अधिक समझने योग्य कोड लिखने की अनुमति देता है, सी प्रोग्रामर को तुच्छ कार्यों पर काम करने से बचाता है और समर्थन को काफी सरल करता है। और जबकि सब कुछ कहता है कि इस दिशा में आंदोलन जारी रहेगा।
लेकिन यह मत सोचो कि Badoo के अंदर हैंडलरकेट का उपयोग करना सबसे सरल कार्यों तक सीमित है। उदाहरण के लिए, हमारे पास रिकॉर्डिंग फ़ंक्शन की प्रबलता के साथ समस्याओं को हल करने के लिए इसका उपयोग करने में व्यापक अनुभव है, जहां बहुत अधिक मात्रा में लोड के तहत कई बारीकियां दिखाई देती हैं। यदि आप विवरण में रुचि रखते हैं - टिप्पणी, पूछें, और हम निश्चित रूप से नए लेखों के साथ इस विषय को जारी रखेंगे।
धन्यवाद!