कोई श्वेतपत्र नहीं है और यह कोड की 200 लाइनों की तरह है ताकि निगलने के लिए बहुत कुछ न हो।
सिग्नलआर में प्रत्येक संदेश एक संदेश बस नामक चीज़ के माध्यम से जाता है। जब आप नोड्स (या प्रक्रियाओं या ऐप डोमेन) में स्केल करना चाहते हैं, तो इस बस के कार्यान्वयन को आपके आवेदन के प्रत्येक उदाहरण से बात करने में सक्षम होना चाहिए। ऐसा करने के लिए आप RedisMessageBus का उपयोग कर सकते हैं। रेडिस में pub sub तंत्र है और साथ ही यह महत्वपूर्ण मूल्य जोड़ों को स्टोर करने की क्षमता है और हम केवल सिग्नल के लिए पूर्व का उपयोग करते हैं।
ऑफटॉप: यह बहुत महत्वपूर्ण है! सिग्नलआर विश्वसनीय संदेश नहीं है, यह एक कनेक्शन अमूर्त है। हम लंबे समय तक संदेशों को बफर कर सकते हैं लेकिन आप ** हमेशा के लिए संदेशों पर भरोसा नहीं कर सकते हैं। यदि आपके पास महत्वपूर्ण संदेश हैं जो आपको जारी रखने की आवश्यकता है, तो उन्हें जारी रखें।
प्रत्येक वेब सर्वर उनके बीच संदेश भेजने के लिए एक (या नए कार्यान्वयन में अधिक) लालसा घटनाओं से जुड़ता है। जब एक या अधिक ग्राहकों के लिए कोई संदेश आता है, तो यह बैकप्लेन (रेडिस) पर भेजा जाता है और यह सभी वेब सर्वर पर आता है। प्रत्येक वेबसर्वर को लाल रंग से संदेश मिलता है और इसे स्थानीय कैश में संग्रहीत करता है। यह स्थानीय कैश है जहां सिग्नलआर क्लाइंट (ब्राउज़र आदि) परोसा जाता है।
स्केल आउट डिज़ाइन का एक महत्वपूर्ण हिस्सा कर्सर है। एक कर्सर दर्शाता है कि एक विशेष ग्राहक संदेशों की अनंत धारा में कहां है। जब कोई कनेक्शन छोड़ने के बाद ग्राहक फिर से कनेक्ट होते हैं या एक संदेश प्राप्त करने के बाद लंबे समय तक कनेक्शन वापस आ जाता है तो यह कुछ कर्सर मूल्य के बाद मुझे सबकुछ प्राप्त करने के लिए बस से पूछता है। कर्सर को संदेश बस कार्यान्वयन द्वारा परिभाषित किया गया है और हमने इसे नवीनतम स्रोतों में सामान्यीकृत किया है (अभी तक लिखने के समय जारी नहीं किया गया है लेकिन मैं यहां विवरण में नहीं जाऊंगा)। रेडिस के वर्तमान कार्यान्वयन में कर्सर केवल एक संख्या है जो बढ़ी है, कुछ भी जटिल नहीं है।
उम्मीद है कि यह कुछ विचार देता है कि यह कैसे काम करता है।
बहुत बहुत धन्यवाद। महान स्पष्टीकरण। – user1574808
महान स्पष्टीकरण के लिए धन्यवाद। कृपया निम्नलिखित परिदृश्य पर विचार करें: मेरे पास ** लोड-संतुलित ** वेब-फार्म है जिसमें प्रत्येक सर्वर एक हब होस्ट कर रहा है। आइए मान लें कि सभी ग्राहक लंबी-मतदान के लिए गिर रहे हैं। _Client X_ लोड-बैलेंसर के माध्यम से जुड़ता है और उसका अनुरोध _server 1_ पर भेजा जाता है। अगले चुनाव पर हालांकि, लोड-बैलेंसरर अपने अनुरोध को _server 2_ पर निर्देशित करता है। मेरा सवाल यह है कि क्या बैकप्लेन सुनिश्चित करता है कि सभी हब सभी जुड़े ग्राहकों के बारे में जानते हैं, भले ही वे किस हब से मूल रूप से जुड़े हों? – demius
बैकप्लेन सभी सर्वरों से अवगत है, इसलिए सबकुछ बस काम करेगा। यह जानने की आवश्यकता नहीं है कि यह मूल रूप से किस सर्वर से जुड़ा हुआ है। – davidfowl