RabbitMQ चैनल निर्माण दिशानिर्देश

Question

मैं एक साधारण वर्ग लिख रहा हूं कि मेरे ऐप्स RabbitMQ का उपयोग करके संदेश भेजने और प्राप्त करने के लिए उपयोग करेंगे। मैंने कितने हाउ-टोस, ब्लॉग पोस्ट, श्वेत पत्र और खरगोश एमक्यू के बारे में पसंद को पढ़ा है जैसा कि मुझे मिल सकता है। अधिकांश उदाहरण एक प्रयोग ब्लॉक में लिपटे कनेक्शन और चैनल का उपयोग करने के लिए दिखाते हैं, और यह कहकर इसका विरोधाभास करते हैं कि आपको शायद उन्हें सिंगलटन के रूप में लागू करना चाहिए। विशेष रूप से चैनल के संबंध में, मैंने टिप्पणियां देखी हैं कि एक ही समय में एक ही चैनल का उपयोग करके आपके पास एक से अधिक धागे नहीं होना चाहिए।

मैं सी # में मेरे पुस्तकालय लिख रहा हूँ। यह एक सिंगलटन है जो पहले तात्कालिकता से जुड़ा एक स्थिर कनेक्शन है।

मैं चैनल के लिए एक ही करने के बारे में सोचा था, लेकिन मैं एक ही पुस्तकालय का उपयोग करने के प्रकाशन/एकाधिक आदान-प्रदान/कतारों की सदस्यता के लिए अनुमति देने का इरादा रखते हैं। प्रकाशन और सदस्यता दोनों को एकाधिक धागे से किया जा सकता है।

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

धन्यवाद!

Answer 1

मैं सी # कार्यान्वयन के विनिर्देशों पर टिप्पणी नहीं कर सकता, लेकिन यह जानने में मदद कर सकता है कि Amqp चैनलों को एक एकल टीसीपी कनेक्शन साझा करने के लिए डिज़ाइन किया गया है, यानी मल्टीप्लेक्सिंग सक्षम करने के लिए। एक चैनल केवल एक भेज सकता है या एक बार में एक संदेश प्राप्त कर सकता है, लेकिन एक कनेक्शन विभिन्न चैनलों पर एक साथ संदेश प्राप्त कर सकता है। छवि में आपको 2 बड़ी 1 जीबी फाइलें मिली हैं जिन्हें आप एक ही उपभोक्ता को अम्कप पर भेजते हैं, यह संभव है कि संदेश 10K भाग में विभाजित हो जाएंगे और एक अंतःस्थापित फैशन में भेजे जाएंगे। जब आप कनेक्शन सेट अप करते हैं तो आप डिफ़ॉल्ट Amqp संदेश आकार में हेरफेर कर सकते हैं, इस पर असर पड़ता है कि आपको अंतराल का अनुभव करने की संभावना है या नहीं; AFAIK इस सुविधा का उद्देश्य भुखमरी को रोकने में मदद करना है जब कई उपभोक्ता कनेक्शन साझा करते हैं और एक उपभोक्ता को बड़े संदेश प्राप्त होते हैं।

एचटीएच।

Answer 2

यह आंतरिक aqmp स्पष्ट करता है। वर्तमान में, मेरी समझ है: ए। मैं प्रत्येक एप्लिकेशन (एक स्थिर साझा संसाधन के रूप में) से सर्वर के लिए एक एकल, साझा, टीसीपी कनेक्शन धारण कर सकता हूं। बी। मुझे या तो प्रत्येक "कार्य" के लिए एक चैनल बनाना चाहिए (एक के लिए क्यू एक्स और एक को वाई का आदान-प्रदान करने के लिए प्रकाशन के लिए सुनना, इत्यादि। इन "कार्यों" को समानांतर में निष्पादित किया जा सकता है) सी। या मैं एक ही ऐप के भीतर सब कुछ के लिए एक चैनल का उपयोग कर सकता हूं, जबकि यह सुनिश्चित करने के लिए कि इसका उपयोग सिंक्रनाइज़ किया गया है - कुछ लॉकिंग तंत्र का उपयोग करके, यह मानते हुए कि वास्तविक समय का उपयोग चैनल का उपयोग किया जाता है (लॉक) अपेक्षाकृत बहुत छोटा होता है।

धन्यवाद।

Answer 3

आप सही है कि चैनल threadsafe नहीं है कर रहे हैं और एक से अधिक थ्रेड द्वारा नहीं पहुँचा जा चाहिए।

अलग कतारों का उपयोग करके अपनी योजना, आप एक चैनल के साथ कई कतारों हो सकते हैं। लेकिन यदि एकाधिक एक्सचेंजों पर आपकी योजना है (सुनिश्चित नहीं है कि आप यहां एक और क्यों चाहते हैं।) आपको या तो अपने सिंगलटन में एकाधिक एक्सचेंजों और चैनलों का ट्रैक रखने या कॉलर्स को जिम्मेदारी देने के लिए मजबूर होना होगा।

मैं आपके सिंगलटन का निर्माण करूंगा जैसे कि इसमें एक पर्यवेक्षक पैटर्न है और आपके कॉलर्स के संदर्भों के साथ वहां सभी खरगोश एमक्यू सामान हैं। इसके बाद आपको एक ऐसे थ्रेड पर कॉल को मार्शल करने की आवश्यकता होगी जो इससे संबंधित है या आप चैनल ऑब्जेक्ट्स के साथ समस्याएं खतरा कर सकते हैं।

Answer 4

संपादित करें (2016-1-26): चैनल धागे सुरक्षित नहीं हैं।

चैनल उदाहरणों धागे के बीच साझा नहीं किया जाना चाहिए: उस पर प्रलेखन April और May 2015 नया पाठ के बीच बदल गया है। अनुप्रयोगों को एक ही चैनल को एकाधिक धागे में साझा करने के बजाय चैनल प्रति थ्रेड का उपयोग करना पसंद करना चाहिए। हालांकि चैनलों पर कुछ संचालन एक साथ आने के लिए सुरक्षित हैं, कुछ लोग तार पर गलत फ्रेम इंटरलीविंग नहीं करेंगे और न ही परिणाम देंगे। धागे के बीच चैनल साझा करना * प्रकाशक पुष्टि के साथ हस्तक्षेप करेगा।

अपने प्रश्न से

यह लग रहा है जैसे आप धागे कि ज्यादातर का प्रकाशन करते हैं/RabbitMQ की सदस्यता की एक पूर्वनिर्धारित, निर्धारित संख्या नहीं है (इस स्थिति में आप धागे के प्रारंभ के हिस्से के रूप में एक चैनल बनाने पर विचार हो सकता , या ThreadLocal<IModel> का उपयोग कर)।

यदि समवर्ती खरगोश एमक्यू ऑपरेशंस दुर्लभ हैं या संदेश आकार हमेशा छोटे होते हैं, तो आप अपने सभी खरगोश एमक्यू पब/सब ऑपरेशंस के आसपास lock(channel) डाल सकते हैं। यदि आपको एक इंटरलीव किए गए फैशन में प्रसारित करने के लिए कई अनुरोधों की आवश्यकता है - यही वह चैनल है जो पहले स्थान पर है - मनमाने ढंग से धागे का उपयोग करके, आप चैनल पूल, उदाहरण के लिए बनाना चाहते हैं। एक ConcurrentQueue<IModel> जहां आप अप्रयुक्त चैनलों को रद्द करते हैं और उस समय के लिए Dequeue जब आपको उनकी आवश्यकता होती है। चैनल निर्माण बहुत कम ओवरहेड है, और मुझे प्रदर्शन परीक्षणों से यह महसूस हो रहा है कि चैनल निर्माण की प्रक्रिया में कोई नेटवर्क शामिल नहीं है, यानी ऐसा लगता है कि पहले चैनल पर एक चैनल स्वचालित रूप से RabbitMQ सर्वर में बनाया जाता है एक ग्राहक द्वारा

---

पुराने (पूर्व 2016/01/26): जावा के अब ज्यादातर अप्रचलित विवरण और .net कार्यान्वयन:

पुन: चैनल और एक से अधिक थ्रेड, जो थोड़ा भ्रामक है की वजह से कार्यान्वयन पर इसकी निर्भरता।

जावा कार्यान्वयन: Channels are thread safe:

चैनल उदाहरणों से अधिक थ्रेड द्वारा उपयोग के लिए सुरक्षित हैं।

But:

पुष्टि ठीक से नहीं संभाला जाता है जब एक चैनल से अधिक थ्रेड

.net कार्यान्वयन के बीच साझा किया जाता है: Channels are not thread safe:

की तुलना में अधिक हैं एक थ्रेड को किसी विशेष I तक पहुंचने की आवश्यकता होती है मॉडल उदाहरण, आवेदन आपसी बहिष्करण को लागू करना चाहिए।

IModel आपरेशन के गलत क्रमबद्धता के लक्षणों में शामिल है, लेकिन, तक सीमित नहीं हैं

• अवैध फ्रेम दृश्यों तार

• NotSupportedExceptions फेंके जाने ...

तो पर भेजा जा रहा है रॉबिन के उपयोगी उत्तर के अलावा, जो कि नेट के कार्यान्वयन में पर सुरक्षित है या नहीं, इस पर लागू होता है, आप केवल कनेक्शन साझा नहीं कर सकते हैं।