द्वारा प्रमोनो विनाता
क्या आप कभी एक ऐसे सिंगल प्रोसेस को संभालने की कोशिश में मुसीबत में पड़े हैं जो वास्तव में बहुत बड़ा या भारी है? यदि हां, तो मैं आपको यह पता लगाने में मदद कर सकता हूं कि इसे बेहतर तरीके से कैसे प्रबंधित किया जाए।
इस लेख में मैं साझा करूंगा कि मैं वर्तमान में एक सिंगल मैसेज को कैसे प्रबंधित कर रहा हूं जिसे एक सिंगल प्रोसेस पर प्रोसेस करने के लिए बहुत बड़ा है। मैंने इसे अलग-अलग चंक्स में विभाजित किया है, जिसके परिणामस्वरूप अलग-अलग प्रोसेस होते हैं।
मैं तकनीकी विवरण में बहुत अधिक नहीं जाऊंगा, बल्कि आर्किटेक्चरल प्रक्रिया पर अधिक ध्यान केंद्रित करूंगा।
मैं कैशिंग उपयोग और पबसब के बारे में कुछ बातें चर्चा करूंगा, लेकिन मैं कार्यान्वयन पर विवरण में नहीं जाऊंगा। इसके बजाय, मैं पैटर्न पर ही ध्यान केंद्रित करूंगा।
समस्या
फोटो: डैनिएल मैकइन्स / अनस्प्लैश
शायद आपके दिमाग में आने वाला पहला सवाल यह है कि हमें एक सिंगल प्रोसेस को कई समवर्ती प्रोसेस में विभाजित करने की आवश्यकता क्यों है?
ऐसा करने के कई कारण हो सकते हैं। मेरे मामले में, हालांकि, मैंने ऐसा इसलिए किया क्योंकि संदेश बहुत बड़ा था।
आपको मेरी स्थिति के बारे में कुछ अंदाजा देने के लिए, आइए मुझे इस सरल आरेख के साथ संक्षेप में बताएं:
मैं एक महान आरेख निर्माता नहीं हूं, लेकिन यह बात समझाने के लिए पर्याप्त होना चाहिए
इसे शब्दों में सरल बनाने के लिए, दो अलग-अलग सेवाओं, सर्विस A और सर्विस B की कल्पना करें, जिसके बीच में एक पबसब सर्विस है।
यदि आप सुनिश्चित नहीं हैं कि पबसब सर्विस क्या है, तो बस इसे एक ब्रोकर के रूप में कल्पना करें जो एक सेवा से संदेश को दूसरी सेवा तक पहुंचाने में मदद करता है।
सर्विस A तब एक संदेश पब्लिश करेगी और पबसब के माध्यम से, सर्विस B फिर इसे प्रोसेस करेगी। प्रोसेस खत्म होने के बाद, यह संदेश को प्रोसेस्ड के रूप में चिह्नित करने के लिए एक और प्रोसेस करेगी।
काफी सरल है ना?
बस कुछ मामलों में जब संदेश बहुत बड़ा होता है, तो यह पबसब सर्विस की सीमाओं के कारण संदेश को सफलतापूर्वक पब्लिश नहीं कर पाएगा।
ठीक है, इससे आपको उन मुद्दों का अवलोकन मिल जाना चाहिए जिनका मैंने सामना किया है। तो मैंने इस समस्या को कैसे ठीक किया? अगले सेक्शन में, मैं आपको अपने समाधान के माध्यम से ले चलूंगा।
मेरा पहला दृष्टिकोण
फोटो: डोज मीडिया / अनस्प्लैश
मेरे दिमाग में आने वाली पहली बात पबसब सर्विस द्वारा संभाले जा सकने वाले आकार को बढ़ाना था, जो एक सिंगल कॉन्फ़िगरेशन परिवर्तन के साथ संभव है।
लेकिन जिंदगी इतनी आसान नहीं होगी ना? क्या होता है अगर संदेश बस बड़ा होता चला जाए? क्या हम पबसब का आकार बढ़ाते रहें?
पता चला कि ऐसा करने से बहुत सारे स्केलेबिलिटी मुद्दे हो सकते हैं। लंबी अवधि के समाधान के लिए अच्छा नहीं।
फिर मैंने एक और समाधान सोचा जो मुझे लगा कि इसे हल कर सकता है: मैंने उस संदेश को कई संदेशों में विभाजित किया और उन भागों को अलग-अलग प्रोसेस करने का प्रयास किया।
अब, सिस्टम इस तरह दिखता था:
मेरा अपडेटेड सिस्टम/प्रोसेस
आरेख से आप देख सकते हैं कि संदेश कई छोटे संदेशों में विभाजित हो जाता है। इसे कैसे विभाजित किया जाता है और संदेश के किस भाग को विभाजित करने की आवश्यकता है, यह प्रत्येक मामले और फ्लो के लिए भिन्न हो सकता है।
मेरे मामले में, हालांकि, मेरा संदेश वास्तव में आइटम्स की एक सूची रखता है इसलिए मैं इसे प्रत्येक आइटम द्वारा विभाजित कर सकता हूं।
मान लें कि मेरे पास 10 आइटम हैं। पहले, यह सभी 10 आइटम्स को एक संदेश में पब्लिश करेगा। लेकिन अब संदेश को विभाजित करने के बाद, यह उस संदेश को 10 संदेशों में बदल देगा।
इसके परिणामस्वरूप एक सिंगल प्रोसेस एक साथ कई प्रोसेस बन जाता है। एक सिंगल पब्लिश 10 पब्लिश में बदल जाएगा जो बदले में उस सिंगल प्रोसेस को 10 प्रोसेस में बदल देगा।
जब आप इसे इस तरह देखते हैं तो यह आदर्श नहीं लग सकता है, लेकिन यह सबसे अच्छा समाधान है जो मैं लेकर आया हूं और यह निश्चित रूप से काम करता है।
तो क्या बस इतना ही है, केवल इसे विभाजित करना?
वास्तव में नहीं - याद रखें कि अंतिम भाग जहां यह प्रोसेस को समाप्त के रूप में चिह्नित करता है?
यदि हां, तो आप सोच रहे होंगे कि वह भाग मेरे नए आरेख से गायब क्यों है।
चिंता न करें - ऐसा नहीं है कि मैं इसके बारे में भूल गया। मैंने इसे अगले भाग के लिए जानबूझकर छोड़ दिया।
बात यह है कि जब आप संदेश को विभाजित करते हैं और इसे कई प्रोसेस में तोड़ते हैं, तो आपका सिस्टम यह नहीं जान पाएगा कि पूरा प्रोसेस वास्तव में समाप्त हो गया है। यह एक और प्रमुख मुद्दा है जिससे हमें निपटने की आवश्यकता है, और शुक्र है कि मुझे इसके लिए भी एक समाधान मिल गया।
समाप्त होने वाली प्रोसेस को कैसे संभालें
फोटो: जेम्स वेनस्कोएट / अनस्प्लैश
तो मुझे वास्तव में कैसे पता चलता है कि प्रोसेस समाप्त हो गई है, चूंकि वे प्रोसेस समवर्ती रूप से हो रही हैं?
मेरे द्वारा खोजा गया समाधान उन प्रोसेस की संख्या को स्टोर करना है जिन्हें करने की आवश्यकता है और हर बार एक प्रोसेस समाप्त होने पर इसे डिक्रीमेंट करना। इस तरह हम यह जान पाएंगे कि अंतिम प्रोसेस समाप्त हो गई है।
यह निश्चित रूप से काफी सरल लगता है, जब तक हमारे पास उस डेटा को स्टोर करने के लिए एक विश्वसनीय स्थान है।
और वास्तव में इसके लिए काफी विकल्प हैं। उनमें से एक को Redis कहा जाता है, और मैं यहां अपने मुद्दे से निपटने के लिए इसका उपयोग कर रहा हूं।
यदि आप Redis से परिचित नहीं हैं, तो यह एक सेवा है जिसे आमतौर पर कैश के रूप में उपयोग किया जाता है।
हम अपने Redis तंत्र को इस तरह प्रबंधित करेंगे:
अपने प्रोसेस को चिह्नित करने के लिए Redis जोड़ना
प्रोसेस बिल्कुल पहले जैसा दिखता है, लेकिन बीच में Redis के जुड़ने के साथ। आपको यह सुनिश्चित करने की आवश्यकता है कि इस मामले के लिए आपके पास एक वैध प्रारंभिक काउंट है।
मेरे मामले में, चूंकि मैं एक सूची पब्लिश कर रहा हूं, मैं आसानी से अपनी सूची की लंबाई को अपने प्रारंभिक काउंटर के रूप में रख सकता हूं। और काउंटर के लिए, मैं इसे हर बार एक प्रोसेस समाप्त होने पर एक से घटा सकता हूं। फिर मैं अपने Redis काउंटर का उल्लेख करके यह जान पाऊंगा कि क्या मैंने अपनी सभी प्रोसेस समाप्त कर ली हैं। यदि यह 0 तक पहुंच गया है, तो इसका मतलब है कि मैं सुरक्षित रूप से चिह्नित कर सकता हूं कि मेरी सभी प्रोसेस हो गई हैं।
निष्कर्ष
इसे संक्षेप में कहें तो, मैंने संदेश को कई संदेशों में विभाजित किया जिसे एक साथ कई प्रोसेस में प्रोसेस किया जाएगा। संदेश प्रोसेस को प्रबंधित करने के लिए, मैं Redis कैशिंग का उपयोग करता हूं।
ऊपर वर्णित समाधान हर बार एक सिल्वर बुलेट नहीं होगा जब आपको एक बहुत बड़े संदेश को प्रोसेस करने में समस्या हो। अन्य तरीके हैं जैसे अपने संदेश को स्ट्रीम करना, लेकिन वह किसी और दिन की कहानी होगी।
मेरे लेख को अंत तक पढ़ने के लिए धन्यवाद! मैं ईमानदारी से आशा करता हूं कि आपको मेरा लेख दिलचस्प और सबसे महत्वपूर्ण रूप से उपयोगी लगा।
मुफ़्त में कोड करना सीखें। freeCodeCamp का ओपन सोर्स पाठ्यक्रम 40,000 से अधिक लोगों को डेवलपर के रूप में नौकरी पाने में मदद कर चुका है। शुरू करें
