Node.JS और Redis पर वितरित चैट

एक छोटा सा प्रश्न / उत्तर:

यह किसके लिए है? जिन लोगों को वितरित प्रणालियों के साथ बहुत कम या कोई अनुभव नहीं है, और जो यह देखने में रुचि रखते हैं कि उन्हें कैसे बनाया जा सकता है, क्या पैटर्न और समाधान मौजूद हैं।

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

समस्या का बयान

कैसे करें चैट? यह एक तुच्छ कार्य होना चाहिए, शायद हर दूसरे बीकेंडर ने अपना खुद का काम देखा, ठीक उसी तरह जैसे कि गेम डेवलपर्स अपने टेट्रिस / सांपों को बनाते हैं, आदि मैंने इसे उठाया, लेकिन इसे और अधिक दिलचस्प बनाने के लिए, इसे दुनिया भर में लेने के लिए तैयार होना चाहिए, ताकि यह सैकड़ों अरबों का सामना कर सके। सक्रिय उपयोगकर्ता और सामान्य तौर पर अविश्वसनीय रूप से शांत थे। एक वितरित आर्किटेक्चर की स्पष्ट आवश्यकता इसी से आती है, क्योंकि यह एक मशीन पर ग्राहकों की सभी काल्पनिक संख्या को फिट करने की वर्तमान क्षमता के लिए अवास्तविक है। क्वांटम कंप्यूटर की उपस्थिति के लिए सिर्फ बैठने और इंतजार करने के बजाय, मैंने वितरित सिस्टम के विषय का अध्ययन करने के बारे में दृढ़ संकल्प किया।

यह ध्यान देने योग्य है कि एक त्वरित प्रतिक्रिया बहुत महत्वपूर्ण है, कुख्यात रीयलटाइम, यह एक चैट है ! कबूतर मेल वितरण नहीं।

रूसी पोस्ट % के बारे में % यादृच्छिक मजाक

हम Node.JS का उपयोग करेंगे, यह प्रोटोटाइप के लिए आदर्श है। सॉकेट के लिए, सॉकेट ले लो। टाइपस्क्रिप्ट पर लिखें।

और इसलिए हम क्या चाहते हैं:

1. ताकि उपयोगकर्ता एक दूसरे को संदेश भेज सकें
2. जानिए कौन है ऑनलाइन / ऑफलाइन

हम इसे कैसे चाहते हैं:

एकल सर्वर

कोड के लिए विशेष रूप से कहने के लिए कुछ भी नहीं है। संदेश इंटरफ़ेस की घोषणा करें:

interface Message{ roomId: string,//    message: string,//    } 

सर्वर पर:

 io.on('connection', sock=>{ //    sock.on('join', (roomId:number)=> sock.join(roomId)) //    //         sock.on('message', (data:Message)=> io.to(data.roomId).emit('message', data)) }) 

क्लाइंट पर, कुछ इस तरह:

 sock.on('connect', ()=> { const roomId = 'some room' //      sock.on('message', (data:Message)=> console.log(`Message ${data.message} from ${data.roomId}`)) //   sock.emit('join', roomId) //    sock.emit('message', <Message>{roomId: roomId, message: 'Halo!'}) }) 

आप इस तरह से ऑनलाइन स्थिति के साथ काम कर सकते हैं:

 io.on('connection', sock=>{ //         // ,        - //      sock.on('auth', (uid:string)=> sock.join(uid)) //,     , //          //   sock.on('isOnline', (uid:string, resp)=> resp(io.sockets.clients(uid).length > 0)) }) 

और ग्राहक पर:

 sock.on('connect', ()=> { const uid = 'im uid, rly' //  sock.emit('auth', uid) //     sock.emit('isOnline', uid, (isOnline:boolean)=> console.log(`User online status is ${isOnline}`)) }) 

नोट: कोड नहीं चला, मैं उदाहरण के लिए मेमोरी से लिखता हूं

जलाऊ लकड़ी की तरह, हम वास्तविक प्राधिकरण, कमरे के प्रबंधन (संदेश इतिहास, प्रतिभागियों को जोड़ने / हटाने) और लाभ को स्पिन करते हैं।

लेकिन! लेकिन हम विश्व शांति पर कब्जा करने जा रहे हैं, जिसका अर्थ है कि यह रुकने का समय नहीं है, हम तेजी से आगे बढ़ रहे हैं:

नोड.जेएस क्लस्टर

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

बांटो और बाइक दो

यह कैसे करना है? जाहिर है, आपको किसी भी तरह हमारे उदाहरणों को जोड़ने की जरूरत है, न केवल घर में बेसमेंट में लॉन्च किया गया है, बल्कि पड़ोसी तहखाने में भी। सबसे पहले क्या ध्यान में आता है: हम कुछ ऐसे मध्यवर्ती लिंक बनाते हैं जो हमारे सभी नोड्स के बीच एक बस के रूप में काम करेंगे:

जब एक नोड दूसरे को संदेश भेजना चाहता है, तो वह बस से एक अनुरोध करता है, और पहले से ही, बदले में, वह इसे आगे बढ़ाता है जहां इसकी आवश्यकता है, सब कुछ सरल है। हमारा नेटवर्क तैयार है!

फिन।

... लेकिन यह इतना आसान नहीं है?)

इस दृष्टिकोण के साथ, हम इस मध्यवर्ती लिंक के प्रदर्शन में भाग लेते हैं, और वास्तव में हम आवश्यक नोड्स से सीधे संपर्क करना चाहते हैं, क्योंकि प्रत्यक्ष संचार से तेज क्या हो सकता है? तो चलिए इस दिशा में कदम बढ़ाते हैं!

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

नोड उठता है, मास्टर को उसके जागरण के बारे में बताता है, यह अन्य सक्रिय नोड्स की एक सूची देता है, हम उनसे कनेक्ट करते हैं और यही वह है, नेटवर्क तैयार है। मास्टर कांसल या ऐसा ही कुछ हो सकता है, लेकिन चूंकि हम साइकिल चला रहे हैं, इसलिए मास्टर को स्व-निर्मित होना चाहिए।

महान, अब हमारे पास अपना खुद का स्काईनेट है! लेकिन इसमें चैट का वर्तमान कार्यान्वयन उपयुक्त नहीं है। चलो वास्तव में आवश्यकताओं के साथ आते हैं:

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

चलो उपयोगकर्ताओं के साथ सौदा करते हैं। उदाहरण के लिए, आप मास्टर को बता सकते हैं कि कौन सा नोड किस नोड से जुड़ा है। स्थिति इस प्रकार है:

दो उपयोगकर्ता विभिन्न नोड्स से जुड़े हैं। गुरु यह जानता है, नोड्स को पता है कि मास्टर क्या जानता है। जब UserB लॉग इन करता है, तो Node2 मास्टर को सूचित करता है, जो "याद रखता है" कि UserB Node2 से जुड़ा है। जब UserA एक उपयोगकर्ता संदेश भेजना चाहता है, तो आपको निम्न चित्र मिलता है:

सिद्धांत रूप में, सब कुछ काम करता है, लेकिन मैं मास्टर से पूछताछ करने के रूप में यात्रा के एक अतिरिक्त दौर से बचना चाहूंगा, यह सीधे सीधे नोड से सीधे संपर्क करने के लिए अधिक किफायती होगा, क्योंकि यह सब शुरू क्यों हुआ। यह तब किया जा सकता है जब वे सभी को बताते हैं कि कौन से उपयोगकर्ता उनके साथ जुड़े हुए हैं, उनमें से प्रत्येक विज़ार्ड का एक आत्मनिर्भर एनालॉग बन जाता है, और विज़ार्ड स्वयं अनावश्यक हो जाता है, क्योंकि सभी के लिए "उपयोगकर्ता => नोड" अनुपात की सूची डुप्लिकेट है। नोड की शुरुआत में, यह किसी भी पहले से चल रहे व्यक्ति से कनेक्ट करने के लिए पर्याप्त है, इसकी सूची को अपने और वॉइला तक खींच लें, यह लड़ाई के लिए भी तैयार है।

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

संदेश दलालों

वह इकाई जो "बस" को लागू करती है, ऊपर वर्णित "मध्यवर्ती लिंक"। इसका कार्य संदेशों को प्राप्त करना और वितरित करना है। हम, उपयोगकर्ता के रूप में, उनकी सदस्यता ले सकते हैं और अपना स्वयं का भेज सकते हैं। सब कुछ सरल है।

वहाँ साबित कर रहे हैं RabbitMQ और Kafka: वे सिर्फ वही करते हैं जो वे संदेश देते हैं - यह उनका उद्देश्य है, गर्दन के लिए सभी आवश्यक कार्यक्षमता के साथ crammed। उनकी दुनिया में, एक संदेश दिया जाना चाहिए चाहे जो भी हो।

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

... और आपको यही चाहिए!

ठीक है, वास्तव में, हम सिर्फ चैट करते हैं। किसी तरह की क्रिटिकल मनी सर्विस या स्पेस फ्लाइट कंट्रोल सेंटर नहीं, बल्कि ... सिर्फ एक चैट। जोखिम यह है कि साल में एक बार सशर्त पीट को एक हजार में से एक भी संदेश प्राप्त नहीं होता है - उसे उपेक्षित किया जा सकता है यदि बदले में हमें उत्पादकता में वृद्धि मिलती है और उसके साथ एक ही दिन के लिए उपयोगकर्ताओं की संख्या, उसके सभी महिमा में व्यापार बंद हो जाता है। इसके अलावा, एक ही समय में, आप कुछ प्रकार के लगातार रिपॉजिटरी में एक संदेश इतिहास रख सकते हैं, जिसका अर्थ है कि पेटी अभी भी पेज / एप्लिकेशन को पुनः लोड करने के लिए उसी मिस्ड संदेश को देखेगा। इसीलिए हम Redis pub / sub, या यों कहें: SocketIO के लिए मौजूदा एडॉप्टर को देखेंगे, जिसका उल्लेख कार्यालय में लेख में किया गया है। साइट ।

तो यह क्या है?

रेडिस एडाप्टर

https://github.com/socketio/socket.io-redis

इसकी मदद से, कुछ लाइनों के माध्यम से एक साधारण एप्लिकेशन और इशारों की एक न्यूनतम संख्या एक वास्तविक वितरित चैट में बदल जाती है! लेकिन कैसे? यदि आप अंदर देखते हैं - यह पता चलता है कि प्रति आधा सौ लाइनों में केवल एक फ़ाइल है।

मामले में जब हम एक संदेश जारी करते हैं

 io.emit("everyone", "hello") 

यह मूली में धकेल दिया जाता है, जो हमारी चैट के अन्य सभी उदाहरणों में प्रेषित होता है, जो बदले में इसे पहले से ही स्थानीय रूप से सॉकेट्स पर जारी करता है

यदि हम किसी विशिष्ट उपयोगकर्ता को जारी करते हैं तो भी संदेश सभी नोड्स में वितरित किया जाएगा। यही है, प्रत्येक नोड सभी संदेशों को स्वीकार करता है और पहले से ही समझता है कि क्या इसकी आवश्यकता है।

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

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

सिद्धांत रूप में, हम यहाँ रुक सकते हैं, लेकिन हमेशा की तरह, यह हमारे लिए पर्याप्त नहीं है:

1. एक ही मूली उदाहरण में बोतल गर्दन
2. अतिरेक, मैं नोड्स को केवल उन संदेशों को प्राप्त करना चाहूंगा जो उन्हें चाहिए

पैराग्राफ एक की कीमत पर, ऐसी चीज़ को देखें:

रेडिस क्लस्टर

यह कई मूली उदाहरणों को जोड़ता है, जिसके बाद वे पूरे काम करते हैं। लेकिन वह इसे कैसे करता है? हां, इस तरह:

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

मैं एक शुरुआती हूं, मुझे बहुत कुछ पता नहीं है, कभी-कभी मुझे पिचफ़र्किंग पर लौटना पड़ता है, जो हम करेंगे। नहीं, मूली को छोड़ दें ताकि यह बिल्कुल भी फिसल न जाए, लेकिन आपको आर्किटेक्चर के साथ कुछ सोचने की जरूरत है क्योंकि वर्तमान अच्छा नहीं है।

गलत रास्ता मोड़ो

हमें क्या चाहिए? समग्र थ्रूपुट बढ़ाएँ। उदाहरण के लिए, आइए एक और उदाहरण के लिए मूर्खतापूर्ण प्रयास करें। कल्पना करें कि सॉकेट.आईओ-रेडिस कई से जुड़ सकता है, जब किसी संदेश को धक्का देता है, तो यह यादृच्छिक का चयन करता है, और सब कुछ के लिए सदस्यता लेता है। यह इस तरह से निकला:

देखा! सामान्य तौर पर, समस्या हल हो जाती है, मूली अब एक अड़चन नहीं है, आप किसी भी संख्या में प्रतियों को फैला सकते हैं! लेकिन वे नोड हो गए। हां, हां, हमारे चैट इंस्टेंसेस अभी भी सभी संदेशों को पचा रहे हैं, जिनके लिए उनका इरादा नहीं था।

आप इसके विपरीत कर सकते हैं: एक यादृच्छिक एक की सदस्यता लें, जो नोड्स पर भार कम कर देगा, और सब कुछ धक्का देगा:

हम देखते हैं कि यह चारों ओर का दूसरा रास्ता बन गया है: नोड्स शांत महसूस करते हैं, लेकिन मूली के उदाहरण पर लोड बढ़ गया है। यह भी अच्छा नहीं है। आपको थोड़ा सा बाइक चलाने की आवश्यकता है।

हमारे सिस्टम को पंप करने के लिए, हम सॉकेट.आईओ-रेडिस पैकेज को अकेले छोड़ देंगे, हालांकि यह शांत है, हमें अधिक स्वतंत्रता की आवश्यकता है। और इसलिए, हम मूली को जोड़ते हैं:

 //  : const pub = new RedisClient({host: 'localhost', port: 6379})//  const sub = new RedisClient({host: 'localhost', port: 6379})//   //    interface Message{ roomId: string,//    message: string,//    } 

हमारी संदेश प्रणाली सेट करें:

 //     sub.on('message', (channel:string, dataRaw:string)=> { const data = <Message>JSON.parse(dataRaw) io.to(data.roomId).emit('message', data)) }) //   sub.subscribe("messagesChannel") //    sock.on('join', (roomId:number)=> sock.join(roomId)) //   sock.on('message', (data:Message)=> { //   pub.publish("messagesChannel", JSON.stringify(data)) }) 

फिलहाल, यह सॉकेट में बदल जाता है ।io-redis: हम सभी संदेशों को सुनते हैं। अब हम इसे ठीक कर देंगे।

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

 //     sub.on('message', (channel:string, message:string)=> { io.to(channel).emit('message', message)) }) let UID:string|null = null; sock.on('auth', (uid:string)=> { UID = uid //   -   //  UID  sub.subscribe(UID) //   sock.join(UID) }) sock.on('writeYourself', (message:string)=> { //  ,        UID if (UID) pub.publish(UID, message) }) 

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

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

इस प्रकार, हम वास्तविक समय में अनंत विस्तार क्षमता के साथ एक ऑपरेटिंग संरचना प्राप्त करते हैं, किसी भी बिंदु पर एक व्यक्तिगत नोड पर लोड सिस्टम के आकार पर निर्भर नहीं करता है, क्योंकि:

1. कुल बैंडविड्थ को समूहों के बीच विभाजित किया जाता है, अर्थात्, उपयोगकर्ताओं / गतिविधि में वृद्धि के साथ, हम केवल अतिरिक्त समूहों की तुलना करते हैं।
2. उपयोगकर्ता प्रबंधन (सदस्यता) स्वयं समूहों में विभाजित है, अर्थात् जब उपयोगकर्ता / सदस्यता बढ़ रही है, तो हम समूहों के भीतर उदाहरणों की संख्या बढ़ाते हैं।

... और जैसा कि हमेशा होता है एक "ब्यूट": जितना अधिक यह सब हो जाता है, अगले लाभ के लिए अधिक संसाधनों की आवश्यकता होती है, यह मुझे अत्यधिक व्यापार बंद लगता है।

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

कुछ ऐसा ही इस दोस्त को बताता है:

उपयोगकर्ता का स्थान प्राप्त करने के लिए, हम एक अतिरिक्त दौर की यात्रा करते हैं, जो सिद्धांत में ठीक है, लेकिन हमारे मामले में नहीं। ऐसा लगता है कि हम गलत दिशा में खुदाई कर रहे हैं, हमें कुछ और चाहिए ...

हैश की ताकत

हैश जैसी कोई चीज होती है। इसमें कुछ परिमित मूल्य हैं। आप इसे किसी भी डेटा से प्राप्त कर सकते हैं। लेकिन क्या होगा अगर आप मूल सीमा के बीच इस सीमा को विभाजित करते हैं? खैर, हम उपयोगकर्ता आईडी लेते हैं, एक हैश का उत्पादन करते हैं, और उस सीमा के आधार पर जिसमें वह एक विशिष्ट उदाहरण के लिए सदस्यता / धक्का देता है। अर्थात्, हम पहले से नहीं जानते हैं कि कौन सा उपयोगकर्ता मौजूद है, लेकिन इसे प्राप्त करने के बाद, हम आत्मविश्वास से कह सकते हैं कि यह n उदाहरण में है, 100 inf। अब एक ही बात है, लेकिन कोड के साथ:

 function hash(val:string):number{/**/}// -,   const clients:RedisClient[] = []//   const uid = "some uid"//  //,            //      const selectedClient = clients[hash(uid) % clients.length] 

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

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

गितुब पर भंडार भर दिया।

यह अंतिम संस्करण को लागू करता है जिस पर हम आए हैं। इसके अलावा, कमरे (संवाद) के साथ काम करने के लिए अतिरिक्त तर्क है।

सामान्य तौर पर, मैं संतुष्ट हूं और इसे बंद किया जा सकता है।

कुल मिलाकर

आप कुछ भी कर सकते हैं, लेकिन संसाधनों के रूप में एक ऐसी चीज है, और वे परिमित हैं, इसलिए आपको कुश्ती करने की आवश्यकता है।

हमने इस बात की पूरी अनदेखी के साथ शुरू किया कि वितरित सिस्टम कैसे ठोस या कम ठोस पैटर्न पर काम कर सकता है, और यह अच्छा है।