स्वचालित डायलिंग कैसे करें, इस साइट पर पहले ही बहुत कुछ लिखा जा चुका है।
तारांकन के लचीलेपन की कोई सीमा नहीं है। बिल्ट-इन टूल्स या थर्ड-पार्टी उत्पादों और समाधानों का उपयोग करके सरल कार्यों के कार्यान्वयन पर बड़ी संख्या में लेख लिखे गए हैं। इसलिए, मेरी राय में, गैर-मानक समस्या को हल करने के लिए सबसे दिलचस्प होगा, जिसके लिए मुझे वर्तमान कॉल सेंटर योजना के साथ संगतता को देखते हुए, स्क्रैच से एक प्रणाली को पूरी तरह से विकसित और कार्यान्वित करना था।
प्रागितिहास
फिलहाल, एक साल से ज्यादा समय बीत चुका है। अब सिस्टम के पूरे प्रोग्राम कोड का लगभग 90-95% फिर से लिखा गया है, और मैं स्पष्ट रूप से कल्पना करता हूं कि सिस्टम कैसे विकसित हो रहा है और सिस्टम को कैसे विकसित करना चाहिए। लेकिन उस समय जब मेरे लिए कार्य निर्धारित किया गया था, मुझे एक अस्पष्ट विचार था कि कोड को कैसा दिखना चाहिए, टीओआर को देखते हुए, और मूल रूप से तारांकन के साथ संचार करने का कोई अनुभव नहीं था। मुझे तुरंत यह कहना होगा कि मुख्य विचार मेरा नहीं है, मेरा कार्य यह महसूस करना था या यहां तक कि यह दर्शाया गया था कि कार्य की स्थितियों में क्या चित्रित किया गया था। लेकिन एक ही समय में सबसे महत्वपूर्ण बात यह थी कि मैं प्रौद्योगिकियों और समाधानों की पसंद में व्यावहारिक रूप से असीमित था - जिसने, मेरी राय में, मुझे पूरी योजना को उस रूप में लाने की अनुमति दी जो मैं चाहता था।
उस समय, कंपनी के पास पहले से ही एक काम करने वाला कॉल सेंटर था। लगभग 10 लाइनें, प्रत्येक पंक्ति में 4 से 20 ऑपरेटरों तक और घड़ी के चारों ओर लगभग 12-15 हजार कॉल। स्थानीय, लंबी दूरी और अंतर्राष्ट्रीय कॉल के लिए 5 प्रदाता। लंबे समय से, कॉल सेंटर बड़ी संख्या में विभिन्न कार्यात्मकताओं और स्वयं के विकास के साथ आगे निकल गया है। मुख्य सॉफ्टवेयर प्लेटफॉर्म तारांकन सर्वर,
MySQL में कॉल सांख्यिकी और व्यावसायिक तर्क के साथ एक डेटाबेस, साथ ही स्क्रिप्ट से
एजीआई के लिए बाध्यकारी हैं।
कार्य
समय-समय पर विभिन्न प्रकार के मुद्दों पर ग्राहकों को कॉल करने की आवश्यकता होती है। यह समय-समय पर दोनों की आवश्यकता हो सकती है, उदाहरण के लिए महीने में एक बार (ऋण, पदोन्नति या विज्ञापन पर सूचनाएं), साथ ही कभी-कभी (अनसुलझे समस्याएं, तकनीकी मुद्दे)। फिलहाल, कई लोगों को कतार से चुना जा रहा है जो ऐसे ग्राहकों को फोन कर रहे हैं और उनके काम की रिपोर्ट तैयार कर रहे हैं, जिसे बाद में एक-दूसरे को सौंप दिया जाता है। यदि कॉल की एक बड़ी कतार है, तो ऑपरेटर इनकमिंग कॉल पर वापस आ जाते हैं और वे लोड को हटाने में मदद करते हैं, फिर वे फिर से वापस आ जाते हैं। नतीजतन, एक मानव कारक के रूप में कई समस्याएं पैदा होती हैं, एक व्यक्ति संख्या में गलती कर सकता है, ग्राहकों में से एक को भूल सकता है, या प्रशासन में - यह आवश्यक है कि कतार से आने वाले ऑपरेटरों की निगरानी करें और डायलिंग से आने वाली कॉल और इसके विपरीत।
इसलिए, एक निश्चित मशीन की आवश्यकता होती है जो कतार में लोड को ध्यान में रखते हुए, वांछित ग्राहकों को रिंग करेगी, ताकि सरल प्रश्नों के लिए, आप केवल न्यूनतम लोड पर रिंग कर सकें, और अधिक जटिल और महत्वपूर्ण लोगों के लिए, यह आने वाली कॉल के लिए भी प्राथमिकता है। मशीन को ऑपरेटर और क्लाइंट को सीधे कनेक्ट करना होगा, ताकि क्लाइंट तुरंत एक जीवित व्यक्ति के साथ बातचीत
शुरू कर सके, बिना
आईवीआर के माध्यम से
जाने या लाइन में इंतजार किए बिना। जिस ऑपरेटर को कॉल करने के लिए चुना गया था - उसे कतार में रहना चाहिए और बिना किसी कार्रवाई के बातचीत की समाप्ति के बाद नियमित रूप से इनकमिंग कॉल या अन्य कॉल ले सकता है। ऑपरेटर के साथ जुड़ने के बाद, ऑपरेटर को कॉल का सार समझने के लिए एक टाइमआउट की आवश्यकता होती है - यह समझने के लिए कि वह क्लाइंट को क्यों बुला रहा है, और कॉल पूरा होने के बाद, परिणाम की परवाह किए बिना, टाइमआउट कार्य पर टिप्पणी करना है। प्रति माह 2000 कॉल की योजनाबद्ध भार और फिर भविष्य में 10,000 - 15,000 तक।
कार्यान्वयन योजना
समस्या की स्थितियों का वर्णन करके, हम तकनीकी मॉडल बनाते हैं:
- एक कार्य अनुसूचक की आवश्यकता है। किसी भी समय और एक निश्चित समय पर दोनों को जारी करने के लिए कार्यों को स्वयं तैयार करना आवश्यक है (किसी को भी 3 बजे शेष राशि की जानकारी की आवश्यकता नहीं होगी)। कतार के भार की निगरानी करना आवश्यक है ताकि डायल करने वाले कार्य सभी स्लॉट बंद न हों और नियमित रूप से आने वाली कॉल में हस्तक्षेप न करें।
- ऑपरेटर और ग्राहक के प्रत्यक्ष कनेक्शन के लिए एक तंत्र की आवश्यकता है। सबसे पहले, एक मुफ्त ऑपरेटर का चयन करते हुए, ऑपरेटर का कंधा उठता है और उसके बाद ही ग्राहक का कंधा उठता है। कॉल के समय, पूरे कतार प्रसंस्करण तर्क को संरक्षित किया जाना चाहिए। एजेंट को व्यस्त होना चाहिए और कॉल को आंकड़ों में गिना जाना चाहिए।
- यदि संभव हो तो, न्यूनतम ऑपरेटर भागीदारी की आवश्यकता है। यहां, इस मामले में, मेरा मतलब है कि ऑपरेटर की ओर से अधिकतम स्वचालन। उसके लिए एक इनकमिंग कॉल आना चाहिए, ऑपरेटर इसका जवाब देगा, और सिस्टम क्लाइंट की कॉल को स्वयं बना देगा, दोनों दिशाओं को चुनकर कार्य की स्थिति को बदल देगा, चाहे हम क्लाइंट के माध्यम से मिले। मैं नीचे और अधिक विस्तार से बताऊंगा।
- निवर्तमान दिशाओं और तारांकन सर्वरों का संतुलन और अतिरेक स्वयं आवश्यक है। इसके अलावा, जब एक आउटगोइंग प्रदाता चुनते हैं, तो आपको यह विचार करने की आवश्यकता है कि ज़ोन से संबंधित होने के अलावा, कॉल की एक अलग लागत भी है।
- कॉल ट्रैकिंग लॉजिक आरक्षित करना सुनिश्चित करें। यदि ऑपरेटर कॉल का जवाब नहीं देता है, तो कंप्यूटर फ्रीज हो जाता है या हिचकिचाता है, कॉल को बस गिरना नहीं चाहिए और खो जाना चाहिए। यदि एक सामान्य इनकमिंग कॉल के दौरान, हमें "AgentRingNoAnswer" ईवेंट प्राप्त होता है, तो हम बस किसी अन्य ऑपरेटर का चयन कर सकते हैं, फिर इस मामले में हमें ऑपरेटर की प्रतिक्रिया और क्लाइंट की डायलिंग के बीच एक अड़चन आती है।
कार्यान्वयन
आयोजन
अब, समय के साथ, निष्पादन कालक्रम को याद करना मुश्किल है, लेकिन सबसे पहले मैंने तुरंत निर्णय लिया था कि सभी योजना बिलिंग में होनी चाहिए। मौजूदा क्लाइंट और उसकी विशेषताओं के आधार पर कार्य बनेगा: इसके लिए बंधे फोन नंबर, बैलेंस, इससे जुड़े उपकरणों की स्थिति, व्यापारिक आँकड़े आदि। प्रारंभ में, यह स्पष्ट था कि इस तरह की स्वचालन ग्राहक के साथ संचार के लिए कौन सी व्यापक संभावनाएं प्रदान करती है। हम सभी से पूछ सकते हैं - जो किसी भी सेवा से जुड़े हैं - इसका उपयोग नहीं करते हैं। जब एक नया फर्मवेयर जारी किया जाता है, तो
ऑटो प्रोविजनिंग नहीं होने पर अपडेट की पेशकश करने के लिए ग्राहकों को कॉल करें। ग्राहकों को नियोजित गतिविधियों के बारे में चेतावनी दें, या अतिरिक्त कंपनी सेवाओं को आंतरिक रूप से बढ़ावा दें। लेकिन टेलीफोनी के तकनीकी पक्ष से ऐसा कार्य केवल एक फोन नंबर और जिस कारण से हम बुला रहे हैं, जैसा दिखता है।
हम एक तुच्छ समस्या पर कॉल कर सकते हैं, लेकिन हमें क्लाइंट के साथ अधिक तत्काल कनेक्शन की आवश्यकता हो सकती है - उदाहरण के लिए, बातचीत के दौरान कॉल बाधित हो गई थी। हमें जल्द से जल्द ग्राहक से संपर्क करने और उसके प्रश्न को हल करने की आवश्यकता है। इसलिए, हमें प्राथमिकता के रूप में ऐसे पैरामीटर की आवश्यकता है। आप उसे किसी भी समय और पहली जगह पर बुला सकते हैं।
प्रत्येक कार्य का अपना समाधान होता है। यदि हमारे पास एक प्रशासनिक योजना का प्रश्न है, तो हम इसे सदस्यता विभाग के माध्यम से हल करते हैं। तकनीकी समस्या को तकनीकी सहायता के माध्यम से हल किया जाता है। तदनुसार, कार्य बनाते समय, आपको यह चुनने की आवश्यकता है कि कौन सी सेवा कार्य प्राप्त करेगी।
नतीजतन, बिलिंग के आंतरिक तर्क के माध्यम से एक दृश्य बनाया गया था, जिसमें से कार्य के रूप में प्राप्त किया जा सकता है: कार्य आईडी, फोन नंबर, प्राथमिकता और वह कतार जिसके लिए कार्य का गठन किया गया था। मेरे हिस्से के लिए, एक डेमॉन लिखा गया था कि लगातार कतार लोड की निगरानी करता है - अधिकतम स्वीकार्य प्रतिशत की प्रतिक्रिया के लिए इंतजार कर रहे कॉल की वर्तमान संख्या लेता है, साथ ही साथ मुफ्त ऑपरेटरों की संख्या भी। उदाहरण के लिए, कम प्राथमिकता वाले कार्यों के लिए, 0% कतार लोडिंग और कम से कम 1 मुफ्त ऑपरेटर की आवश्यकता होती है। यदि प्राथमिकता अधिक है, तो लोड 70% से अधिक नहीं है। उच्च प्राथमिकता के लिए, लोड 100% के बराबर नहीं है। अनुकूल परिस्थितियों में, कार्य को प्राप्त करने वाला दानव अपनी स्थिति को
"चालू" में बदल देता है और कॉल को कतार में फेंक देता है। कार्य संख्या स्थानीय डेमन कैश में दर्ज की जाती है, जिसके द्वारा हमारे डेटाबेस के रूप में
कार्य तालिका में कार्य की निगरानी की जाती है:
कार्य आईडी -> डायलेस्टाटस । यदि कोई स्थिति दिखाई दी है, तो हम बिलिंग में कार्य की स्थिति को बदलते हैं और शब्दकोश और स्थानीय कैश से कार्य को हटा देते हैं। तदनुसार, डेमन की शुरुआत में, स्थिति के साथ
"निष्पादित" किए जाने वाले सभी कार्यों को बिलिंग से उनकी स्थिति की निगरानी के लिए एकत्र किया जाता है।
ऑपरेटर के साथ काम करें
एक ऑपरेटर के साथ काम करने के लिए एक योजना विकसित करना, मैंने मुख्य विशेषताओं पर प्रकाश डाला:
- ऑपरेटर के साथ चयन और कनेक्ट करने की प्रक्रिया जितनी जल्दी हो सके होनी चाहिए। किसी भी व्यस्त ऑपरेटर को 3-5 सेकंड से अधिक समय में कॉल के लिए बेरोजगारी और उपयुक्तता के लिए जाँच की जानी चाहिए।
- यदि कोई विफलता होती है और ऑपरेटर कॉल का जवाब नहीं देता है या कंप्यूटर जमा नहीं करता है। कॉल बैक को कतार में ले जाना, और समस्या ऑपरेटर को कतार से निकालना आवश्यक है।
- कॉल की स्थिति की निगरानी करना आवश्यक है ताकि कॉल के अंत में कार्य की स्थिति को पूरा करने के लिए या तो पूरा हो या नहीं।
जब मैंने एक समाधान की तलाश शुरू की, तो मुझे तुरंत एहसास हुआ कि वर्तमान आंकड़े सही ढंग से नहीं देखेंगे और ऑपरेटर को कॉल को सफल नहीं मानेंगे, इसके अलावा, यह स्पष्ट नहीं था कि इस तरह के विशेष कॉल को प्राप्त करने के लिए ऑपरेटर को कैसे निकालना है, इसलिए ऑपरेटर को डायल करने और इसे ब्रिजिंग करने जैसे प्रयास किए गए थे। ग्राहक के कंधे के साथ-साथ कतार स्लॉट के साथ विभिन्न धोखाधड़ी। एकत्र की गई योजनाएं काम कर रही थीं, लेकिन आंकड़े एकत्र करते समय बेहद अस्थिर और समय लेने वाली थीं। नतीजतन, मैंने वर्तमान योजना के अनुकूल होने की कोशिश करने से इनकार कर दिया और एक नए प्रकार की इनकमिंग कॉल को संसाधित करने के लिए तर्क का एक स्वतंत्र हिस्सा लिखने का फैसला किया। ऑपरेटर के साथ काम करने का तंत्र
ओरिजिनल चुना गया था।
कॉल फ़ाइल का विरोध करने के रूप में कई
, तकनीक निश्चित रूप से शांत है, और इसमें कुछ प्रकार के कार्यों के लिए मौजूद होने का अधिकार है, लेकिन यह मेरे कार्य के लिए उपयुक्त नहीं होगा: ऑपरेटर से कनेक्ट करने के लिए, तत्काल उत्तर की आवश्यकता है या नहीं, ऑपरेटर कॉल स्वीकार कर सकता है, फ़ाइल के मामले में आपको फ़ाइल की निगरानी करने की आवश्यकता है , जो मेरे दृष्टिकोण से सुविधाजनक नहीं है और तर्कसंगत नहीं है। मैं सिर्फ एक एमी अनुरोध करता हूं, लगभग 5 सेकंड प्रतीक्षा करें, यदि ऑपरेटर फोन उठाता है, तो कॉल अगले चरण में जाता है, यदि नहीं, तो कतार में कॉल वापस करें और अगले ऑपरेटर की तलाश करें। इसके अलावा, फ़ाइलें तारांकन पर स्थानीय कार्य की विशेषता होती हैं जिसके लिए यह बनता है। यही है, हमें प्रत्येक सर्वर पर एक निश्चित स्थानीय स्क्रिप्ट की आवश्यकता होगी, जो स्थानीय रूप से एक फ़ाइल बनाएगी, साथ ही यह पता लगाएगा कि वर्तमान में अन्य सर्वर सहयोगियों में से कौन सबसे कम लोड है। प्रबंधन का पूर्ण विकेंद्रीकरण। मेरे मामले में, मैं बस सभी सर्वरों पर एक लोड का अनुरोध करता हूं और सबसे कम लोड का चयन करते हुए मैं उसे एमी अनुरोध भेजता हूं।
तारांकन :: एएमआई पुस्तकालय का उपयोग काम के लिए किया गया था।
ऑपरेटर द्वारा कॉल का उत्तर दिए जाने के बाद, स्थानीय चर के माध्यम से उत्पन्न कॉल में,
" कॉल के लिए
" एक्सटेंड " का चयन किया जाता है, जहां
" डायल " से पहले
" प्रतीक्षा "के माध्यम से एक टाइमआउट सेट किया जाता है। मुख्य समस्या यह थी कि यदि ऑपरेटर टाइमआउट या कॉल के समय सोचता है और लटका हुआ है, तो कॉल गायब हो जाती है। इसलिए, जब dialstatus'a
"रद्द करें" आता है
, तो कॉल को संसाधित नहीं माना जाता है और कतार में वापस आ जाता है। ऑपरेटर को कतार से हटाएं। डायलपैन'ए
डायल पर आगे अतिरिक्त पैरामीटर
"जी" के साथ होता है, बातचीत की समाप्ति के बाद निष्पादन जारी रखने के लिए। टाइमआउट के अंत में,
"हैंगअप" एक्सटेंशन के माध्यम से बातचीत के बाद, एक प्रविष्टि डिक्शनरी में जोड़ा जाता है - जॉब आइडेंटिफ़ायर और डायलास्टस,
डालने का अनुरोध। इस प्रकार, एक कार्यशील मशीन और एक ग्राहक इस पर घूमा करता है,
"ऑटो उत्तर" फ़ंक्शन को चालू करता है - ऑपरेटर केवल इंटरफ़ेस में कार्यों पर टिप्पणी करता है, सभी कॉल प्रोसेसिंग उसके लिए होती है। शायद कोई कहेगा कि यह एक बुरा विचार है, लेकिन यह कई कारणों से किया जाता है। यदि हम चाहते हैं कि ग्राहक 30 सेकंड के माध्यम से प्राप्त करने की कोशिश करें, तो हम केवल डायल कमांड के लिए समय निर्धारित करते हैं, और ऑपरेटर से किसी भी कार्रवाई की प्रतीक्षा नहीं करते हैं। फिर से, हमें एक योजना मिलती है जिसमें लोगों के लिए नीरस काम कम हो जाता है। ऐसा हुआ कि शुरुआत में ही मैंने एक तकनीकी सहायता ऑपरेटर के रूप में एक ही कंपनी में काम किया और मुझे पहले से पता है कि ग्राहकों के अलावा खुद भी वही काम कैसे थकाऊ होते हैं।
संतुलन और आरक्षण
यदि आप प्रदाताओं में से किसी एक के अनुपलब्ध होने पर आउटगोइंग कॉल को आरक्षित करने के तरीके के बारे में जानकारी के लिए इंटरनेट पर खोज करते हैं - सबसे अधिक बार आपको डायप्लान में एक के बाद एक कई डायल'ओव बनाने के लिए प्रकार की सिफारिश मिलेगी। अपने हिस्से के लिए, मैं कुछ अधिक लचीला और गतिशील करना चाहता था। मुख्य समस्या यह थी कि हमने लोहे के बहुत सारे टुकड़ों का इस्तेमाल किया और कॉल करने से पहले कम से कम लोड और उपलब्ध ट्रंक की तलाश में उनके आसपास जाने का समय नहीं था। मुख्य विचार समग्र जानकारी के साथ काम करना था। ऐसा करने के लिए, एक अलग डेमॉन लिखा गया था, जिसके कार्य निम्नानुसार थे: विभिन्न प्रकार के उपकरणों से लोड को इकट्ठा करने के लिए, टीडीएम के कब्जे वाले स्लॉट्स और फ्री वाले के बीच अंतर,
सिप साथियों के माध्यम से वीओआइपी प्रदाताओं की पहुंच से और तारांकित उपयोगकर्ताओं से वर्तमान चैनलों के आधार पर, जो अधिक उपयोग किया जाता है। लेकिन दिशा चुनने के अलावा, किसी को यह ध्यान रखना चाहिए कि चड्डी में से कोई भी गिर सकता है, इसलिए आपको एक विकल्प चुनने की आवश्यकता है। मेरे मामले में, ये वॉयस प्रोवाइडर थे, लेकिन उनकी अपनी कीमतें भी होती हैं, इसलिए बैलेंसिंग को सबसे सस्ते से लेकर सबसे महंगे तक का चयन करना चाहिए (वे गुणवत्ता में बिल्कुल बराबर हैं)। इस तरह के चयन के लिए, मैंने प्रत्येक प्रदाता को मेरा वजन या मेरी लागत के लिए बनाया। इस प्रकार, इस प्रकार की कुंजियों और मूल्यों की एक सूची प्राप्त की गई थी:
- स्थानीय क्षेत्र => १०
- वीओआइपी प्रदाता ए => 20
- वीओआइपी प्रदाता बी => 30
- वीओआइपी प्रदाता सी => 40
इसलिए यदि प्रदाताओं में से कोई एक उपलब्ध नहीं है, तो हम निम्न से उच्चतर या महंगे से प्रतिस्थापन की तलाश कर रहे हैं।
लेकिन इसके अलावा, कमरे के आधार पर एक वितरण भी है। उदाहरण के लिए, मॉस्को नंबरों को, अपने स्थानीय प्रदाता के माध्यम से, अपने स्वयं के माध्यम से, यदि कोई हो, या किसी इंटरसिटी और अंतर्राष्ट्रीय गंतव्य के माध्यम से साइबेरिया या अन्य देशों में बुलाया जाना चाहिए। यहां यह निर्धारित करने की आवश्यकता है कि संख्या किस क्षेत्र से संबंधित है। इसके लिए, मैंने डेटाबेस में
संचार रजिस्ट्री का एक पार्सर लिखा। ऐसा लगता है:
mysql> select local.get_region(903599****); +
काम और विभिन्न बारीकियों की सामान्य योजना
- वर्तमान में प्रत्येक कार्य के लिए, आप प्रयासों की संख्या निर्धारित कर सकते हैं, जो कि "विफल" की प्रत्येक स्थिति से कम हो जाती है । निर्धारित समय समाप्त होने के बाद, कार्य फिर से जारी करने के लिए वापस आ जाएगा।
- इसके अलावा हाल ही में एक मौका दिया गया है कि किसी दिए गए प्रदाता के माध्यम से प्राथमिकता डायल अप करें, अगर यह अतिभारित और सुलभ नहीं है।
- वीओआइपी प्रदाताओं द्वारा लोड एकत्रीकरण के लिए डेमॉन को उपसर्ग द्वारा सिप चैनलों के नाम से उन्मुख किया जाता है। उदाहरण समूहों के लिए उपयोग करना संभव होगा, लेकिन अभी तक सब कुछ ठीक चल रहा है।
- वह समय-समय पर व्हिप प्रदाताओं और सभी ग्रंथियों को चड्डी के रास्ते पर रखता है, अगर कोई उपलब्ध नहीं है - प्रदाता को शेष राशि से हटा दिया जाता है।
- एक मुक्त ऑपरेटर का चयन करने के बाद, इसे व्यस्त के रूप में चिह्नित किया जाता है और निम्न तर्क होता है:
- हम सभी तारक सर्वरों का अनुरोध करते हैं जो संतुलन में हैं।
- वर्तमान कतार के लिए, कॉल मापदंडों का अनुरोध किया जाता है। यह ऑपरेटर और क्लाइंट से प्रतिक्रिया के लिए प्रतीक्षा समय है, "स्रोत" नंबर जिसे ग्राहक एक इनकमिंग कॉल के साथ देखेंगे - यह प्रत्येक सेवा के लिए अलग है।
- ग्राहक संख्या द्वारा, संख्याओं के रजिस्टर के साथ तालिका के माध्यम से दिशा का चयन करें।
- कॉल करने के लिए अपलिंक चुनें। यदि आप 0 सेट करते हैं, तो अपलिंक चयन में भाग नहीं लेगा, इसलिए आप प्रदाताओं को प्राथमिकता शिफ्ट करके संतुलन बना सकते हैं। उपलब्धता के लिए चयनित ट्रंक की जाँच की जाएगी और फिर डाउनलोड के लिए। यदि शर्तों को पूरा नहीं किया जाता है, तो अपलिंक को छोड़ दिया जाता है और हम अगले एक वजन पर आगे बढ़ते हैं।
- अगला, हम सबसे कम चैनलों के साथ तारांकन सर्वर का चयन करते हैं। चूंकि Redis में सभी सर्वरों के सभी चैनल हैं, इसलिए हम बिल्ट-इन hlen फ़ंक्शन के माध्यम से कुल प्राप्त करते हैं। एक सर्वर का चयन करते हुए, हम इसे कनेक्ट करने का प्रयास करते हैं - यदि सर्वर जवाब नहीं देता है, तो हम अगले एक को लेते हैं, फिर से कम से कम लोड के साथ।
- अंतिम रूप से, चर पैरामीटर के लिए, सेवा चर की एक सरणी बनाई जाती है, जिसके आधार पर कॉलिंग लेखांकन और दिशा चयन दोनों किए जाते हैं। यह उस कार्य के लिए वर्तमान ऑपरेटर की कॉल के बाइंडिंग का भी उपयोग करता है जिसके लिए कॉल किया जा रहा है।
निष्कर्ष
घोषित भार के बावजूद, अब यह आंकड़ा पिछले महीने की तुलना में लगभग 30,785 हो गया है। प्रारंभ में, योजना, केवल एक संकीर्ण श्रेणी के कार्यों के लिए नियोजित की गई है, जो एक व्यापक श्रेणी के कार्यों को सुलझाने में सक्षम सेवा तक बढ़ी है और एक बड़े भार का सामना करेगी। फिलहाल, इस पर काम बंद नहीं हुआ है - मैं लगातार कुछ जोड़ रहा हूं और कार्यक्षमता का विस्तार कर रहा हूं, साथ ही एक और रीफैक्टरिंग करने की योजना भी बना रहा हूं।