वह सब कुछ जो आप क्वेरी प्रोसेसिंग के बारे में जानना चाहते थे, लेकिन पूछने में शर्म आ रही थी

नेटवर्क सेवा क्या है? यह एक ऐसा कार्यक्रम है जो नेटवर्क पर आने वाले अनुरोधों को स्वीकार करता है और उन्हें संसाधित करता है, संभवतः प्रतिक्रियाएं लौटाता है।

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

अनुरोध प्रक्रिया विधि का चयन करने के दूरगामी परिणाम होते हैं। 100,000 एक साथ कनेक्शन को समझने के साथ चैट सेवा कैसे करें? खराब संरचित फ़ाइलों की एक धारा से डेटा निकालने के लिए कौन सा दृष्टिकोण लेना चाहिए? गलत चुनाव से समय और ऊर्जा की बर्बादी होगी।

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

परिचय

क्वेरी प्रोसेसिंग विधियों का विषय नया नहीं है, उदाहरण के लिए देखें: एक , दो । हालाँकि, अधिकांश लेख इसे आंशिक रूप से ही मानते हैं। यह लेख अंतराल में भरने और मुद्दे की एक सुसंगत प्रस्तुति प्रदान करने का इरादा है।

निम्नलिखित दृष्टिकोणों पर विचार किया जाएगा:

• अनुक्रमिक प्रसंस्करण
• अनुरोध प्रक्रिया
• अनुरोध स्ट्रीम
• प्रक्रिया / थ्रेड पूल
• घटना-उन्मुख प्रसंस्करण (रिएक्टर पैटर्न)
• आधा सिंक / आधा async पैटर्न
• कन्वेयर प्रसंस्करण

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

टीएल, डॉ

लेख के अंत में प्रत्येक दृष्टिकोण के संक्षिप्त विवरण के साथ एक सूची है।

अनुक्रमिक प्रसंस्करण

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

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

अनुरोध प्रक्रिया

एक एप्लिकेशन में एक मुख्य प्रक्रिया होती है जो आने वाले अनुरोधों और वर्कफ़्लो को स्वीकार करती है। प्रत्येक नए अनुरोध के लिए, मुख्य प्रक्रिया एक वर्कफ़्लो बनाती है जो अनुरोध को संसाधित करती है। अनुरोधों की संख्या के आधार पर स्केलिंग सरल है: प्रत्येक अनुरोध की अपनी प्रक्रिया होती है।

इस वास्तुकला में कुछ भी जटिल नहीं है, लेकिन यह है समस्याओं सीमाएँ :

• इस प्रक्रिया में संसाधनों की बहुत अधिक खपत होती है।
  PostgreSQL RDBMS को 10,000 समवर्ती कनेक्शन बनाने की कोशिश करें और परिणाम देखें।
• प्रक्रियाओं में साझा मेमोरी (डिफ़ॉल्ट) नहीं है। यदि आपको साझा डेटा या साझा कैश तक पहुंच की आवश्यकता है, तो आपको साझा मेमोरी (कॉलिंग mmap, munmap) को मैप करना होगा या बाहरी स्टोरेज (मेमेकैड, रेडिस) का उपयोग करना होगा

ये समस्याएँ किसी भी तरह से रुकने से नहीं हैं। निम्नलिखित दिखाएगा कि वे PostgeSQL RDBMS में कैसे प्रबंधित किए जाते हैं।

इस वास्तुकला के पेशेवरों :

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

उदाहरण:

• PostgreSQL RDBMS प्रत्येक नए कनेक्शन के लिए एक नई प्रक्रिया बनाता है। साझा मेमोरी का उपयोग सामान्य डेटा के साथ काम करने के लिए किया जाता है। PostgreSQL प्रक्रियाओं की उच्च संसाधन खपत को कई अलग-अलग तरीकों से संभाल सकता है। यदि कुछ ग्राहक (विश्लेषकों के लिए एक समर्पित स्टैंड) हैं, तो ऐसी कोई समस्या नहीं है। यदि कोई एकल अनुप्रयोग है जो डेटाबेस तक पहुँचता है, तो आप अनुप्रयोग स्तर पर एक डेटाबेस कनेक्शन पूल बना सकते हैं। यदि कई अनुप्रयोग हैं, तो आप pgbouncer का उपयोग कर सकते हैं
• sshd पोर्ट 22 पर आने वाले अनुरोधों को सुनता है और हर कनेक्शन पर कांटा लगाता है। प्रत्येक ssh कनेक्शन sshd डेमॉन का एक कांटा है जो अनुक्रम में उपयोगकर्ता कमांड को प्राप्त करता है और निष्पादित करता है। इस वास्तुकला के लिए धन्यवाद, ओएस के संसाधनों का उपयोग एक्सेस अधिकारों में अंतर करने के लिए किया जाता है
• हमारे अपने अभ्यास से एक उदाहरण। असंरचित फ़ाइलों की एक धारा है जिसमें से आपको मेटाडेटा प्राप्त करने की आवश्यकता है। मुख्य सेवा प्रक्रिया हैंडलर प्रक्रियाओं के बीच फ़ाइलों को वितरित करती है। प्रत्येक हैंडलर प्रक्रिया एक स्क्रिप्ट है जो एक फ़ाइल पथ को एक पैरामीटर के रूप में लेती है। फ़ाइल प्रक्रिया एक अलग प्रक्रिया में होती है, इसलिए, एक प्रसंस्करण त्रुटि के कारण, पूरी सेवा क्रैश नहीं होती है। प्रसंस्करण एल्गोरिथ्म को अपडेट करने के लिए, यह सेवा को रोकने के बिना प्रसंस्करण स्क्रिप्ट को बदलने के लिए पर्याप्त है।

सामान्य तौर पर, मुझे यह कहना होगा कि इस दृष्टिकोण के अपने फायदे हैं, जो इसके दायरे को निर्धारित करते हैं, लेकिन मापनीयता बहुत सीमित है।

अनुरोध स्ट्रीम

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

पेशेवरों:

• आउट ऑफ द बॉक्स साझा मेमोरी
• कार्यान्वयन में आसानी
• मल्टी-कोर सीपीयू का कुशल उपयोग

विपक्ष:

• एक धारा बहुत सारे संसाधनों का उपभोग करती है। यूनिक्स की तरह ऑपरेटिंग सिस्टम पर, एक धागा एक प्रक्रिया के रूप में लगभग कई संसाधनों की खपत करता है

उपयोग का एक उदाहरण MySQL है। लेकिन यह ध्यान दिया जाना चाहिए कि MySQL एक मिश्रित दृष्टिकोण का उपयोग करता है, इसलिए इस उदाहरण की चर्चा अगले भाग में की जाएगी।

प्रक्रिया / थ्रेड पूल

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

पूल को सेवा की शुरुआत में अग्रिम रूप से बनाया जा सकता है या धीरे-धीरे बनाया जा सकता है। थ्रेड पूल का उपयोग करना अधिक सामान्य है आपको साझा मेमोरी को लागू करने की अनुमति देता है।

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

पेशेवरों:

• कई सीपीयू कोर का उपयोग
• एक धागा / प्रक्रिया बनाने के लिए लागत में कमी

विपक्ष:

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

उदाहरण:

1. अजगर आवेदन uWSGI और nginx के साथ चल रहा है। मुख्य uWSGI प्रक्रिया nginx से आने वाले अनुरोधों को प्राप्त करती है और अनुरोधों को संसाधित करने वाले दुभाषिया के पायथन प्रक्रियाओं के बीच उन्हें वितरित करती है। आवेदन किसी भी uWSGI- संगत ढांचे पर लिखा जा सकता है - Django, फ्लास्क, आदि।
2. MySQL थ्रेड पूल का उपयोग करता है: प्रत्येक नए कनेक्शन को पूल से मुक्त थ्रेड्स में से एक द्वारा संसाधित किया जाता है। यदि कोई मुक्त थ्रेड नहीं हैं, तो MySQL एक नया थ्रेड बनाता है। फ्री थ्रेड्स के पूल का आकार और थ्रेड्स की अधिकतम संख्या (कनेक्शन) सेटिंग्स द्वारा सीमित हैं।

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

घटना-उन्मुख प्रसंस्करण (रिएक्टर पैटर्न)

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

इस दृष्टिकोण की एक पूरी चर्चा इस लेख के दायरे से परे है। एक गहरी नज़र के लिए आप रिएक्टर (रिएक्टर) की सिफारिश कर सकते हैं, NodeJS गति का रहस्य क्या है? , अंदर NGINX । यहां हम इस दृष्टिकोण के पेशेवरों और विपक्षों पर विचार करने के लिए खुद को सीमित करते हैं।

पेशेवरों:

• प्रभावी स्केलिंग आरपीएस और एक साथ कनेक्शन की संख्या से। एक प्रतिक्रियाशील सेवा एक साथ बड़ी संख्या में कनेक्शन (दसियों हज़ार) संसाधित कर सकती है यदि अधिकांश कनेक्शन I / O के पूरा होने की प्रतीक्षा कर रहे हैं

विपक्ष:

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

उदाहरण:

1. Node.js आउट-ऑफ-द-बॉक्स रिएक्टर पैटर्न का उपयोग करता है। अधिक जानकारी के लिए, NodeJS गति का रहस्य क्या है?
2. nginx: nginx की कार्यकर्ता प्रक्रियाएं समानांतर में अनुरोधों को संसाधित करने के लिए रिएक्टर पैटर्न का उपयोग करती हैं। अधिक जानकारी के लिए अंदर NGINX देखें।
3. सी / सी ++ प्रोग्राम जो सीधे ओएस टूल्स (लिनोल पर आईओसीपी, खिड़कियों पर आईओसीपी, फ्रीबीएसडी पर केक्यू) का उपयोग करता है, या फ्रेमवर्क (लिबेव, लिबवेंट, लिबाव, आदि) का उपयोग करता है।

आधा सिंक / आधा async

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

विचार को अधिक विशिष्ट बनाने के लिए कुछ उदाहरण :

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

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

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

नतीजतन, आधा सिंक / आधा async दृष्टिकोण में दोनों फायदे हैं और अतुल्यकालिक दृष्टिकोण के कुछ नुकसान हैं। लेख की मात्रा हमें इस दृष्टिकोण पर विस्तार से विचार करने की अनुमति नहीं देती है। रुचि रखने वालों के लिए, मैं आपको POSA पुस्तक में उसी नाम के अध्याय को पढ़ने की सलाह देता हूं : पैटर्न फॉर कंसंट्रेट एंड नेटवर्कड ऑब्जेक्ट्स ।

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

पेशेवरों:

• यह आरपीएस में अच्छी तरह से तराजू और एक साथ कनेक्शन की संख्या
• अतुल्यकालिक दृष्टिकोण की तुलना में कोड लिखना और डीबग करना आसान है

विपक्ष:

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

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

कन्वेयर प्रसंस्करण

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

पेशेवरों:

• यह दृष्टिकोण rps में अच्छी तरह से तराजू है। श्रृंखला में जितने अधिक लिंक, उतने अनुरोध प्रति सेकंड संसाधित होते हैं।
• कई थ्रेड्स का उपयोग करके आप सीपीयू कोर के पार अच्छे से स्केल कर सकते हैं।

विपक्ष:

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

उदाहरण:

1. रिपोर्ट हाईलोड 2018 में कन्वेयर प्रसंस्करण का एक दिलचस्प उदाहरण वर्णित किया गया था मॉस्को एक्सचेंज के ट्रेडिंग और क्लियरिंग सिस्टम की वास्तुकला का विकास।

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

सारांश

दृष्टिकोणों का एक संक्षिप्त सारांश:

• तुल्यकालिक प्रसंस्करण।
  एक सरल दृष्टिकोण, लेकिन स्केलेबिलिटी में बहुत सीमित, दोनों आरपीएस में और एक साथ कनेक्शन की संख्या में। यह एक साथ कई सीपीयू कोर के उपयोग की अनुमति नहीं देता है।
• हर अनुरोध के लिए एक नई प्रक्रिया।
  . , . . ( , ).
• .
  , , . , .
• /.
  /. . rps . . .
• - (reactor ).
  rps . - , . CPU
• Half sync/half async.
  rps . CPU (Golang) (Python). , () . reactor , , reactor .
• .
  , . (, long polling ).

, .

: ? , ?

संदर्भ

1. :
   
   • :
2. - :
   
   • Reactor ()
   • NodeJS?
   • Inside NGINX
3. :
   
   • Apache vs Nginx:
   • Node.js PHP
4. Half sync/half async:
   
   • Half-Sync/Half-Async (Java Design Patterns)
   • POSA: Patterns for Concurrent and Networked Objects
5. :
   
   • Green threads ()
   • Green Vs Native Threads
6. :
   
   • -