मेरा असली सवाल यह है कि क्या उपरोक्त तकनीकी स्टैक स्केल 1,000,000 संदेश प्रति सेकंड (पाठ, चित्र, वीडियो) कर सकता है?
ज़रूर कर सकता है। सही डिजाइन और पर्याप्त हार्डवेयर के साथ। आपके ग्राहक को जो प्रश्न पूछना चाहिए वह वास्तव में यह नहीं है कि क्या इसे इतना बड़ा बनाया जा सकता है, लेकिन यह किस कीमत और व्यावहारिकता पर किया जा सकता है और क्या वे सबसे अच्छे विकल्प हैं।
आइए आपके द्वारा उल्लिखित प्रत्येक अंश को देखें:
नोड.जेएस - एक I/O केंद्रित ऐप के लिए, यह उच्च पैमाने के लिए एक उत्कृष्ट विकल्प है और यह क्लस्टर में कई CPUs (प्रति सर्वर और बहु-सर्वर दोनों बहु-प्रक्रिया) को तैनात करके स्केल कर सकता है। इस प्रकार का पैमाना कितना व्यावहारिक है यह इस बात पर निर्भर करता है कि इन सभी सर्वर प्रक्रियाओं को किस प्रकार के साझा डेटा तक पहुंच की आवश्यकता है। आम तौर पर, डेटा स्टोर अंततः स्केलिंग में कठिन बाधा बन जाता है क्योंकि अनुरोध प्रसंस्करण पर अधिक सर्वर फेंकना आसान होता है। केंद्रीकृत डेटा स्टोर पर अधिक हार्डवेयर फेंकना इतना आसान नहीं है। ऐसा करने के तरीके हैं, लेकिन यह ऐप की मांगों पर निर्भर करता है कि आप इसे कैसे करते हैं और यह कितना कठिन है।
socket.io - यदि आपको छोटे संदेशों के कुशल सर्वर पुश की आवश्यकता है, तो socket.io शायद जाने का सबसे अच्छा तरीका है क्योंकि यह क्लाइंट को पुश करने में सबसे कुशल है। हालांकि यह सभी प्रकार के परिवहन में अच्छा नहीं है। उदाहरण के लिए, मैं socket.io के माध्यम से बड़ी छवियों या वीडियो को इधर-उधर नहीं करूंगा क्योंकि ऐसा करने के लिए और अधिक उद्देश्य से निर्मित तरीके हैं। तो, socket.io का उपयोग इस बात पर निर्भर करता है कि ऐप वास्तव में इसका क्या उपयोग करना चाहता है। यदि आप किसी क्लाइंट को वीडियो पुश करना चाहते हैं, तो आप केवल एक URL को पुश कर सकते हैं और क्लाइंट को घुमा सकते हैं और जाने-माने उच्च स्तरीय तकनीक का उपयोग करके एक नियमित http URL के माध्यम से वीडियो का अनुरोध कर सकते हैं।
रेडिस - फिर, कुछ चीज़ों के लिए बढ़िया, हर चीज़ में बढ़िया नहीं। तो, यह वास्तव में इस बात पर निर्भर करता है कि आप क्या करने की कोशिश कर रहे हैं। मैंने पहले जो समझाया था, वह यह है कि आपके डेटा स्टोर का डिज़ाइन और इसके माध्यम से लेन-देन की संख्या शायद वह जगह है जहाँ आपकी वास्तविक पैमाने की समस्याएँ हैं। अगर मैं यह काम शुरू कर रहा था, तो मैं सर्वर के लिए डेटा स्टोरेज की जरूरतों, विभिन्न प्रकार के लेनदेन प्रति सेकेंड, कैशिंग रणनीति, रिडंडेंसी, फेल-ओवर, डेटा दृढ़ता, आदि की समझ के साथ शुरू करूंगा ... और उच्च डिजाइन करें पहले डेटा तक पहुंच का पैमाना। मुझे पूरा यकीन नहीं होगा कि रेडिस पसंदीदा विकल्प था। मैं शायद सुझाव दूंगा कि आपको परियोजना की शुरुआत में एक सलाहकार के रूप में एक उच्च स्तर के डेटाबेस वाले की आवश्यकता है।
Nginx - nginx का उपयोग करने वाली बहुत सी उच्च स्तरीय साइटें तो यह निश्चित रूप से एक अच्छा टूल है। यह आपके लिए बिल्कुल सही उपकरण है या नहीं यह आपके डिजाइन पर निर्भर करता है। मैं शायद इस हिस्से पर अंतिम रूप से काम करूंगा क्योंकि यह डिजाइन के लिए कम केंद्रीय लगता है और एक बार बाकी सिस्टम तैयार हो जाने के बाद, आप इस पर विचार कर सकते हैं कि आपको यहां क्या चाहिए।
अमेज़ॅन ईसी2 - कई संभावित विकल्पों में से एक। इन विकल्पों की सीधे सेब से सेब की तुलना में तुलना करना कठिन है। बड़े पैमाने के सिस्टम EC2 से बनाए गए हैं, इसलिए वहां अवधारणा का प्रमाण है और सामान्य वास्तुकला एक उपयुक्त मेल लगता है। यदि आप जानना चाहते हैं कि असली ग्रेमलिन कहां हैं, तो आपको एक सलाहकार की आवश्यकता होगी जिसने ईसी 2 पर उच्च स्तर की चीजें की हों।
अमेज़ॅन S3 - मैं व्यक्तिगत रूप से वीडियो और छवियों दोनों के लिए S3 का उपयोग करने वाली कुछ बहुत ही उच्च भंडारण और बैंडविड्थ साइटों को जानता हूं। यह उसके लिए काम करता है।
तो ... ये आम तौर पर उपयोग करने के लिए अच्छे उपकरण होते हैं यदि इन्हें सही तरीके से उपयोग किया जाता है। वास्तविक एप्लिकेशन की भंडारण आवश्यकताओं के आधार पर रेडिस एक प्रश्न-चिह्न होगा (आपने शून्य आवश्यकताएं प्रदान की हैं और शून्य आवश्यकताओं के साथ डेटाबेस का चयन नहीं किया जा सकता है)। एक अधिक तर्कसंगत उत्तर आवश्यकताओं के एक उच्च स्तरीय सेट को एक साथ रखने पर आधारित होगा जो विश्लेषण करता है कि सिस्टम को 1,000,000 की सेवा करने के लिए क्या करने में सक्षम होना चाहिए। सिस्टम को स्केल करने पर बॉलपार्क शुरू करने के लिए इनमें से कुछ टुकड़ों के लिए उन आवश्यकताओं की तुलना ज्ञात क्षमताओं से की जा सकती है। फिर, आपको सिस्टम के कुछ हिस्सों पर कुछ परीक्षण चलाने के लिए कुछ बेंचमार्किंग परीक्षणों को एक साथ रखना होगा। विफलता की सफलता इस बात पर निर्भर करती है कि ऐप कैसे बनाया गया था और टूल्स का उपयोग कैसे किया गया था क्योंकि यह कौन से टूल्स चुने गए थे। आप कई अलग-अलग प्रकार के टूल के साथ एक सफल पैमाना बना सकते हैं। हेक, फेसबुक PHP पर चलता है (ठीक है, एक अत्यधिक संशोधित, अनुकूलित PHP जो वास्तव में रनटाइम पर बिल्कुल सामान्य PHP नहीं है)।
