Azure Queues और Service Bus Queues की तुलना करें

Microsoft Azure दो प्रकार के कतार तंत्रों का समर्थन करता है: Azure Queues और Service Bus Queues ।



एज़्योर क्यूज़ , एज़्योर स्टोरेज इंफ्रास्ट्रक्चर का हिस्सा है, जो एक सेवा के भीतर या कई सेवाओं के बीच विश्वसनीय, गारंटीकृत संदेश वितरण के लिए एक सरल रीस्ट-ओरिएंटेड गेट / पुट / पीक इंटरफेस प्रदान करता है।



सेवा बस कतार Azure संदेश संरचना का हिस्सा है जो कतार, प्रकाशन / सदस्यता, वेब सेवाओं और एकीकरण पैटर्न ( सेवा बस संदेश पैटर्न के अवलोकन में इसके बारे में अधिक) से संबंधित है।



सेवाएँ समानांतर में काम करती हैं, Azure Queues पहले Azure संग्रहण सेवाओं के शीर्ष पर निर्मित एक अलग कतार तंत्र के रूप में दिखाई दिया।

सेवा बस कतार "संदेश दलालों" अवसंरचना के शीर्ष पर बनाई गई हैं जो एप्लिकेशन या एप्लिकेशन घटकों को जोड़ने के लिए डिज़ाइन की गई हैं, जिन्हें विभिन्न प्रोटोकॉल के लिए समर्थन की आवश्यकता हो सकती है, विभिन्न डोमेन या नेटवर्क वातावरण में काम कर सकते हैं।



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

प्रौद्योगिकी विचार

दोनों Azure कतार और सेवा बस कतार Microsoft Azure प्लेटफ़ॉर्म पर सेवाओं की कतार है। उनके पास सुविधाओं का एक अलग सेट है, इसलिए आप उनमें से किसी एक का उपयोग कर सकते हैं, या दूसरे, या दोनों को एक साथ उपयोग कर सकते हैं - आपके आवेदन की आवश्यकता पर निर्भर करता है। चयन के लिए निम्नलिखित सिफारिशें हैं।



तो आपको Azure Queues चुनना चाहिए यदि:

• आपके एप्लिकेशन को एक कतार में 80 GB से अधिक डेटा संग्रहीत करने की आवश्यकता है, जिसमें प्रत्येक संदेश 7 दिनों से अधिक नहीं चलेगा।
• आपके आवेदन को कतार में संदेश प्रसंस्करण की स्थिति की निगरानी करने की आवश्यकता है। उदाहरण के लिए, आप उस कार्यकर्ता के पतन से अवगत होना चाहते हैं जो संदेश को संसाधित कर रहा था, और जब यह घटना होती है, तो किसी अन्य कार्यकर्ता को आगे की प्रक्रिया स्थानांतरित करें।
• आपको अपनी कतार में सभी लेन-देन के लॉग की आवश्यकता है।

आपको सेवा बस कतार का चयन करना चाहिए यदि:

• आपको निरंतर "मतदान" के बिना संदेश प्राप्त करने में सक्षम होना चाहिए। सेवा बस कतार टीसीपी प्रोटोकॉल का समर्थन करती है, जो आपको नए संदेशों के बारे में जानकारी जल्दी से प्राप्त करने की अनुमति देती है।
• आपको संदेश प्रसंस्करण आदेश (FIFO) के संरक्षण की गारंटी देने की आवश्यकता है।
• आपके पास Windows सर्वर के लिए सेवा बस के साथ अनुभव है और अज़ूरे में कतारों के साथ काम करते समय इसका उपयोग करना चाहते हैं।
• आप स्वचालित रूप से डुप्लिकेट संदेशों का पता लगाना चाहते हैं।
• आप अपने एप्लिकेशन में संदेशों को तथाकथित "स्ट्रीम" के समानांतर में संसाधित करना चाहते हैं (संदेश SessionId द्वारा एक स्ट्रीम से जुड़े हैं)। इस मॉडल में, संदेश प्राप्त करने वाले एप्लिकेशन का प्रत्येक नोड एक थ्रेड को संसाधित करने के लिए जिम्मेदार है। जब नोड के लिए प्रसंस्करण के लिए एक धारा प्रस्तुत की जाती है, तो बाद वाले लेनदेन का उपयोग करके धारा के साथ काम कर सकते हैं।
• संदेशों के समूह को भेजते या प्राप्त करते समय आपके आवेदन में लेन-देन की आवश्यकता होती है।
• संदेश जीवनकाल (TTL) 7 दिनों से अधिक हो सकता है।
• आपके एप्लिकेशन को 64 KB (लेकिन 256 KB से अधिक नहीं) से बड़े संदेशों को संसाधित करने की आवश्यकता है।
• आपको एक संदेश-आधारित सुरक्षा मॉडल प्रदान करने की आवश्यकता है, संदेश प्रदाताओं और संदेश उपभोक्ताओं दोनों के लिए उपयोग के विभिन्न स्तरों को लागू करें।
• कतार में सभी संदेशों का कुल आकार 80 जीबी से अधिक नहीं है।
• आप संदेश के लिए AMQP 1.0 का उपयोग करना चाहते हैं। अधिक जानकारी यहाँ - सेवा बस AMQP अवलोकन ।
• आप "एक आपूर्तिकर्ता, एक प्राप्तकर्ता" मॉडल से उस मॉडल पर जाने की सैद्धांतिक संभावना मानते हैं जहां संदेश कई आपूर्तिकर्ताओं द्वारा उत्पन्न किए जा सकते हैं और एक से अधिक प्राप्तकर्ता (संभवत: कुछ फ़िल्टरिंग नियमों द्वारा) पर रीडायरेक्ट किए जा सकते हैं।
• आपको "At-Most-Once" प्रकार की डिलीवरी की गारंटी चाहिए और आप इसके लिए एक विशेष बुनियादी ढाँचा नहीं बनाना चाहते हैं।
• आपको संदेशों को भेजने और प्राप्त करने की क्षमता है।
• आपको विंडोज कम्युनिकेशन फाउंडेशन (WCF) स्टैक और .NET फ्रेमवर्क के साथ पूर्ण एकीकरण की आवश्यकता है।

Azure Queues और Service Bus Queues की तुलना करना

निम्नलिखित अनुभागों में तालिकाओं को तार्किक समूहों में विभाजित किया गया है, जिनमें से प्रत्येक कुछ मापदंडों के लिए एज़्योर क्युएस और सर्विस बस क्युब्स की तुलना करता है।

मौलिक अवसर

तुलना की कसौटी	Azure कतारों	सेवा बस कतारें
संरक्षण की गारंटी	नहीं	हाँ - FIFO (सत्रों के उपयोग के माध्यम से)
वितरण की गारंटी	"कम से कम एक बार"	"कम से कम एक बार" "अधिकतम समय"
लेन-देन का समर्थन	नहीं	हां (स्थानीय लेनदेन के उपयोग के माध्यम से)
उत्पादन विधि	रुकावट नहीं है (कोई नया संदेश नहीं है तो तुरंत समाप्त होता है)	लॉकआउट के साथ या बिना टाइमआउट के (" धूमकेतु तकनीक " देखें) रुकावट नहीं है (.NET API का उपयोग करके)
क्लाइंट को सर्वर द्वारा "पुशिंग" संदेश	नहीं	हां OnMessage और OnMessage सेशन .NET API
उत्पादन विधि	झांकना और पट्टा	झांकना और ताला प्राप्त करें और हटाएँ
एक्सक्लूसिव मैसेज एक्सेस	लीज के आधार पर	लॉक आधारित
लीज / लॉकआउट टाइमआउट	30 सेकंड (डिफ़ॉल्ट) 7 दिन (अधिकतम) ( UpdateMessage API का उपयोग करके अपडेट या रीसेट किया जा सकता है)	60 सेकंड (डिफ़ॉल्ट) (नवीनीकृत एपीआई का उपयोग कर अद्यतन या रीसेट किया जा सकता है)
ग्रैन्युलैरिटी लीज / लॉक	संदेश स्तर (प्रत्येक संदेश का अपना समयबाह्य हो सकता है, प्रत्येक संदेश के लिए इसे अपडेटमेस एपीआई का उपयोग करके बदला जा सकता है)	कतार स्तर (प्रत्येक कतार का अपना समयबाह्य होता है, जो इस कतार के सभी संदेशों पर लागू होता है, समय-समय पर नवीनीकरण API का उपयोग करके अपडेट किया जा सकता है)
बैच रसीद	हां (प्राप्त होने पर, यह स्पष्ट रूप से इंगित किया जाता है कि कितने संदेशों की आवश्यकता है, अधिकतम 32)	हां (स्पष्ट रूप से प्रीलोड सेटिंग्स को शामिल करने या लेनदेन के माध्यम से स्पष्ट रूप से)
बैच भेज रहा है	नहीं	हां (ग्राहक पक्ष पर लेनदेन या बैच के माध्यम से)

अतिरिक्त जानकारी

• यदि आप पहले से ही एज़्योर स्टोरेज ब्लब्स और टेबल्स का उपयोग करते हैं और कतारों का उपयोग शुरू करते हैं, तो भी आपने 99.9% के भीतर सेवाओं की उपलब्धता की गारंटी दी है। यदि आप सेवा बस कतारों के साथ ब्लब्स और टेबल्स का उपयोग करते हैं - विश्वसनीयता कम होगी।
• सेवा बस कतारों में गारंटी संदेश वितरण आदेश (FIFO) लेनदेन के उपयोग की आवश्यकता है। यदि एप्लिकेशन पीक और लॉक मोड में है, तो एप्लिकेशन क्रैश हो जाता है, एप्लिकेशन को पुनरारंभ करने के बाद, यह समाप्त होते ही (TTL) जैसे ही संदेश प्राप्त होगा।
• Azure Queues मानक कतारबद्ध परिदृश्यों का समर्थन करने के लिए डिज़ाइन किया गया है, जैसे कि अलग-अलग मापनीयता के लिए अनुप्रयोग घटकों को अलग करना और व्यक्तिगत घटकों के लिए दोष सहिष्णुता।
• सेवा बस कतार, कम से कम एक बार वितरण गारंटी मॉडल का समर्थन करती है। इसके अलावा, "वन्स अपॉन ए टाइम" मॉडल को लेन-देन और परमाणु रसीद संदेशों के साथ अद्यतन सत्र स्थिति के साथ लागू किया जा सकता है। एज़्योर वर्कफ़्लो इस तकनीक का उपयोग एक बार की गारंटी पर अधिकतम एक बार प्रदान करने के लिए करता है।
• Azure Queues तालिका और ब्लॉब एक्सेस इंटरफ़ेस के समान एक एकीकृत और सुसंगत एक्सेस इंटरफ़ेस प्रदान करता है, जो कि इन सभी सेवाओं का उपयोग करने की आवश्यकता होने पर सुविधाजनक हो सकता है।
• सेवा बस कतार प्रत्येक कतार के संदर्भ में स्थानीय लेनदेन सहायता प्रदान करती है।
• सेवा बस कतारों द्वारा समर्थित "प्राप्त करें और हटाएं" मोड आपको उनकी रसीद की गारंटी को कम करने के बदले में संदेश प्राप्त करने के लिए संचालन की संख्या को कम करने की अनुमति देता है।
• Azure Queues आपको मैसेज प्रोसेसिंग टाइमआउट के आकार को संभालने की अनुमति देता है। एक कार्यकर्ता जल्दी से "लघु" संदेशों को संसाधित कर सकता है, और यदि वह अचानक दुर्घटनाग्रस्त हो जाता है, तो संदेश जल्दी से दूसरे कार्यकर्ता को स्थानांतरित कर दिए जाएंगे। उसी समय, अगर कार्यकर्ता को संदेश को संसाधित करने के लिए अधिक समय की आवश्यकता होती है, तो वह अपना समय बढ़ा सकता है, जिससे यह स्पष्ट हो जाता है कि संदेश अभी भी संसाधित किया जा रहा है।
• Azure Queues प्रकाशित होने पर आपको किसी संदेश की "अदृश्यता" के लिए समय-सीमा निर्धारित करने की अनुमति देता है। इस समयावधि के बाद ही उपभोक्ता को संदेश उपलब्ध होगा। सर्विस बस कतार भी आपको इस तरह का समय निर्धारित करने की अनुमति देती है, लेकिन केवल कतार मेटाडेटा स्तर पर।
• सेवा बस कतार में अवरुद्ध संदेश प्राप्त करने का अधिकतम समय 24 दिनों का है। हालाँकि, REST इंटरफ़ेस का उपयोग करते समय, यह टाइमआउट 55 सेकंड है।
• सेवा बस कतारों द्वारा प्रदान किए गए क्लाइंट-साइड बैच संचालन कई संदेशों को एकल भेजने के संचालन में संयोजित करने की अनुमति देते हैं। बैच भेजने केवल अतुल्यकालिक भेजने के संचालन के लिए उपलब्ध है।
• Azure Queues क्वींस (और खाता वर्चुअलाइजेशन के मामले में और भी अधिक) में दिए गए 200 टीबी तक का समर्थन और कतारों की एक असीमित संख्या इस सेवा को सास प्रदाताओं के लिए एक आदर्श मंच बनाती है।
• Azure Queues एक लचीली और शक्तिशाली पहुंच प्रतिनिधि तंत्र प्रदान करता है।

अतिरिक्त विशेषताएं

तुलना की कसौटी	Azure कतारों	सेवा बस कतारें
अनुसूचित वितरण	हां	हां
मृत संदेशों की स्वचालित मार्किंग	नहीं	हां
कतार में संदेश जीवनकाल बढ़ाएँ	हां (कतार में प्रत्येक संदेश के लिए अलग से टाइमआउट अपडेट)	हां (अलग एपीआई समारोह)
अधूरे संदेशों के लिए समर्थन	हां	हां
संदेश अद्यतन	हां	हां
सर्वर-साइड लेनदेन लॉग	हां	नहीं
भंडारण मेट्रिक्स	हां मिनट मेट्रिक्स: उपलब्धता के लिए वास्तविक समय, टीपीएस, एपीआई कॉल की संख्या, त्रुटियों की संख्या, आदि, स्टोरेज एनालिटिक्स मेट्रिक्स के बारे में देखें	हां ( GetQueues विधि)
राज्य प्रबंधन	नहीं	हां Microsoft.ServiceBus.Messaging.EntityStatus.Active , Microsoft.ServiceBus.Messaging.EntityStatus.Disabled , Microsoft.ServiceBus.Messaging.EntityStatus.SendDisabled , Microsoft.ServiceBus.Messaging.EntityStatus.ReceiveDisabled
ऑटो संदेश अग्रेषण	नहीं	हां
पूरी कतार साफ करें	हां	नहीं
संदेश समूह	नहीं	हां (संदेश सत्र के माध्यम से)
एक संदेश समूह के लिए आवेदन की स्थिति	नहीं	हां
डुप्लिकेट डिटेक्शन	नहीं	हां (प्रेषक पक्ष पर कॉन्फ़िगर करने योग्य)
डब्ल्यूसीएफ के साथ एकीकरण	नहीं	हां (WCF द्वारा प्रदान की गई - बाइंडिंग)
WF के साथ एकीकरण	बाहरी (अपने स्वयं के WF गतिविधियों के निर्माण की आवश्यकता है)	एकीकृत (WF गतिविधियों द्वारा प्रदान की गई)
संदेश देखें समूह	नहीं	हां
सत्र आईडी द्वारा विशिष्ट संदेशों के संदेश प्राप्त करना	नहीं	हां

अतिरिक्त जानकारी

• दोनों कतार प्रौद्योगिकियां आपको एक विशिष्ट समय के लिए संदेश वितरण में देरी करने की अनुमति देती हैं।
• स्वचालित संदेश पुनर्निर्देशन आपको एक कतार में हजारों कतार से संदेश एकत्र करने की अनुमति देता है। आप सुरक्षा, नियंत्रण प्रक्रियाओं और संदेश प्रदाताओं को एक दूसरे से अलग करने के लिए इस तंत्र का उपयोग कर सकते हैं।
• Azure Queues एक संदेश की सामग्री को संशोधित करने की क्षमता का समर्थन करता है। आप इस संदेश के अनुरूप कार्य की प्रगति को अपडेट करने के लिए इसका उपयोग कर सकते हैं, ताकि यदि आवश्यक हो, तो उपयोगकर्ता को यह जानकारी दिखाएं या वांछित चरण से प्रसंस्करण जारी रखें, और पहले नहीं। सेवा बस कतारों में, आप सत्रों का उपयोग करके एक समान परिदृश्य लागू कर सकते हैं। सत्र आपको आवेदन की स्थिति को बचाने और प्राप्त करने की अनुमति देता है ( सेटस्टेट और गेटस्ट्रेट विधियों का उपयोग करके)।
• डेड मेल प्रोसेसिंग मैकेनिज्म, जो सर्विस बस क्यूस द्वारा समर्थित है, आपको उन संदेशों को अलग करने की अनुमति देता है जो प्राप्तकर्ता द्वारा सफलतापूर्वक संसाधित नहीं किए जा सकते हैं या जो उनके जीवन काल (टीटीएल) के अंत तक पहुंच गए हैं। इस तरह के संदेशों को $ डेडलेटरक्यूयू नामक एक विशेष कतार में ले जाया जाएगा।
• एप्लिकेशन पक्ष पर Azure Queues में आंशिक रूप से समान तंत्र लागू किया जा सकता है - DequeueCount संपत्ति की जाँच करके, आप कुछ संदेशों को दूसरी कतार में पुनर्निर्देशित कर सकते हैं।
• Azure Queues आपको प्रत्येक कतार के लिए सभी लेन-देन का विस्तृत लॉग, और साथ ही कुछ एग्रीगेटेड मेट्रिक्स प्राप्त करने की अनुमति देता है। डिबगिंग और समझने के लिए दोनों विशेषताएं बहुत उपयोगी हैं कि आपके एप्लिकेशन कतार का उपयोग कैसे करते हैं। वे प्रदर्शन का अनुकूलन करने में मदद करते हैं और कतारों का उपयोग करते समय लागत को कम करते हैं।
• सेवा बस कतारों द्वारा समर्थित "संदेश सत्र" की अवधारणा, प्रत्येक संदेश को एक तार्किक समूह से संबंधित होने की अनुमति देता है जो एक एकल प्राप्तकर्ता के साथ जुड़ा हो सकता है। आप प्रत्येक संदेश के लिए सत्र फ़ील्ड को भरकर इस कार्यक्षमता का उपयोग कर सकते हैं। इसके बाद प्राप्तकर्ता केवल विशिष्ट SessionID वाले कतार संदेशों से अनुरोध कर सकता है।
• सेवा बस क्यू द्वारा समर्थित डुप्लिकेट डिटेक्शन तंत्र स्वचालित रूप से कतार से एक ही मैसेजआईडी वाले संदेशों को हटा देता है।

क्षमता और कोटा

तुलना की कसौटी	Azure कतारों	सेवा बस कतारें
अधिकतम कतार का आकार	200 टीबी (एक खाते के लिए कुल भंडारण द्वारा सीमित)	1 जीबी से 80 जीबी (कतार निर्माण चरण के दौरान निर्धारित)
अधिकतम संदेश का आकार	64 केबी (४64 KB जब बेस ६४ एन्कोडिंग का उपयोग कर रहे हैं) एज़्योर कतारों और ब्लब्स के संयोजन से बड़े संदेशों का समर्थन करता है - तो आप वास्तव में एक संदेश में २०० जीबी तक डेटा स्टोर कर सकते हैं	256 KB (संदेश के हेडर और बॉडी सहित, हेडर का अधिकतम आकार 64 KB है)
अधिकतम संदेश जीवनकाल	7 दिन	सीमित नहीं है
कतारों की अधिकतम संख्या	सीमित नहीं है	10000 (प्रति नामस्थान, बढ़ाया जा सकता है)
ग्राहकों की अधिकतम संख्या	सीमित नहीं है	सीमित नहीं है (टीसीपी प्रोटोकॉल ग्राहकों के लिए 100 कनेक्शन)

अतिरिक्त जानकारी

• Azure Queues के लिए, यदि संदेश सामग्री में ऐसे वर्ण हैं, जो XML में संग्रहीत नहीं किए जा सकते हैं, तो उसे Base64 में एन्कोड किया जाना चाहिए। कृपया ध्यान दें कि इस स्थिति में संदेश में पेलोड का आकार 48 केबी से अधिक नहीं होना चाहिए।
• सेवा बस कतारों के लिए, प्रत्येक संदेश में एक शीर्षक और एक निकाय होता है। कुल संदेश का आकार 256 KB से अधिक नहीं होना चाहिए।
• जब ग्राहक टीसीपी पर सर्विस बस क्यूस का उपयोग करते हैं, तो एक कतार में सक्रिय कनेक्शन की कुल संख्या 100 से अधिक नहीं होनी चाहिए। प्रेषक और प्राप्तकर्ता दोनों को ध्यान में रखा जाता है। यदि यह कोटा हो जाता है, तो बाद के अनुरोध अस्वीकार कर दिए जाएंगे। यह सीमा उन ग्राहकों पर लागू नहीं होती है जो REST API के माध्यम से कतार का उपयोग करते हैं।
• सेवा बस कतारों की कतार आकार सीमाएँ हैं। वे तब सेट होते हैं जब कतार बनाई जाती है और 1 से 80 जीबी तक हो सकती है। यदि सीमा समाप्त हो जाती है, तो अगला संदेश कतार में स्वीकार नहीं किया जाएगा। अधिक जानकारी - एज़्योर सर्विस बस कोटा ।
• यदि आपको समान नामस्थान में 10,000 से अधिक सेवा बस कतारों की आवश्यकता है, तो आप Azure तकनीकी सहायता से संपर्क कर सकते हैं और आपके लिए सीमा में वृद्धि के लिए पूछ सकते हैं। लेकिन यह Microsoft Azure Management Portal के माध्यम से अतिरिक्त नाम स्थान बनाने के लिए सरल और तेज़ हो सकता है।

प्रबंधन और पहुंच

तुलना की कसौटी	Azure कतारों	सेवा बस कतारें
नियंत्रण प्रोटोकॉल	HTTP / HTTPS पर REST	HTTPS से अधिक की परीक्षा
संचालन का प्रोटोकॉल	HTTP / HTTPS पर REST	HTTPS से अधिक की परीक्षा AMQP 1.0 मानक (टीएलएस के साथ टीसीपी)
.NET एपीआई	हां (.NET संग्रहण क्लाइंट API)	हां (संदेश ब्रोकरों के लिए .NET एपीआई)
देशी c ++	हां	नहीं
जावा एपीआई	हां	हां
PHP एपीआई	हां	हां
Node.js एपीआई	हां	हां
कस्टम मेटाडेटा समर्थन	हां	नहीं
कतार नामकरण नियम	63 वर्ण तक (पत्र कम होना चाहिए)	260 वर्ण तक (कतार नाम केस-असंवेदनशील हैं)
कतार में संदेशों की संख्या प्राप्त करना	हां (अनुमानित, उन संदेशों को छोड़कर, जिनके लिए TTL की समय सीमा समाप्त हो गई है और वे हटाने की प्रक्रिया में हैं)	हां (सटीक)
संदेशों को कतार में देखने का कार्य उन्हें चुने बिना	हां	हां

अतिरिक्त जानकारी

• एज़्योर कतार कुंजी / मान जोड़े के रूप में कतार में मेटाडेटा की एक मनमानी राशि जोड़ने की क्षमता प्रदान करती है।
• दोनों कतार प्रौद्योगिकियां कतार में संदेशों को देखने / उन्हें बदलने / हटाने के बिना अनुमति देती हैं, जो कतार देखने के उपकरण को लागू करने के लिए उपयोगी हो सकता है।
• सेवा बस टीसीपी कनेक्शन के आधार पर .NET एपीआई का समर्थन करती है, जो आरईएसटी अनुरोधों या एएमक्यूपी 1.0 प्रोटोकॉल की तुलना में अधिक कुशलता से काम करती है।
• एज़ुरे क्यू में कतार का नाम 3 से 63 अक्षरों तक लंबा हो सकता है, इसमें विभिन्न मामलों, संख्याओं और हाइफ़न में पत्र शामिल हो सकते हैं। अधिक जानकारी - नामकरण कतार और मेटाडाटा ।
• सेवा बस कतार में कतार का नाम 260 वर्णों तक हो सकता है और इसमें अक्षरों और संख्याओं के अलावा वर्ण शामिल हो सकते हैं '।', '-' और '_'।

उत्पादकता

तुलना की कसौटी	Azure कतारों	सेवा बस कतार
अधिकतम थ्रूपुट	प्रति सेकंड 2000 संदेशों तक (1 केबी के संदेशों के लिए)	प्रति सेकंड 2000 संदेशों तक (1 केबी के संदेशों के लिए)
औसत देरी	10 मि (टीसीपी नागले विकलांग के साथ)	20-25 मि
अधिभार व्यवहार	HTTP कोड 503 (अनुरोध भुगतान नहीं किया गया है)	HTTP कोड 503 (अनुरोध भुगतान नहीं किया गया है)

अतिरिक्त जानकारी

• एक एकल एज़्योर कतार कतार प्रति सेकंड 2000 लेनदेन तक की प्रक्रिया कर सकती है। लेनदेन एक पुट , गेट और डिलीट ऑपरेशंस हैं। एक संदेश को कतार ( पुट ) में भेजना एक लेन-देन माना जाता है, लेकिन संदेश प्राप्त करना अक्सर दो-चरणीय संचालन होता है - संदेश को पहले प्राप्त करना चाहिए ( प्राप्त करें ) और फिर कतार से हटा दिया गया ( हटाएं ), जिसके परिणामस्वरूप दो लेनदेन होते हैं। यह मत भूलो कि लेनदेन की संख्या को कम करने के लिए, आप एक अनुरोध के साथ 32 संदेश प्राप्त कर सकते हैं, हालांकि आपको अभी भी उन्हें एक बार में एक पंक्ति से हटाना होगा। थ्रूपुट को बढ़ाने के लिए, आप अधिक कतारें बना सकते हैं (कुल संख्या सीमित नहीं है)।
• जब आपका एप्लिकेशन प्रति सेकंड 2000 से अधिक संदेशों को संसाधित करने का प्रयास करता है, तो आपको "HTTP 503 सर्वर व्यस्त" प्रतिक्रिया प्राप्त होगी। इस मामले में, आपको कतार में कॉल की आवृत्ति कम करनी चाहिए।
• Azure Queues में औसत विलंबता 10 ms है जब कतार में समान क्षेत्र में स्थित Azure सेवा वर्चुअल मशीन के साथ कार्य करते समय 10 KB तक संदेश संसाधित करता है
• यदि अधिकतम बैंडविड्थ पार हो गई है तो दोनों कतार सेवाएं कतार अनुरोधों को अस्वीकार करती हैं। दोनों सेवाओं को ऐसे अनुरोधों का भुगतान करने के लिए नहीं माना जाता है।
• सेवा बस कतार प्रदर्शन परीक्षण से पता चला कि एक कतार 1 केबी के संदेश आकार में प्रति सेकंड 2000 संदेशों तक की प्रक्रिया कर सकती है। अधिक थ्रूपुट के लिए, कई कतारों का उपयोग करें। अधिक जानकारी - सेवा बस ब्रोकेड मैसेजिंग का उपयोग करते हुए प्रदर्शन में सुधार के लिए सर्वश्रेष्ठ अभ्यास ।
• जब सर्विस बस क्यू का उपयोग करके अधिकतम थ्रूपुट प्राप्त किया जाता है, तो आपको एक सर्वरब्यूसेप्शन मिलेगा (जब .NET एपीआई का उपयोग करते हुए) या "HTTP 503 सर्वर व्यस्त" (बाकी एपीआई का उपयोग करते समय)।

प्रमाणीकरण और प्राधिकरण

तुलना की कसौटी	Azure कतारों	सेवा बस कतारें
प्रमाणीकरण	सममित कुंजी द्वारा	सममित कुंजी द्वारा
अभिगम नियंत्रण मॉडल	प्रत्यायोजित SAS टोकन एक्सेस	ACS पर RBAC
पहचान प्रदाताओं का संघ	नहीं	हां

अतिरिक्त जानकारी

• प्रत्येक कतार अनुरोध को प्रमाणित किया जाना चाहिए। सार्वजनिक अनाम कतारों का समर्थन नहीं किया जाता है। एसएएस का उपयोग करके, आप अपने एप्लिकेशन के विभिन्न परिदृश्यों का निर्माण कर सकते हैं।
• Azure Queues में प्रमाणीकरण योजना में सममित कुंजी का उपयोग किया जाता है, जो कि Base64 में एन्हांस्ड SHA-256 हैश राशि है। Azure Queues — Authenticating Access to Your Storage Account , Service Bus Queues — Shared Access Signature Authentication with Service Bus .
• Microsoft Azure Active Directory Access Control ( Access Control Service ACS) Service Bus, : Admin , Sender Receiver , Azure Queues.
• Service Bus ACS, Active Directory ( ADFS) , Live ID, Google, Facebook Yahoo.

कीमतों

	Azure Queues	Service Bus Queues
	$0.0005 ( 10,000 )	$0.01 ( 10,000 )
		Send Receive ( — )
	( , )	( )
	$0.07 ( )	$0.00
	$0.12 — $0.19 ( -)	$0.12 — $0.19 ( -)

अतिरिक्त जानकारी

• , - Azure .
• Azure - .
• .
• ACS- Service Bus Queues . Service Bus Queues ACS ( 20 ). , ACS-.
• , , Service Bus Queues .

टिप्पणी

. Pricing Overview .

निष्कर्ष

Azure Queues और Service Bus Queues के बीच चयन करने का निर्णय कई कारकों, आपके आवेदन की आवश्यकताओं और इसकी वास्तुकला पर निर्भर करता है। यदि आप पहले से ही अन्य Azure सेवाओं का उपयोग करते हैं, जैसे तालिकाओं या बूँदें, तो आप अभी Azure Queues का उपयोग करना शुरू कर देंगे, खासकर यदि आपको केवल कतार का उपयोग करने के लिए बुनियादी परिदृश्यों की आवश्यकता है। दूसरी ओर, सर्विस बस कतार कई अतिरिक्त सुविधाएँ प्रदान करती हैं, जैसे कि सत्र, लेनदेन, डुप्लिकेट डिटेक्शन, "डेड" संदेशों का स्वचालित प्रसंस्करण, जो आपके आवेदन के लिए आवश्यक हो सकता है।