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