🤖 🔩 ⬇️ कैस्केडिंग कतारों के साथ प्रति दिन लाखों घटनाओं को संसाधित करना 🔠 🍟 🏂🏼

सैकड़ों, हजारों और कुछ सेवाओं में, लाखों कतारें, जिनके माध्यम से डेटा की एक बड़ी मात्रा गुजरती है, हमारे उत्पाद के हुड के नीचे कताई कर रहे हैं। यह सब कुछ जादुई तरीके से संसाधित किया जाना चाहिए और शूट नहीं किया जाना चाहिए। इस पोस्ट में मैं आपको बताऊंगा कि हम घर पर इस्तेमाल होने वाले वास्तुशिल्प तरीकों का क्या उपयोग करते हैं, एक काफी मामूली प्रौद्योगिकी स्टैक और हमारे "पेंट्री" में एक छोटा डेटा सेंटर नहीं होने के कारण।

हमारे पास क्या है?

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

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

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

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

हमारे सिस्टम में, एक सामान्य बस है जिसके माध्यम से ग्राहकों के साथ होने वाली सभी घटनाएं गुजरती हैं। यह प्रति दिन 500 मिलियन से अधिक घटनाएँ हैं। उनका प्रसंस्करण बल्कि नाजुक है - यह डेटा वेयरहाउस में एक रिकॉर्ड है, ताकि पेज के मालिक को ऐतिहासिक रूप से वह सब कुछ देखने का अवसर मिले जो उसके ग्राहकों के साथ हुआ था।

ऐसा लगता है कि एक इवेंट-आधारित प्रणाली को लागू करने के लिए हमारे पास पहले से ही सब कुछ है, और यह हमारे लिए एक सामान्य ईवेंट बस के प्रसंस्करण में हमारे व्यापार तर्क को एकीकृत करने के लिए पर्याप्त है। लेकिन हमारी नई प्रणाली के लिए हमारी कुछ आवश्यकताएँ हैं:

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

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

कतारों का एक समूह

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

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

हमारा डेटा प्रवाह आरेख अब इस तरह दिखता है:

हालांकि, इस योजना के काम करने के लिए, हमें नई कतारों के प्रसंस्करण के मुद्दे को हल करने की आवश्यकता है।

हमारे प्लेटफ़ॉर्म पर 1 मिलियन से अधिक जुड़े पृष्ठ (बॉट) हैं, जिसका अर्थ है कि संभावित रूप से हम अपनी योजना में ~ 1 मिलियन कतार प्राप्त कर सकते हैं, केवल घटना-आधारित परत के स्तर पर। तकनीकी दृष्टिकोण से, यह हमारे लिए डरावना नहीं है। कतार सर्वर के रूप में, हम Redis का उपयोग इसके मानक डेटा प्रकारों के साथ करते हैं, जैसे LIST, SORTED SET और अन्य। इसका मतलब यह है कि प्रत्येक पंक्ति रैम में रेडिस के लिए मानक डेटा संरचना है, जिसे मक्खी पर बनाया या हटाया जा सकता है, जो हमें आसानी से और लचीले ढंग से हमारे सिस्टम में बड़ी संख्या में कतारों को संचालित करने की अनुमति देता है। मैं एक अलग पोस्ट में तकनीकी विवरण के साथ कतार सर्वर के रूप में रेडिस का उपयोग करने के बारे में अधिक गहराई से बात करूंगा, लेकिन अब हम अपनी वास्तुकला में वापस आ जाएंगे।

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

कतारों का एक बड़ा पूल प्रसंस्करण

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

लेकिन कतारों के अनुपात को 1: 1 करने के लिए एक संदिग्ध काम है। कतारों की संख्या लगातार बदल रही है, ऊपर और नीचे दोनों। रनिंग हैंडलर की संख्या भी अनंत नहीं है, कम से कम हमारे पास ऑपरेटिंग सिस्टम और हार्डवेयर की ओर से एक सीमा है, और हम नहीं चाहेंगे कि श्रमिकों को खाली कतारों पर खड़ा होना पड़े। हैंडलर और कतारों के बीच बातचीत की समस्या को हल करने के लिए, हमने अपने कतार पूल को संसाधित करने के लिए एक राउंड रॉबिन सिस्टम लागू किया।

और यहाँ नियंत्रण रेखा हमारी सहायता के लिए आई।

जब किसी साझा बॉट से किसी विशेष बॉट के ईवेंट-आधारित कतार में ईवेंट को अग्रेषित किया जाता है, तो हम इस बॉट कतार के पहचानकर्ता को नियंत्रण कतार में भी रखते हैं। नियंत्रण कतार पूल में मौजूद कतारों के केवल पहचानकर्ताओं को संग्रहीत करती है और उन्हें संसाधित करने की आवश्यकता होती है। नियंत्रण कतार में केवल अनन्य मान संग्रहीत किए जाते हैं, अर्थात, एक ही बॉट कतार पहचानकर्ता को केवल एक बार नियंत्रण कतार में संग्रहीत किया जाएगा, चाहे वह कितनी बार लिखी गई हो। Redis पर, यह SORTED SET डेटा संरचना का उपयोग करके कार्यान्वित किया जाता है।

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

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

अंतिम योजना इस प्रकार है:

वर्तमान योजना के साथ, हमने मुख्य पहचान की गई समस्याओं को हल किया:

मुख्य घटना बस में प्रदर्शन में गिरावट
ईवेंट हैंडलिंग उल्लंघन
शोर पड़ोसियों का प्रभाव

गतिशील भार से कैसे निपटें?

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

सोचकर, हमने फैसला किया, क्यों न एक बार फिर सभी परिचित और परिचित साधनों का उपयोग किया जाए। इसलिए हमें अपना आंतरिक एपीआई मिला, जिसने NGINX + PHP-FPM के मानक बंडल पर काम किया। नतीजतन, हम अपने श्रमिकों के निश्चित पूल को एपीआई के साथ बदल सकते हैं, और एनजीआईएनएक्स + पीएचपी-एफपीएम को हल कर सकते हैं और श्रमिकों को स्वयं प्रबंधित कर सकते हैं, और हमारे लिए नियंत्रण कतार और हमारे आंतरिक एपीआई के बीच केवल एक नियंत्रण उपभोक्ता है जो हमारे एपीआई में कतार पहचानकर्ता भेजेगा। प्रसंस्करण और कतार खुद को PHP-FPM द्वारा उठाए गए कार्यकर्ता में संसाधित किया जाएगा।

नई योजना इस प्रकार थी:

यह सुंदर दिखता है, लेकिन हमारा नियंत्रण उपभोक्ता एक धागे में काम करता है, और हमारा एपीआई तुल्यकालिक रूप से काम करता है। इसका मतलब यह है कि उपभोक्ता हर बार हैंग करेगा जबकि PHP-FPM एक कतार को पीस रहा है। यह हमें शोभा नहीं देता।

हमारे एपीआई को अतुल्यकालिक बनाना

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

कार्यान्वयन कोड की एक जोड़ी लेता है, और अवधारणा का प्रमाण इस तरह दिखता है:

class Api {
    	public function actionDoSomething()
    	{
    		$data = $_POST;
    		$this->dropFPMSession();
    		// ,        ,     
    		//     
    	}
    
    
    	protected function dropFPMSession()
    	{
    		ignore_user_abort(true); 
    		//          
    		ob_end_flush(); //  
    		flush(); //  
    		@session_write_close(); // 
    	
    		fastcgi_finish_request(); 
    		//          
    	}
    }

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

इस दृष्टिकोण का उपयोग करते हुए, हमने उपभोक्ताओं के गतिशील नियंत्रण और उनके स्वचालित स्केलिंग के साथ जुड़े सिरदर्द का एक गुच्छा उतार दिया।

आगे स्केलेबल

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

यदि हम एक ठोस इकाई के रूप में अपनी वास्तुकला की कल्पना करते हैं, तो यह इस तरह दिखाई देगा:

ऐसी इकाइयों की संख्या में वृद्धि करने के बाद, हम उनके सामने एक पतली बैलेंसर रख सकते हैं, जो कि शार्पिंग कुंजी के आधार पर हमारी घटनाओं / कार्यों को आवश्यक इकाइयों में बिखेर देगा।

इस प्रकार, हमें अपने सिस्टम की क्षैतिज स्केलिंग के लिए एक बड़ा मार्जिन मिलता है।

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

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