हमने विज्ञापन विचारों का तेज़ और विश्वसनीय भंडार कैसे बनाया

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



कुल में, सेवा प्रक्रियाएं ~ 300 हजार रीड रिक्वेस्ट और ~ 9 हजार प्रति मिनट रिक्वेस्ट लिखती हैं, जिनमें से 99% को 5ms तक निष्पादित किया जाता है। ये निश्चित रूप से, खगोलीय संकेतक नहीं हैं और मंगल ग्रह पर रॉकेटों का प्रक्षेपण नहीं है - लेकिन यह भी इतना मामूली काम नहीं है क्योंकि संख्याओं का सरल भंडारण प्रतीत हो सकता है। यह पता चला कि दोषरहित डेटा भंडारण सुनिश्चित करने और सुसंगत, प्रासंगिक मूल्यों को पढ़ने के लिए यह सब करना, कुछ प्रयास की आवश्यकता है, जिसके बारे में हम नीचे चर्चा करेंगे।

प्रोजेक्ट कार्य और अवलोकन

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

सामान्य तौर पर, परियोजना की कार्यक्षमता और सिद्धांत इस तरह दिखते हैं:

• वेब पेज या एप्लिकेशन स्क्रीन विज्ञापन देखने वाले काउंटरों के पीछे एक अनुरोध करता है (अनुरोध आम तौर पर बुनियादी जानकारी के उत्पादन को प्राथमिकता देने के लिए अतुल्यकालिक है)। और यदि विज्ञापन का पृष्ठ स्वयं प्रदर्शित होता है, तो ग्राहक आपसे अपडेट की गई राशि को देखने और वापस करने के लिए कहेंगे।
• रीड रिक्वेस्ट को संसाधित करके, सेवा रेडिस कैश से जानकारी प्राप्त करने की कोशिश करती है, और MongoDB के लिए अनुरोध पूरा करके अज्ञात को पूरक करती है।
• मूली में 2 संरचनाएं लिखें अनुरोध भेजे गए हैं: वृद्धिशील अद्यतन कतार (पृष्ठभूमि में संसाधित, अतुल्यकालिक) और कुल विचारों की संख्या।
• उसी सेवा में एक पृष्ठभूमि प्रक्रिया कतार से तत्वों को पढ़ती है, उन्हें स्थानीय बफर में जमा करती है, और समय-समय पर इसे MongoDB को लिखती है।

रिकॉर्ड देखें काउंटर: नुकसान

यद्यपि ऊपर वर्णित चरण काफी सरल दिखते हैं, यहाँ समस्या डेटाबेस और माइक्रोसेवा इंस्टेंस के बीच बातचीत का संगठन है ताकि डेटा खो न जाए, डुप्लिकेट न हो, और पिछड़ न जाए।

केवल एक रिपॉजिटरी का उपयोग करना (उदाहरण के लिए, केवल MongoDB) इन समस्याओं में से कुछ को हल करेगा। वास्तव में, सेवा पहले काम करती थी, जब तक कि हम स्केलिंग, स्थिरता और गति की समस्याओं के खिलाफ नहीं आए।

स्टोरेज के बीच बढ़ते डेटा का एक भोली कार्यान्वयन, उदाहरण के लिए, ऐसी विसंगतियों को जन्म दे सकता है:

• प्रतिस्पर्धात्मक कैश के दौरान डेटा की हानि:
  
  1. प्रोसेस ए रेडिस कैश में विचारों की संख्या को बढ़ाता है, लेकिन यह पता चलता है कि इस इकाई के लिए अभी भी कोई डेटा नहीं है (यह या तो एक नई घोषणा हो सकती है या एक पुरानी हो सकती है जिसे कैश से बाहर निकाला गया है), इसलिए प्रक्रिया को पहले MongoDB के लिए यह मान प्राप्त करना होगा।
     
  2. प्रक्रिया A को MongoDB से दृश्य गणना मिलती है - उदाहरण के लिए, संख्या 5; फिर इसमें 1 जोड़ता है और Redis 6 को लिखने जा रहा है।
  3. प्रक्रिया बी (साइट के किसी अन्य उपयोगकर्ता द्वारा, जिसने एक ही विज्ञापन में प्रवेश किया है) शुरू (कहते हैं, एक साथ) एक ही करता है।
  4. प्रोसेस ए 6 से रेडिस का मान लिखता है।
  5. प्रोसेस बी 6 से रेडिस का मान लिखता है।
  6. नतीजतन, डेटा रिकॉर्ड करते समय दौड़ के कारण एक दृश्य खो जाता है।
     परिदृश्य इतना संभावना नहीं है: उदाहरण के लिए, हमारे पास एक भुगतान सेवा है जो साइट के मुख्य पृष्ठ पर एक विज्ञापन रखती है। एक नई घोषणा के लिए, इस तरह की घटनाओं के कारण एक बार में कई विचारों की हानि हो सकती है क्योंकि उनकी अचानक आमद होती है।
• Redis से MongoDb पर विचार करते समय एक अन्य परिदृश्य का एक उदाहरण डेटा हानि है:
  
  
  1. प्रक्रिया रेडिस से एक लंबित मूल्य उठाती है और इसे बाद में MongoDB को लिखने के लिए स्मृति में संग्रहीत करती है।
  2. एक लिखित अनुरोध विफल हो जाता है (या प्रक्रिया निष्पादित होने से पहले दुर्घटनाग्रस्त हो जाती है)।
  3. डेटा फिर से खो जाता है, जो स्पष्ट हो जाएगा कि अगली बार कैश्ड मान को बाहर धकेल दिया गया है और डेटाबेस से मूल्य के साथ बदल दिया गया है।
  
  

अन्य त्रुटियां हो सकती हैं, जिनके कारण डेटाबेस के बीच गैर-परमाणु प्रकृति के कार्यों में भी निहित हैं, उदाहरण के लिए, एक ही इकाई के विचारों को हटाने और बढ़ाने के दौरान एक संघर्ष।

रिकॉर्डिंग दृश्य गणना: समाधान

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

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

1. जब एक लिखित अनुरोध माइक्रोसर्विस में आता है, तो यह काउंटर स्क्रिप्ट को बढ़ाने के लिए lua स्क्रिप्ट IncrementIfExists चलाता है, अगर यह कैश में पहले से मौजूद है। यदि मूली में देखी गई इकाई के लिए कोई डेटा नहीं है, तो स्क्रिप्ट तुरंत -1 लौटती है; अन्यथा, यह HINCRBY के माध्यम से कैश में विचारों के मूल्य को बढ़ाता है , घटना को MongoDB में बाद के भंडारण के लिए कतार में जोड़ता है (जिसे हमारे द्वारा लंबित कतार कहा जाता है), LPUSH के माध्यम से, और अद्यतित मात्रा में दृश्य देता है।
   
2. यदि IncrementIfExists एक सकारात्मक संख्या देता है, तो यह मान क्लाइंट को वापस कर दिया जाता है और अनुरोध समाप्त हो जाता है।
   
   अन्यथा, माइक्रोसेव ने MongoDb से व्यू काउंटर को उठाया, इसे 1 से बढ़ाकर मूली को भेज दिया।
   
3. मूली के लिए लेखन एक अन्य लुआ लिपि के माध्यम से किया जाता है - उपर - जो कि कैश की कुल संख्या को बचाता है यदि यह अभी भी खाली है, या 1 से उन्हें बढ़ाता है यदि कोई व्यक्ति चरण 1 और 3 के बीच कैश को भरने में कामयाब होता है।
   
4. उपेंडर लंबित कतार में एक दृश्य घटना भी जोड़ता है, और एक अद्यतन राशि लौटाता है, जिसे बाद में ग्राहक को भेजा जाता है।
   

इस तथ्य के कारण कि लुआ लिपियों को परमाणु रूप से निष्पादित किया जाता है , हम कई संभावित समस्याओं से बचते हैं जो प्रतिस्पर्धी लेखन के कारण हो सकते हैं।

एक अन्य महत्वपूर्ण विवरण लंबित कतार से MongoDB तक अद्यतनों के सुरक्षित हस्तांतरण को सुनिश्चित कर रहा है। ऐसा करने के लिए, हमने रेडिस प्रलेखन में वर्णित "विश्वसनीय कतार" टेम्पलेट का उपयोग किया, जो कि एक अलग, दूसरी कतार में संसाधित वस्तुओं की एक प्रति बनाकर डेटा हानि की संभावना को काफी कम कर देता है जब तक कि वे अंततः एक स्थिर भंडारण में संग्रहीत नहीं हो जाते हैं।

पूरी प्रक्रिया के चरणों को बेहतर ढंग से समझने के लिए, हमने एक छोटा सा दृश्य तैयार किया है। सबसे पहले, आइए एक सामान्य, सफल परिदृश्य देखें (ऊपरी दाएं कोने में चरणों को गिना गया है और नीचे विस्तार से वर्णित किया गया है):

1. Microservice को एक लिखित अनुरोध प्राप्त होता है
2. अनुरोध हैंडलर इसे एक लुआ-स्क्रिप्ट में भेजता है जो कैश को लुकअप लिखता है (तुरंत इसे पठनीय बनाता है) और आगे की प्रक्रिया के लिए कतार में।
3. बैकग्राउंड गोरोइन (समय-समय पर) BRPopLPush ऑपरेशन करता है, जो एक तत्व को एक कतार से दूसरी कतार में ले जाता है (हम इसे "प्रोसेसिंग कतार" कहते हैं - वर्तमान में संसाधित तत्वों के साथ एक कतार)। एक ही तत्व तब प्रक्रिया मेमोरी में एक बफर में संग्रहीत किया जाता है।
   
4. एक अन्य लिखित अनुरोध आता है और संसाधित किया जा रहा है, जो हमें बफर में 2 तत्वों और प्रसंस्करण कतार में 2 तत्वों के साथ छोड़ देता है।
5. कुछ समय समाप्त होने के बाद, पृष्ठभूमि प्रक्रिया MongoDB में बफर को फ्लश करने का निर्णय लेती है। बफर से कई मान लिखना एक अनुरोध द्वारा किया जाता है, जो सकारात्मक रूप से थ्रूपुट को प्रभावित करता है। साथ ही, रिकॉर्डिंग से पहले, प्रक्रिया कई विचारों को एक में मिलाने की कोशिश करती है, वही विज्ञापनों के लिए उनके मूल्यों को जोड़ देती है।
   हमारी प्रत्येक परियोजना पर, 3 माइक्रोसर्विस इंस्टेंस का उपयोग किया जाता है, प्रत्येक अपने स्वयं के बफर के साथ, जो हर 2 सेकंड में डेटाबेस में सहेजा जाता है। इस समय के दौरान, एक बफर में लगभग 100 तत्व जमा होते हैं।
   
6. एक सफल लेखन के बाद, प्रक्रिया प्रसंस्करण कतार से आइटम निकालती है, यह दर्शाता है कि प्रसंस्करण सफलतापूर्वक पूरा हो गया है।
   

जब सभी सबसिस्टम क्रम में होते हैं, तो इनमें से कुछ चरण निरर्थक लग सकते हैं। और चौकस पाठक के पास एक सवाल भी हो सकता है कि निचले बाएं कोने में सो रहा गोफर क्या करता है।
जब MongoDB उपलब्ध नहीं है तो परिदृश्य पर विचार करते समय सब कुछ समझाया गया है:

1. पहला चरण पिछले परिदृश्य से घटनाओं के समान है: सेवा को विचारों को रिकॉर्ड करने और उन्हें संसाधित करने के लिए 2 अनुरोध प्राप्त होते हैं।
   
2. प्रक्रिया MongoDB के साथ कनेक्शन खो देती है (प्रक्रिया स्वयं, ज़ाहिर है, इस बारे में अभी तक नहीं जानती है)।
   गोरुटिन हैंडलर, पहले की तरह, डेटाबेस में अपने बफर को फ्लश करने की कोशिश कर रहा है - लेकिन इस बार सफलता के बिना। वह अगली यात्रा की प्रतीक्षा कर रही है।
   
3. एक अन्य पृष्ठभूमि गोरोइन उठता है और प्रसंस्करण कतार की जांच करता है। वह जानती है कि तत्वों को उसके साथ बहुत पहले जोड़ा गया था; यह निष्कर्ष निकालते हुए कि उनका प्रसंस्करण विफल रहा, वह उन्हें लंबित कतार में वापस ले जाती है।
   
4. थोड़ी देर के बाद, MongoDB के साथ कनेक्शन बहाल हो जाता है।
   
5. पहला बैकग्राउंड गोरोइन फिर से एक लेखन ऑपरेशन करने की कोशिश करता है - इस बार सफलतापूर्वक - और अंततः स्थायी रूप से प्रसंस्करण कतार से आइटम निकालता है।
   

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

सख्ती से बोलना, यहां तक ​​कि ये उपाय सैद्धांतिक रूप से प्रमाणित गारंटी प्रदान नहीं करते हैं (उदाहरण के लिए, हम 15 मिनट के लिए प्रक्रिया फ़्रीज जैसे परिदृश्यों की उपेक्षा करते हैं) - लेकिन व्यवहार में यह काफी मज़बूती से काम करता है।

इस योजना में भी कम से कम 2 और कमजोरियां हैं जो हमारे लिए ज्ञात हैं जिनका पता होना महत्वपूर्ण है:

• यदि MongoDb को सफलतापूर्वक सहेजने के तुरंत बाद माइक्रोसर्विस दुर्घटनाग्रस्त हो गया, लेकिन प्रसंस्करण कतार सूची को साफ़ करने से पहले, तो यह डेटा बिना सहेजे माना जाएगा - और 15 मिनट के बाद फिर से सहेजा जाएगा।
  इस तरह के परिदृश्य की संभावना को कम करने के लिए, हमने त्रुटियों के मामले में प्रसंस्करण कतार से हटाने के लिए बार-बार प्रयास किए हैं। वास्तव में, हमने अभी तक उत्पादन में ऐसे मामलों को नहीं देखा है।
  
• जब आप पुनः आरंभ करते हैं, तो मूली न केवल कैश खो सकती है, बल्कि कतारों से कुछ अनसुने दृश्य भी हो सकते हैं, क्योंकि यह हर कुछ मिनटों में समय-समय पर RDB स्नैपशॉट को सहेजने के लिए कॉन्फ़िगर किया जाता है।
  यद्यपि सिद्धांत रूप में यह एक गंभीर समस्या हो सकती है (विशेषकर यदि परियोजना वास्तव में महत्वपूर्ण डेटा के साथ व्यवहार करती है), तो व्यवहार में नोड्स को शायद ही कभी फिर से शुरू किया जाता है। उसी समय, निगरानी के अनुसार, तत्व 3 सेकंड से कम समय के लिए कतारों में खर्च करते हैं, अर्थात, नुकसान की संभावित मात्रा बहुत सीमित है।
  

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

इसका एक ज्वलंत उदाहरण उस समय था जब किसी एक परियोजना में MongoDB उदाहरण पूरी रात अनुपलब्ध था। इस समय, मूली को एक कतार से दूसरी कतार में संचित और घुमाए जाने के रूप में देखा जाता है, जब तक कि वे अंततः घटना को हल करने के बाद डेटाबेस में सहेजे नहीं गए; अधिकांश उपयोगकर्ताओं ने भी विफलता को नोटिस नहीं किया।

पठन दृश्य मायने रखता है

पढ़ने के अनुरोध लिखने के अनुरोधों की तुलना में बहुत सरल हैं: microservice पहले मूली में कैश की जांच करता है; सब कुछ जो कैश में नहीं पाया जाता है वह MongoDb के डेटा से पॉप्युलेट होता है और क्लाइंट में वापस आ जाता है।

प्रतिस्पर्धी लेखों के खिलाफ रक्षा के ओवरहेड से बचने के लिए रीड ऑपरेशंस के दौरान कैश को एंड-टू-एंड लिखना नहीं है। कैश की हिट्रेट अच्छी बनी हुई है, जितना अधिक बार नहीं, यह पहले से ही अन्य लिखित अनुरोधों की बदौलत गर्म हो जाएगा।

दैनिक दृश्य आँकड़े MongoDB से सीधे पढ़े जाते हैं, क्योंकि यह अक्सर बहुत कम अनुरोध किया जाता है, और कैशिंग करना अधिक कठिन होता है। इसका अर्थ यह भी है कि जब डेटाबेस अनुपलब्ध है, तो आंकड़े पढ़ना काम करना बंद कर देता है; लेकिन यह उपयोगकर्ताओं के केवल एक छोटे से हिस्से को प्रभावित करता है।

MongoDB डेटा भंडारण योजना

परियोजना के लिए MongoDB संग्रह योजना स्वयं डेटाबेस डेवलपर्स की इन सिफारिशों पर आधारित है, और इस तरह दिखता है:

• दृश्य 2 संग्रहों में सहेजे गए हैं: एक में उनकी कुल राशि है, दूसरे में - दिन के हिसाब से आँकड़े।
  
• सांख्यिकी संग्रह में डेटा प्रति माह एक दस्तावेज़ प्रति विज्ञापन के आधार पर आयोजित किया जाता है। नई घोषणाओं के लिए, चालू महीने के लिए इकतीस शून्य से भरा एक दस्तावेज संग्रह में डाला गया है; ऊपर वर्णित लेख के अनुसार, यह आपको डिस्क पर एक दस्तावेज़ के लिए पर्याप्त स्थान तुरंत आवंटित करने की अनुमति देता है ताकि डेटा जोड़ते समय डेटाबेस को इसे स्थानांतरित न करना पड़े।
  यह आइटम आंकड़ों को पढ़ने की प्रक्रिया को थोड़ा अजीब बनाता है (अनुरोधों को महीनों से माइक्रो सर्विस पर उत्पन्न किया जाना चाहिए), लेकिन कुल मिलाकर यह योजना काफी सहज बनी हुई है।
  
• अपग्रेड ऑपरेशन का उपयोग रिकॉर्डिंग के लिए किया जाता है, अपडेट करने के लिए और, यदि आवश्यक हो, उसी अनुरोध के भीतर वांछित इकाई के लिए एक दस्तावेज़ बनाएं।
  

हम एक ही समय में कई संग्रहों को अद्यतन करने के लिए MongoDb की व्यवहारिक क्षमताओं का उपयोग नहीं करते हैं, जिसका अर्थ है कि हम जोखिम लेते हैं कि डेटा को केवल एक संग्रह में लिखा जा सकता है। कुछ समय के लिए, हम बस ऐसे मामलों में लॉग इन करते हैं; उनमें से कुछ हैं, और अब तक यह अन्य परिदृश्यों के समान महत्वपूर्ण समस्या पेश नहीं करता है।

परीक्षण

मुझे अपने स्वयं के शब्दों पर भरोसा नहीं होगा कि वर्णित परिदृश्य वास्तव में काम करते हैं यदि वे परीक्षणों द्वारा कवर नहीं किए गए थे।

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

इस परियोजना में, परीक्षण के 3 मुख्य क्षेत्र हैं:

1. विशिष्ट परिदृश्यों में व्यापार तर्क की मान्यता, तथाकथित खुश-पथ। ये परीक्षण प्रश्न का उत्तर देते हैं - जब सभी उपप्रणाली क्रम में हैं, तो क्या सेवा कार्यात्मक आवश्यकताओं के अनुसार काम करती है?
2. नकारात्मक परिदृश्यों की जांच करना जिसमें सेवा को अपना काम जारी रखने की उम्मीद है। उदाहरण के लिए, क्या MongoDb क्रैश होने पर सेवा वास्तव में डेटा नहीं खोती है?
   क्या हमें यकीन है कि सूचना आवधिक समय-सीमा, जमाव और प्रतिस्पर्धी रिकॉर्डिंग कार्यों के अनुरूप है?
3. उन नकारात्मक परिदृश्यों की जाँच करना जिनमें हमें सेवा के जारी रहने की उम्मीद नहीं है, लेकिन न्यूनतम स्तर की कार्यक्षमता अभी भी प्रदान की जानी चाहिए। उदाहरण के लिए, इस बात की कोई संभावना नहीं है कि सेवा तब भी डेटा को सहेजना और वापस करना जारी रखेगी जब न तो मूली और न ही मैंगो उपलब्ध हो - लेकिन हम यह सुनिश्चित करना चाहते हैं कि ऐसे मामलों में यह दुर्घटनाग्रस्त न हो, लेकिन सिस्टम पुनर्प्राप्ति की उम्मीद करता है और फिर काम पर लौट आता है।

असफल परिदृश्यों के लिए जाँच करने के लिए, सेवा व्यवसाय तर्क कोड डेटाबेस क्लाइंट इंटरफेस के साथ काम करता है, जो आवश्यक परीक्षणों में कार्यान्वयन से प्रतिस्थापित किया जाता है जो त्रुटियों को वापस करते हैं और / या नेटवर्क देरी का अनुकरण करते हैं। हम " पर्यावरण ऑब्जेक्ट " पैटर्न का उपयोग करके कई सेवा उदाहरणों के समानांतर संचालन का अनुकरण भी करते हैं। यह अच्छी तरह से ज्ञात "नियंत्रण उलटा" दृष्टिकोण का एक प्रकार है, जहां फ़ंक्शन स्वयं निर्भरता तक नहीं पहुंचते हैं, लेकिन उन्हें तर्कों में पारित पर्यावरण वस्तु के माध्यम से प्राप्त करते हैं। अन्य फायदों के बीच, दृष्टिकोण आपको एक परीक्षण में सेवा की कई स्वतंत्र प्रतियों का अनुकरण करने की अनुमति देता है, जिनमें से प्रत्येक का डेटाबेस से कनेक्शन का अपना पूल है और कम या ज्यादा कुशलता से उत्पादन वातावरण को पुन: पेश करता है। कुछ परीक्षण प्रत्येक ऐसे उदाहरण को समानांतर में चलाते हैं और सुनिश्चित करते हैं कि वे सभी एक ही डेटा देखते हैं, और कोई दौड़ की स्थिति नहीं है।

हमने एक अल्पविकसित भी किया, लेकिन अभी भी काफी उपयोगी तनाव परीक्षण आधारित है
घेराबंदी , जिसने सेवा से स्वीकार्य भार और प्रतिक्रिया की गति का अनुमान लगाने में मदद की।

प्रदर्शन के बारे में

90% अनुरोधों के लिए, प्रसंस्करण समय बहुत छोटा है, और सबसे महत्वपूर्ण बात - स्थिर; यहां कई दिनों में से एक परियोजना पर माप का एक उदाहरण है:



यह दिलचस्प है कि लेखन (जो वास्तव में एक लेखन + रीड ऑपरेशन है, क्योंकि यह अद्यतन मान लौटाता है) पढ़ने की तुलना में थोड़ा तेज है (लेकिन केवल एक ग्राहक के दृष्टिकोण से जो निरीक्षण नहीं करता है वास्तविक लंबित रिकॉर्ड)।
देरी में नियमित रूप से सुबह की वृद्धि हमारी एनालिटिक्स टीम के काम का एक दुष्प्रभाव है, जो दैनिक रूप से सेवा के डेटा के आधार पर अपने स्वयं के आंकड़े एकत्र करती है, जो हमारे लिए एक "कृत्रिम उच्च भार" का निर्माण करती है।

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

निष्कर्ष

अभ्यास, कुछ हद तक काउंटरिंटिकली, ने दिखाया है कि देखने की सेवा के लिए मुख्य भंडार के रूप में रेडिस का उपयोग करने से समग्र स्थिरता में वृद्धि हुई है और इसकी समग्र गति में सुधार हुआ है।

सेवा का मुख्य भार रीड अनुरोध है, जिनमें से 95% कैश से वापस आ जाते हैं, और इसलिए बहुत जल्दी काम करते हैं। रिकॉर्डिंग अनुरोधों में देरी हो रही है, हालांकि अंत उपयोगकर्ता के दृष्टिकोण से वे भी जल्दी से काम करते हैं और तुरंत सभी ग्राहकों के लिए दृश्यमान हो जाते हैं। सामान्य तौर पर, लगभग सभी ग्राहकों को 5ms से कम समय में प्रतिक्रियाएं मिलती हैं।

परिणामस्वरूप, Go, Redis और MongoDB के आधार पर माइक्रोसैसवर्क का वर्तमान संस्करण सफलतापूर्वक लोड के तहत काम करता है और डेटा स्टोर में से एक की आवधिक अनुपलब्धता से बचने में सक्षम है। बुनियादी ढांचे की समस्याओं के साथ हमारे पिछले अनुभव के आधार पर, हमने मुख्य त्रुटि परिदृश्यों की पहचान की और सफलतापूर्वक उनके खिलाफ बचाव किया, ताकि अधिकांश उपयोगकर्ता असुविधा का अनुभव न करें। और हम, बदले में, लॉग में बहुत कम शिकायतें, अलर्ट और संदेश प्राप्त करते हैं - और हम उपस्थिति में और वृद्धि के लिए तैयार हैं।