2013-02-27 137 views
6

के बिना एमएसएमक्यू में एक पुनः प्रयास तंत्र बनाना मेरे पास कई मौजूदा एप्लिकेशन हैं जो सिस्टम के माध्यम से एमएसएमक्यू का उपयोग करके संदेश भेजते और प्राप्त करते हैं। मैसेजिंग एपीआई। कतार आम तौर पर गैर-लेनदेन होते हैं और एमएसएमक्यू 3 और 4 का मिश्रण होते हैं।डब्ल्यूसीएफ

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

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

क्या कोई भी किसी भी उदाहरण का सुझाव दे सकता है या किसी भी उदाहरण को इंगित कर सकता है यदि कोई डब्लूसीएफ का उपयोग नहीं कर रहा है तो पुनः प्रयास करें?

उत्तर

7

मैं ऐसा करने के लिए एक एकल, लोकप्रिय पैटर्न नहीं ढूंढ पाया। लेकिन सिस्टम में थोड़ा सा पोक करने के बाद। मैसेजिंग, मैं संदेश गुणों और एमएसएमक्यू व्यवहार का लाभ उठाने में सक्षम था जो मुझे लगता है कि कम से कम चलने वाले हिस्सों के साथ काम करने का एक उचित तरीका था।

यहां मैंने जो लागू किया है।यह पता चला काफी सरल और हल्के होने के लिए - ज्यादा नहीं कोड और आसान बनाए रखने के लिए:

मैंने किसी चीज़ RetryLevel बुलाया तीन गुण है कि बनाया:

पूर्णांक आदेश, पूर्णांक NumberOfRetries, TimeSpan देरी

रिसीवर एप्लिकेशन की कॉन्फ़िगरेशन में अब रेट्रीलेवल की एक सूची है। इसलिए नई सुविधा मूल रूप से एन-स्तरीय रीट्रीज़ का समर्थन करती है।

फिर मैंने RetryInfo नामक एक ऑब्जेक्ट बनाया।

पूर्णांक प्रयास, स्ट्रिंग SourceQueuePath

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

अंत में नष्ट करने की अनुमति देता है, मैं जोड़ा रिसीवर की कॉन्फ़िगरेशन के लिए एक प्रतीक्षा कतार पथ। यह कतार वह जगह है जहां वे "टाइमआउट" में संदेश छोड़ दिए जाएंगे।

तो अब, जब कोई संदेश हैंडलर संदेश को खारिज कर दिया, रिसीवर यह, RetryInfo है अगर वहाँ एक है, और की (पिछले) नंबर पर लग रहा है यह निर्धारित करने के लिए कॉन्फ़िगर किया गया RetryLevels की यह तक पहुँच गया है प्रयास deserializes।

रिसीवर तब संदेश की टाइम टॉबीरसीड (टीटीबीआर) संपत्ति को डेटटाइम पर सेट करता है.अब प्लस उपयुक्त रेट्रीलेवल का देरी मूल्य। इसके बाद यह RetryInfo की SourceQueuePath प्रॉपर्टी से बनाई गई कतार में व्यवस्थापकीय क्यूयू प्रॉपर्टी सेट करता है और संदेश की स्वीकृति टाइप को स्वीकार करने के लिए सेट करता है। नकारात्मक रीसीव। अंत में, यह संदेश प्रतीक्षा कतार पर रखता है।

यहां से, एमएसएमक्यू संदेश के टीटीबीआर देखता है। जब यह समय समाप्त हो जाता है, तो एमएसएमक्यू संदेश को अपनी प्रशासनिक क्यूई प्रॉपर्टी में कतार पर वापस रखता है जो मूल रूप से संदेश से प्राप्त कतार है। अगर संदेश हैंडलरों द्वारा खारिज कर दिया जाना चाहिए, तो यह सिर्फ रेट्रीलेवल तक पहुंच जाता है।

यदि किसी संदेश के प्रयास कॉन्फ़िगर किए गए रेट्रीलेवल पर सभी नंबरऑफेट्रीज़ से परे हैं, तो संदेश की टीटीबीआर प्रॉपर्टी टाइमस्पेन.जेरो पर सेट की जाती है, UseDeadLetterQueue प्रॉपर्टी सत्य पर सेट होती है और संदेश किसी भी तरह की प्रतीक्षा कतार में डाल दिया जाता है अन्य पुनः प्रयास करें। इस बार, हालांकि, यह तुरंत समाप्त हो जाता है और एमएसएमक्यू इसे प्रतीक्षा कतार के मेजबान सिस्टम मृत पत्र कतार (डीएलक्यू) में भेजता है जहां इसे मैन्युअल रूप से निपटाया जा सकता है।

0

जैसा कि आप कहते हैं कि आप पहिया का पुन: आविष्कार नहीं करना चाहते हैं, मैं सुझाव देता हूं कि MassTransit या अन्य जैसे कई उपलब्ध ढांचे का उपयोग करें।

व्यक्तिगत रूप से, मैंने NServiceBus के साथ सकारात्मक अनुभव किया, जो एमएसएमक्यू के शीर्ष पर बैठता है।

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

यह आप आसानी से की तरह कुछ कॉन्फ़िगर कर सकते हैं: "। मैं 5 पुनर्प्रयास भीतर सही ढंग से इस संदेश को संसाधित नहीं कर सकता है, तो यह मेरी त्रुटि कतार में कदम "

यह वह जगह है एक बाहर के बॉक्स कार्यक्षमता।

उदाहरण विन्यास (आधिकारिक दस्तावेज से), प्रकाशक भाग के app.config ध्यान दें:

Basic Publisher/Subscriber configuration from official documentation http://images.nservicebus.com/basic_pubsub.png

गैर WCF भाग के लिए के रूप में, किसी भी NServiceBus .NET अनुप्रयोग के लिए बस के रूप में अच्छी तरह से काम करता है। आपके पास डीएलएल का संदर्भ देने का विकल्प है, या आप स्थानीय सेवा के रूप में अपने आवेदन को होस्ट करने के लिए एनएस सेवाबस का उपयोग कंटेनर के रूप में कर सकते हैं, या आप इसे विंडोज सेवा के रूप में स्थायी रूप से पंजीकृत कर सकते हैं। और अंत में, यदि आप एक दिन अपने दिमाग को बदल देंगे, तो, और डब्ल्यूसीएफ पर स्विच करें जो भी समर्थित होगा। :-)

+0

धन्यवाद जेन्स। मुझे NServiceBus और MassTransit के बारे में पता है जो डब्ल्यूसीएफ की तरह हैं, एमएसएमक्यू के शीर्ष पर बनाए गए अनुप्रयोगों ने पुनः प्रयास की है। लेकिन मेरा सवाल यह है कि यदि आप एमएसएमक्यू के शीर्ष पर एक एप्लीकेशन बना रहे हैं तो पुनः प्रयास कार्यक्षमता बनाने का एक अच्छा तरीका क्या है। मेरे आवेदन को दूसरे के साथ बदलने का अच्छा तरीका नहीं है। –