Yandex.Market खोज कैसे काम करती है और यदि कोई सर्वर विफल हो जाता है तो क्या होता है

नमस्ते, मेरा नाम एवगेनी है। मैं Yandex.Market सर्च इंफ्रास्ट्रक्चर में काम करता हूं। मैं हैबर समुदाय को बाज़ार की आंतरिक रसोई के बारे में बताना चाहता हूँ - और मेरे पास बताने के लिए बहुत कुछ है। सबसे पहले, बाज़ार खोज कैसे काम करती है, प्रक्रियाएँ और वास्तुकला। हम आपातकालीन स्थितियों से कैसे निपटें: यदि एक सर्वर डाउन हो जाए तो क्या होगा? यदि ऐसे 100 सर्वर हों तो क्या होगा?

आप यह भी सीखेंगे कि हम एक साथ कई सर्वरों पर नई कार्यक्षमता कैसे लागू करते हैं। और कैसे हम उपयोगकर्ताओं को कोई असुविधा पहुंचाए बिना सीधे उत्पादन में जटिल सेवाओं का परीक्षण करते हैं। सामान्य तौर पर, बाज़ार खोज कैसे काम करती है ताकि हर किसी को अच्छा समय मिले।

हमारे बारे में थोड़ा: हम कौन सी समस्या का समाधान करते हैं

जब आप टेक्स्ट दर्ज करते हैं, मापदंडों के आधार पर किसी उत्पाद की खोज करते हैं, या विभिन्न दुकानों में कीमतों की तुलना करते हैं, तो सभी अनुरोध खोज सेवा को भेज दिए जाते हैं। खोज बाज़ार में सबसे बड़ी सेवा है.

हम सभी खोज अनुरोधों को संसाधित करते हैं: साइटों से Market.yandex.ru, beru.ru, सुपरचेक सेवा, Yandex.Advisor, मोबाइल एप्लिकेशन। हम yandex.ru पर खोज परिणामों में उत्पाद ऑफ़र भी शामिल करते हैं।

खोज सेवा से मेरा तात्पर्य न केवल स्वयं खोज से है, बल्कि बाजार पर मौजूद सभी प्रस्तावों वाला एक डेटाबेस भी है। पैमाना यह है: प्रति दिन एक अरब से अधिक खोज अनुरोध संसाधित किए जाते हैं। और सब कुछ बिना किसी रुकावट के तेजी से काम करना चाहिए और हमेशा वांछित परिणाम देना चाहिए।

क्या है: बाजार वास्तुकला

मैं बाज़ार की वर्तमान संरचना का संक्षेप में वर्णन करूँगा। इसे नीचे दिए गए चित्र द्वारा मोटे तौर पर वर्णित किया जा सकता है:

मान लीजिए कि एक पार्टनर स्टोर हमारे पास आता है। वह कहता है कि मैं एक खिलौना बेचना चाहता हूं: चीखने वाली आवाज वाली यह दुष्ट बिल्ली। और एक और क्रोधित बिल्ली बिना चीं-चीं के। और बस एक बिल्ली. फिर स्टोर को ऑफ़र तैयार करने की ज़रूरत होती है जिसके लिए बाज़ार खोज करता है। स्टोर ऑफ़र के साथ एक विशेष एक्सएमएल तैयार करता है और संबद्ध इंटरफ़ेस के माध्यम से इस एक्सएमएल के पथ को संचारित करता है। इसके बाद इंडेक्सर समय-समय पर इस एक्सएमएल को डाउनलोड करता है, त्रुटियों की जांच करता है और सभी जानकारी को एक विशाल डेटाबेस में सहेजता है।

ऐसे कई सहेजे गए xml हैं। इस डेटाबेस से एक सर्च इंडेक्स बनाया जाता है। सूचकांक को आंतरिक प्रारूप में संग्रहीत किया जाता है। इंडेक्स बनाने के बाद, लेआउट सेवा इसे खोज सर्वर पर अपलोड करती है।

परिणामस्वरूप, चीख़ती हुई एक क्रोधित बिल्ली डेटाबेस में दिखाई देती है, और बिल्ली का सूचकांक सर्वर पर दिखाई देता है।

मैं आपको खोज वास्तुकला वाले भाग में बताऊंगा कि हम बिल्ली की खोज कैसे करते हैं।

बाज़ार खोज वास्तुकला

हम माइक्रोसर्विसेज की दुनिया में रहते हैं: हर आने वाला अनुरोध Market.yandex.ru बहुत सारी सबक्वेरीज़ का कारण बनता है, और उनके प्रसंस्करण में दर्जनों सेवाएँ शामिल होती हैं। आरेख केवल कुछ ही दिखाता है:

सरलीकृत अनुरोध प्रसंस्करण योजना

प्रत्येक सेवा में एक अद्भुत चीज़ होती है - एक अद्वितीय नाम के साथ उसका अपना बैलेंसर:

बैलेंसर हमें सेवा के प्रबंधन में अधिक लचीलापन देता है: उदाहरण के लिए, आप सर्वर को बंद कर सकते हैं, जो अक्सर अपडेट के लिए आवश्यक होता है। बैलेंसर देखता है कि सर्वर अनुपलब्ध है और स्वचालित रूप से अनुरोधों को अन्य सर्वर या डेटा केंद्रों पर रीडायरेक्ट करता है। किसी सर्वर को जोड़ते या हटाते समय, लोड स्वचालित रूप से सर्वरों के बीच पुनर्वितरित हो जाता है।

बैलेंसर का विशिष्ट नाम डेटा सेंटर पर निर्भर नहीं करता है। जब सेवा ए बी से अनुरोध करती है, तो डिफ़ॉल्ट बैलेंसर बी अनुरोध को वर्तमान डेटा सेंटर पर रीडायरेक्ट करता है। यदि सेवा अनुपलब्ध है या वर्तमान डेटा केंद्र में मौजूद नहीं है, तो अनुरोध अन्य डेटा केंद्रों पर पुनर्निर्देशित किया जाता है।

सभी डेटा केंद्रों के लिए एक एकल FQDN सेवा A को स्थानों से पूरी तरह से अलग होने की अनुमति देता है। सेवा बी के लिए उनके अनुरोध पर हमेशा कार्रवाई की जाएगी। अपवाद तब होता है जब सेवा सभी डेटा केंद्रों में स्थित होती है।

लेकिन इस बैलेंसर के साथ सब कुछ इतना अच्छा नहीं है: हमारे पास एक अतिरिक्त मध्यवर्ती घटक है। बैलेंसर अस्थिर हो सकता है, और यह समस्या अनावश्यक सर्वर द्वारा हल की जाती है। सेवाओं ए और बी के बीच अतिरिक्त विलंब भी है। लेकिन व्यवहार में यह 1 एमएस से कम है और अधिकांश सेवाओं के लिए यह महत्वपूर्ण नहीं है।

अप्रत्याशित से निपटना: खोज सेवा संतुलन और लचीलापन

कल्पना कीजिए कि एक पतन हुआ है: आपको एक चीख़ने वाली बिल्ली को खोजने की ज़रूरत है, लेकिन सर्वर क्रैश हो जाता है। या 100 सर्वर. कैसे बाहर निकलें? क्या हम वास्तव में उपयोगकर्ता को बिल्ली के बिना छोड़ने जा रहे हैं?

स्थिति डरावनी है, लेकिन हम इसके लिए तैयार हैं. मैं आपको क्रम से बताऊंगा.

खोज अवसंरचना कई डेटा केंद्रों में स्थित है:

डिज़ाइन करते समय, हम एक डेटा सेंटर को बंद करने की संभावना को शामिल करते हैं। जीवन आश्चर्यों से भरा है - उदाहरण के लिए, एक खुदाई करने वाला भूमिगत केबल काट सकता है (हाँ, ऐसा हुआ)। शेष डेटा केंद्रों की क्षमता पीक लोड झेलने के लिए पर्याप्त होनी चाहिए।

आइए एकल डेटा सेंटर पर विचार करें। प्रत्येक डेटा सेंटर में समान बैलेंसर ऑपरेशन योजना होती है:

एक बैलेंसर कम से कम तीन भौतिक सर्वर होता है। यह अतिरेक विश्वसनीयता के लिए बनाया गया है। बैलेंसर्स HAProx पर चलते हैं।

हमने HAProx को उसके उच्च प्रदर्शन, कम संसाधन आवश्यकताओं और व्यापक कार्यक्षमता के कारण चुना। हमारा खोज सॉफ़्टवेयर प्रत्येक सर्वर के अंदर चलता है।

एक सर्वर के विफल होने की संभावना कम है। लेकिन यदि आपके पास कई सर्वर हैं, तो कम से कम एक के बंद होने की संभावना बढ़ जाती है।

वास्तविकता में यही होता है: सर्वर क्रैश हो जाते हैं। इसलिए, सभी सर्वरों की स्थिति की लगातार निगरानी करना आवश्यक है। यदि सर्वर प्रत्युत्तर देना बंद कर देता है, तो यह स्वचालित रूप से ट्रैफ़िक से डिस्कनेक्ट हो जाता है। इस प्रयोजन के लिए, HAProxy में एक अंतर्निहित स्वास्थ्य जांच है। यह एक सेकंड में एक बार HTTP अनुरोध "/पिंग" के साथ सभी सर्वरों पर जाता है।

HAProxy की एक अन्य विशेषता: एजेंट-चेक आपको सभी सर्वरों को समान रूप से लोड करने की अनुमति देता है। ऐसा करने के लिए, HAProxy सभी सर्वरों से जुड़ता है, और वे वर्तमान लोड के आधार पर 1 से 100 तक अपना वजन लौटाते हैं। वजन की गणना प्रसंस्करण के लिए कतार में अनुरोधों की संख्या और प्रोसेसर पर लोड के आधार पर की जाती है।

अब बिल्ली को ढूंढने के बारे में। खोज के परिणामस्वरूप ऐसे अनुरोध प्राप्त होते हैं: /खोज?पाठ=गुस्सा+बिल्ली. खोज तेज़ होने के लिए, संपूर्ण कैट इंडेक्स को RAM में फ़िट होना चाहिए। यहां तक ​​कि SSD से पढ़ना भी पर्याप्त तेज़ नहीं है।

एक समय, ऑफ़र डेटाबेस छोटा था, और एक सर्वर की रैम इसके लिए पर्याप्त थी। जैसे-जैसे ऑफ़र बेस बढ़ता गया, सब कुछ अब इस रैम में फिट नहीं होता, और डेटा दो भागों में विभाजित हो गया: शार्ड 1 और शार्ड 2।

लेकिन ऐसा हमेशा होता है: कोई भी समाधान, यहां तक ​​कि एक अच्छा समाधान भी, अन्य समस्याओं को जन्म देता है।

बैलेंसर अभी भी किसी भी सर्वर पर गया। लेकिन जिस मशीन पर रिक्वेस्ट आई, वहां इंडेक्स आधा ही था। बाकी अन्य सर्वर पर था. इसलिए, सर्वर को किसी पड़ोसी मशीन पर जाना पड़ा। दोनों सर्वरों से डेटा प्राप्त करने के बाद, परिणामों को संयोजित किया गया और पुन: रैंक किया गया।

चूंकि बैलेंसर अनुरोधों को समान रूप से वितरित करता है, सभी सर्वर केवल डेटा भेजने के बजाय, पुन: रैंकिंग में लगे हुए थे।

यदि कोई पड़ोसी सर्वर अनुपलब्ध था तो समस्या उत्पन्न हुई। समाधान विभिन्न प्राथमिकताओं वाले कई सर्वरों को "पड़ोसी" सर्वर के रूप में निर्दिष्ट करना था। सबसे पहले, अनुरोध वर्तमान रैक में सर्वर को भेजा गया था। यदि कोई प्रतिक्रिया नहीं हुई, तो अनुरोध इस डेटा सेंटर के सभी सर्वरों को भेजा गया था। और अंत में, अनुरोध अन्य डेटा केंद्रों पर चला गया।
जैसे-जैसे प्रस्तावों की संख्या बढ़ती गई, डेटा को चार भागों में विभाजित किया गया। लेकिन यह सीमा नहीं थी.

वर्तमान में, आठ शार्डों के विन्यास का उपयोग किया जाता है। इसके अलावा, और भी अधिक मेमोरी बचाने के लिए, सूचकांक को एक खोज भाग (जिसका उपयोग खोज के लिए किया जाता है) और एक स्निपेट भाग (जो खोज में शामिल नहीं है) में विभाजित किया गया था।

एक सर्वर में केवल एक शार्ड की जानकारी होती है। इसलिए, पूर्ण सूचकांक खोजने के लिए, आपको अलग-अलग शार्क वाले आठ सर्वरों पर खोज करनी होगी।

सर्वरों को समूहों में समूहीकृत किया गया है। प्रत्येक क्लस्टर में आठ खोज इंजन और एक स्निपेट सर्वर होता है।

स्निपेट सर्वर स्थिर डेटा के साथ एक कुंजी-मूल्य डेटाबेस चलाता है। दस्तावेज़ जारी करने के लिए उनकी आवश्यकता होती है, उदाहरण के लिए, चीख़ती हुई बिल्ली का विवरण। डेटा को विशेष रूप से एक अलग सर्वर पर स्थानांतरित किया जाता है ताकि खोज सर्वर की मेमोरी लोड न हो।

चूंकि दस्तावेज़ आईडी केवल एक सूचकांक के भीतर अद्वितीय हैं, ऐसी स्थिति उत्पन्न हो सकती है जहां स्निपेट में कोई दस्तावेज़ नहीं हैं। खैर, या कि एक आईडी के लिए अलग-अलग सामग्री होगी। इसलिए, खोज को कार्यान्वित करने और परिणाम वापस पाने के लिए, पूरे क्लस्टर में एकरूपता की आवश्यकता थी। मैं आपको नीचे बताऊंगा कि हम निरंतरता की निगरानी कैसे करते हैं।

खोज स्वयं इस प्रकार संरचित है: एक खोज अनुरोध आठ सर्वरों में से किसी पर भी आ सकता है। मान लीजिए कि वह सर्वर 1 पर आया। यह सर्वर सभी तर्कों को संसाधित करता है और समझता है कि क्या और कैसे देखना है। आने वाले अनुरोध के आधार पर, सर्वर आवश्यक जानकारी के लिए बाहरी सेवाओं से अतिरिक्त अनुरोध कर सकता है। एक अनुरोध के बाद बाहरी सेवाओं के लिए अधिकतम दस अनुरोध किए जा सकते हैं।

आवश्यक जानकारी एकत्र करने के बाद, ऑफ़र डेटाबेस में खोज शुरू होती है। ऐसा करने के लिए, क्लस्टर के सभी आठ सर्वरों पर सबक्वेरीज़ बनाई जाती हैं।

एक बार प्रतिक्रियाएँ प्राप्त हो जाने के बाद, परिणाम संयुक्त हो जाते हैं। अंत में, परिणाम उत्पन्न करने के लिए स्निपेट सर्वर पर कई और सबक्वेरीज़ की आवश्यकता हो सकती है।

क्लस्टर के भीतर खोज क्वेरी इस प्रकार दिखती हैं: /shard1?text=गुस्सा+बिल्ली. इसके अलावा, फॉर्म की सबक्वेरीज़ क्लस्टर के भीतर सभी सर्वरों के बीच प्रति सेकंड एक बार लगातार बनाई जाती हैं: /दर्जा.

जांच /दर्जा ऐसी स्थिति का पता लगाता है जहां सर्वर उपलब्ध नहीं है।

यह यह भी नियंत्रित करता है कि खोज इंजन संस्करण और इंडेक्स संस्करण सभी सर्वरों पर समान हैं, अन्यथा क्लस्टर के भीतर असंगत डेटा होगा।

इस तथ्य के बावजूद कि एक स्निपेट सर्वर आठ खोज इंजनों से अनुरोधों को संसाधित करता है, इसका प्रोसेसर बहुत हल्के ढंग से लोड होता है। इसलिए, अब हम स्निपेट डेटा को एक अलग सेवा में स्थानांतरित कर रहे हैं।

डेटा स्थानांतरित करने के लिए, हमने दस्तावेज़ों के लिए सार्वभौमिक कुंजियाँ पेश कीं। अब ऐसी स्थिति असंभव है जहां एक कुंजी का उपयोग करके दूसरे दस्तावेज़ की सामग्री वापस की जाती है।

लेकिन दूसरी वास्तुकला में परिवर्तन अभी पूरा नहीं हुआ है। अब हम डेडिकेटेड स्निपेट सर्वर से छुटकारा पाना चाहते हैं। और फिर क्लस्टर संरचना से पूरी तरह दूर चले जाएं। इससे हम आसानी से आगे बढ़ना जारी रख सकेंगे। एक अतिरिक्त बोनस लोहे की महत्वपूर्ण बचत है।

और अब सुखद अंत वाली डरावनी कहानियाँ। आइए सर्वर अनुपलब्धता के कई मामलों पर विचार करें।

कुछ भयानक हुआ: एक सर्वर अनुपलब्ध है

मान लीजिए कि एक सर्वर अनुपलब्ध है। फिर क्लस्टर में शेष सर्वर प्रतिक्रिया देना जारी रख सकते हैं, लेकिन खोज परिणाम अधूरे होंगे।

स्थिति जांच के माध्यम से /दर्जा पड़ोसी सर्वर समझते हैं कि कोई उपलब्ध नहीं है। इसलिए, पूर्णता बनाए रखने के लिए, क्लस्टर में सभी सर्वर प्रति अनुरोध /गुनगुनाहट वे बैलेंसर को जवाब देना शुरू कर देते हैं कि वे भी अनुपलब्ध हैं। यह पता चला कि क्लस्टर के सभी सर्वर मर गए (जो सच नहीं है)। यह हमारी क्लस्टर योजना का मुख्य दोष है - इसीलिए हम इससे दूर जाना चाहते हैं।

त्रुटि के साथ विफल होने वाले अनुरोध बैलेंसर द्वारा अन्य सर्वर पर दोबारा भेजे जाते हैं।
बैलेंसर उपयोगकर्ता ट्रैफ़िक को मृत सर्वर पर भेजना भी बंद कर देता है, लेकिन उनकी स्थिति की जाँच करना जारी रखता है।

जब सर्वर उपलब्ध हो जाता है, तो यह प्रतिक्रिया देना शुरू कर देता है /गुनगुनाहट. जैसे ही मृत सर्वर से पिंग पर सामान्य प्रतिक्रियाएं आने लगती हैं, बैलेंसर्स वहां उपयोगकर्ता ट्रैफ़िक भेजना शुरू कर देते हैं। क्लस्टर संचालन बहाल हो गया है, हुर्रे।

इससे भी बदतर: कई सर्वर अनुपलब्ध हैं

डेटा सेंटर में सर्वरों का एक महत्वपूर्ण हिस्सा कट गया है। क्या करें, कहां भागें? बैलेंसर फिर से बचाव के लिए आता है। प्रत्येक बैलेंसर लगातार लाइव सर्वर की वर्तमान संख्या को मेमोरी में संग्रहीत करता है। यह लगातार ट्रैफ़िक की अधिकतम मात्रा की गणना करता है जिसे वर्तमान डेटा सेंटर संसाधित कर सकता है।

जब एक डेटा सेंटर में कई सर्वर डाउन हो जाते हैं, तो बैलेंसर को पता चलता है कि यह डेटा सेंटर सभी ट्रैफ़िक को प्रोसेस नहीं कर सकता है।

फिर अतिरिक्त ट्रैफ़िक अन्य डेटा केंद्रों पर बेतरतीब ढंग से वितरित होना शुरू हो जाता है। सब कुछ काम करता है, हर कोई खुश है।

हम यह कैसे करते हैं: विज्ञप्तियाँ प्रकाशित करना

अब बात करते हैं कि हम सेवा में किए गए परिवर्तनों को कैसे प्रकाशित करते हैं। यहां हमने प्रक्रियाओं को सरल बनाने का मार्ग अपनाया है: एक नई रिलीज़ को रोल आउट करना लगभग पूरी तरह से स्वचालित है।
जब प्रोजेक्ट में एक निश्चित संख्या में परिवर्तन जमा हो जाते हैं, तो एक नई रिलीज़ स्वचालित रूप से बन जाती है और उसका निर्माण शुरू हो जाता है।

फिर सेवा को परीक्षण के लिए शुरू किया जाता है, जहां संचालन की स्थिरता की जांच की जाती है।

उसी समय, स्वचालित प्रदर्शन परीक्षण लॉन्च किया गया है। इसे एक विशेष सेवा द्वारा नियंत्रित किया जाता है। मैं अभी इसके बारे में बात नहीं करूंगा - इसका विवरण एक अलग लेख के योग्य है।

यदि परीक्षण में प्रकाशन सफल होता है, तो प्रीस्टेबल में रिलीज़ का प्रकाशन स्वचालित रूप से शुरू हो जाता है। प्रेस्टेबल एक विशेष क्लस्टर है जहां सामान्य उपयोगकर्ता ट्रैफ़िक को निर्देशित किया जाता है। यदि यह कोई त्रुटि लौटाता है, तो बैलेंसर उत्पादन के लिए पुनः अनुरोध करता है।

प्रीस्टेबल में, प्रतिक्रिया समय को मापा जाता है और उत्पादन में पिछली रिलीज के साथ तुलना की जाती है। यदि सब कुछ ठीक है, तो एक व्यक्ति कनेक्ट होता है: लोड परीक्षण के ग्राफ़ और परिणामों की जांच करता है और फिर उत्पादन शुरू करता है।

उपयोगकर्ता को शुभकामनाएँ: ए/बी परीक्षण

यह हमेशा स्पष्ट नहीं होता है कि किसी सेवा में परिवर्तन से वास्तविक लाभ होगा या नहीं। परिवर्तनों की उपयोगिता को मापने के लिए, लोग ए/बी परीक्षण लेकर आए। मैं आपको थोड़ा बताऊंगा कि यह Yandex.Market खोज में कैसे काम करता है।

यह सब एक नए सीजीआई पैरामीटर को जोड़ने से शुरू होता है जो नई कार्यक्षमता को सक्षम बनाता है। मान लीजिए हमारा पैरामीटर है: बाज़ार_नई_कार्यक्षमता=1. यदि ध्वज मौजूद है तो कोड में हम इस कार्यक्षमता को सक्षम करते हैं:

If (cgi.experiments.market_new_functionality) {
// enable new functionality
}

उत्पादन के लिए नई कार्यक्षमता शुरू की जा रही है.

ए/बी परीक्षण को स्वचालित करने के लिए, एक समर्पित सेवा है जो विस्तृत जानकारी प्रदान करती है यहाँ वर्णित है. सेवा में एक प्रयोग बनाया गया है. उदाहरण के लिए, ट्रैफ़िक हिस्सेदारी 15% निर्धारित है। प्रतिशत प्रश्नों के लिए नहीं, बल्कि उपयोगकर्ताओं के लिए निर्धारित किए गए हैं। प्रयोग की अवधि भी इंगित की गई है, उदाहरण के लिए, एक सप्ताह।

एक साथ कई प्रयोग चलाए जा सकते हैं. सेटिंग्स में आप निर्दिष्ट कर सकते हैं कि क्या अन्य प्रयोगों के साथ प्रतिच्छेदन संभव है।

परिणामस्वरूप, सेवा स्वचालित रूप से एक तर्क जोड़ती है बाज़ार_नई_कार्यक्षमता=1 15% उपयोगकर्ताओं के लिए. यह स्वचालित रूप से चयनित मेट्रिक्स की गणना भी करता है। प्रयोग पूरा होने के बाद, विश्लेषक परिणामों को देखते हैं और निष्कर्ष निकालते हैं। निष्कर्षों के आधार पर, उत्पादन या शोधन शुरू करने का निर्णय लिया जाता है।

बाज़ार का चतुर हाथ: उत्पादन में परीक्षण

अक्सर ऐसा होता है कि आपको उत्पादन में एक नई कार्यक्षमता के संचालन का परीक्षण करने की आवश्यकता होती है, लेकिन आप निश्चित नहीं हैं कि यह भारी भार के तहत "मुकाबला" स्थितियों में कैसे व्यवहार करेगा।

एक समाधान है: सीजीआई मापदंडों में झंडे का उपयोग न केवल ए/बी परीक्षण के लिए किया जा सकता है, बल्कि नई कार्यक्षमता का परीक्षण करने के लिए भी किया जा सकता है।

हमने एक उपकरण बनाया है जो आपको सेवा को जोखिम में डाले बिना हजारों सर्वरों पर कॉन्फ़िगरेशन को तुरंत बदलने की अनुमति देता है। इसे स्टॉप टैप कहा जाता है. मूल विचार लेआउट के बिना कुछ कार्यक्षमता को शीघ्रता से अक्षम करने में सक्षम होना था। फिर उपकरण का विस्तार हुआ और अधिक जटिल हो गया।

सेवा प्रवाह आरेख नीचे प्रस्तुत किया गया है:

ध्वज मान एपीआई के माध्यम से निर्धारित किए जाते हैं। प्रबंधन सेवा इन मानों को डेटाबेस में संग्रहीत करती है। सभी सर्वर हर दस सेकंड में एक बार डेटाबेस पर जाते हैं, फ़्लैग मानों को पंप करते हैं और इन मानों को प्रत्येक अनुरोध पर लागू करते हैं।

स्टॉप टैप में आप दो प्रकार के मान सेट कर सकते हैं:

1) सशर्त अभिव्यक्तियाँ। जब कोई एक मान सत्य हो तो लागू करें। उदाहरण के लिए:

{
	"condition":"IS_DC1",
	"value":"3",
}, 
{
	"condition": "CLUSTER==2 and IS_BERU", 
	"value": "4!" 
}

मान "3" तब लागू किया जाएगा जब अनुरोध स्थान DC1 में संसाधित किया जाएगा। और जब beru.ru साइट के लिए दूसरे क्लस्टर पर अनुरोध संसाधित किया जाता है तो मान "4" होता है।

2) बिना शर्त मूल्य। यदि कोई भी शर्त पूरी नहीं होती तो डिफ़ॉल्ट रूप से आवेदन करें। उदाहरण के लिए:

मूल्य, मूल्य!

यदि कोई मान विस्मयादिबोधक बिंदु के साथ समाप्त होता है, तो उसे उच्च प्राथमिकता दी जाती है।

सीजीआई पैरामीटर पार्सर यूआरएल को पार्स करता है। फिर स्टॉप टैप से मान लागू करता है।

निम्नलिखित प्राथमिकताओं वाले मान लागू किए जाते हैं:

1. स्टॉप टैप (विस्मयादिबोधक चिह्न) से बढ़ी हुई प्राथमिकता के साथ।
2. अनुरोध से मूल्य.
3. स्टॉप टैप से डिफ़ॉल्ट मान.
4. कोड में डिफ़ॉल्ट मान.

ऐसे कई झंडे हैं जो सशर्त मूल्यों में दर्शाए गए हैं - वे हमें ज्ञात सभी परिदृश्यों के लिए पर्याप्त हैं:

• डेटा सेंटर।
• पर्यावरण: उत्पादन, परीक्षण, छाया।
• स्थान: बाजार, बेरू.
• क्लस्टर संख्या.

इस टूल से, आप सर्वर के एक निश्चित समूह पर (उदाहरण के लिए, केवल एक डेटा सेंटर में) नई कार्यक्षमता सक्षम कर सकते हैं और संपूर्ण सेवा के लिए किसी विशेष जोखिम के बिना इस कार्यक्षमता के संचालन का परीक्षण कर सकते हैं। भले ही आपने कहीं कोई गंभीर गलती की हो, सब कुछ गिरना शुरू हो गया हो और पूरा डेटा सेंटर बंद हो गया हो, बैलेंसर अनुरोधों को अन्य डेटा केंद्रों पर रीडायरेक्ट कर देंगे। अंतिम उपयोगकर्ताओं को कुछ भी नज़र नहीं आएगा.

यदि आपको कोई समस्या दिखाई देती है, तो आप तुरंत ध्वज को उसके पिछले मान पर लौटा सकते हैं और परिवर्तन वापस ले लिए जाएंगे।

इस सेवा के अपने नकारात्मक पक्ष भी हैं: डेवलपर्स इसे बहुत पसंद करते हैं और अक्सर सभी परिवर्तनों को स्टॉप टैप में डालने का प्रयास करते हैं। हम दुरुपयोग से निपटने की कोशिश कर रहे हैं।

स्टॉप टैप दृष्टिकोण तब अच्छी तरह से काम करता है जब आपके पास पहले से ही स्थिर कोड उत्पादन के लिए तैयार हो। साथ ही, आपको अभी भी संदेह है, और आप "मुकाबला" स्थितियों में कोड की जांच करना चाहते हैं।

हालाँकि, स्टॉप टैप विकास के दौरान परीक्षण के लिए उपयुक्त नहीं है। डेवलपर्स के लिए एक अलग क्लस्टर है जिसे "शैडो क्लस्टर" कहा जाता है।

गुप्त परीक्षण: छाया समूह

किसी एक क्लस्टर से अनुरोध छाया क्लस्टर में डुप्लिकेट किए जाते हैं। लेकिन बैलेंसर इस क्लस्टर से मिलने वाली प्रतिक्रियाओं को पूरी तरह से नजरअंदाज कर देता है। इसके संचालन का आरेख नीचे प्रस्तुत किया गया है।

हमें एक परीक्षण क्लस्टर मिलता है जो वास्तविक "मुकाबला" स्थितियों में है। सामान्य उपयोगकर्ता ट्रैफ़िक वहां जाता है. दोनों क्लस्टर में हार्डवेयर समान है, इसलिए प्रदर्शन और त्रुटियों की तुलना की जा सकती है।

और चूंकि बैलेंसर प्रतिक्रियाओं को पूरी तरह से नजरअंदाज कर देता है, अंतिम उपयोगकर्ताओं को छाया क्लस्टर से प्रतिक्रियाएं नहीं दिखेंगी। इसलिए, गलती करना डरावना नहीं है।

निष्कर्ष

तो, हमने बाज़ार खोज कैसे बनाई?

सब कुछ सुचारू रूप से चलाने के लिए, हम कार्यक्षमता को अलग-अलग सेवाओं में विभाजित करते हैं। इस तरह हम केवल उन्हीं घटकों को स्केल कर सकते हैं जिनकी हमें आवश्यकता है और घटकों को सरल बना सकते हैं। किसी अन्य टीम को एक अलग घटक सौंपना और उस पर काम करने की ज़िम्मेदारियाँ साझा करना आसान है। और इस दृष्टिकोण के साथ लोहे में महत्वपूर्ण बचत एक स्पष्ट प्लस है।

शैडो क्लस्टर भी हमारी मदद करता है: हम सेवाएं विकसित कर सकते हैं, प्रक्रिया में उनका परीक्षण कर सकते हैं और उपयोगकर्ता को परेशान नहीं कर सकते।

खैर, निश्चित रूप से उत्पादन में परीक्षण। हजारों सर्वरों पर कॉन्फ़िगरेशन बदलने की आवश्यकता है? आसान, स्टॉप टैप का उपयोग करें। इस तरह आप तुरंत एक तैयार जटिल समाधान तैयार कर सकते हैं और समस्या आने पर स्थिर संस्करण में वापस ला सकते हैं।

मुझे आशा है कि मैं यह दिखाने में सक्षम था कि हम ऑफ़र के बढ़ते आधार के साथ बाज़ार को कैसे तेज़ और स्थिर बनाते हैं। हम सर्वर समस्याओं को कैसे हल करते हैं, बड़ी संख्या में अनुरोधों से निपटते हैं, सेवा के लचीलेपन में सुधार करते हैं और कार्य प्रक्रियाओं को बाधित किए बिना ऐसा करते हैं।

स्रोत: www.habr.com