क्या खरगोश एमक्यू, ज़ीरोएमक्यू, सर्विस ब्रोकर या उच्च उपलब्धता डेटाबेस webservice बनाने के लिए कुछ उपयुक्त समाधान है?

Question

मेरे पास एक सीआरयूडी webservice है, और यह सुनिश्चित करने के लिए एक तरीका जानने का प्रयास किया गया है कि डेटाबेस डाउन होने पर हम डेटा खोना नहीं चाहते हैं। हर कोई जानता है कि यदि डेटाबेस नीचे चला जाता है तो हम "पढ़े" नहीं पाएंगे, लेकिन संचालन के एक विशिष्ट सबसेट के लिए हम यह सुनिश्चित करना चाहते हैं कि हम डेटा न खोएं।

मुझे यह इंप्रेशन दिया गया है कि यह ऐसा कुछ है जो 0MQ, RabbitMQ, या Microsoft MQ सेवाओं में से एक जैसी सेवाओं द्वारा कवर किया गया है। हालांकि पढ़ने और शोध के कुछ दिनों के बाद, मुझे यह भी यकीन नहीं है कि एमक्यू सेवाओं में जिन संदेशों के बारे में हम बात कर रहे हैं उनमें डेटाबेस ऑपरेशंस शामिल हैं। हालांकि मैं 100% निश्चित हूं कि मैं कई हेलो दुनिया को कतारबद्ध कर सकता हूं क्योंकि मैं कभी उम्मीद कर सकता हूं।

यदि मैं डेटाबेस में सुरक्षा की परत जोड़ने के लिए एक संदेश कतार का उपयोग कर सकता हूं, तो मैं खरगोश की तरफ झुकता हूं (क्योंकि यह क्रैश के माध्यम से जारी रहता है) लेकिन चूंकि लक्ष्य एक माइक्रोसॉफ्ट एसक्यूएल सर्वर डेटाबेस है, शायद एक उनके समाधान (जैसे कि एसक्यूएल सेवा ब्रोकर, या एमएसएमक्यू) अधिक उपयुक्त है।

असली मौलिक सवाल है कि मुझे अभी तक यकीन नहीं है कि मैं कार्ड के दाहिने डेक (इसलिए बोलने के लिए) भी खेल रहा हूं।

उच्च-लाभकारी webservice की इच्छा के साथ, यदि डेटाबेस डाउन हो जाता है तो यह काम करना जारी रखता है, क्या यह वेब सेवा और डेटाबेस के बीच "खरगोश एमक्यू उदाहरण" को रखने का अर्थ है? शायद श्रृंखला में सही लिंक है RabbitMQ वेबसर्वर को संदेश भेजना है?

या क्या यह प्राप्त करने के लिए कोई अन्य समाधान है? डाटाबेस आउटेज या कुछ की स्थिति में वेबलॉग को रोल करने के तरीके खोजने के लिए इस समय कई खोने वाले विचार हैं ... लेकिन हम अभी भी पर्याप्त चरणों में हैं (कम से कम मुझे) मुझे नहीं पता कि मैं क्या हूं ' मैं करने जा रहा हूँ।

संदेश सही समाधान कतार है?

Answer 1

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

अतिरिक्त रूप से कतार का उपयोग करके आप डेटाबेस यातायात की मात्रा पर नियंत्रण प्राप्त करते हैं, आपके डेटाबेस को शीर्ष पर संभालना पड़ता है।

हालांकि, ऐसा करने के लिए आपको यह पता होना चाहिए कि जब डेटाबेस लेखन किया जाता है तो अनुरोध कतारबद्ध होता है और ऑफ़लाइन वितरित और संसाधित किया जाएगा।

यहां तक ​​कि ऐसी स्थितियों के तहत जहां यह लगभग तत्काल होता है, आप लाभ खो रहे हैं आपकी वर्तमान सेवा की तुल्यकालिक प्रकृति आपको अनुमति देती है। और यह लाभ यह है कि आपका सेवा उपभोक्ता (या वेब क्लाइंट) हमेशा यह जान सकता है कि ऑपरेशन सफल रहा है या नहीं।

मैंने here से पहले इस विषय के बारे में लिखा है। प्रश्न पोस्ट करने वाले उपयोगकर्ता को आपके लिए समान चिंताएं थीं। चाहे आप ऐसा करते हों या नहीं, आपको निर्णय लेना है।

तकनीकी ढेर के बारे में आप सोच रहे हैं, 0 एमक्यू वास्तव में एक संदेश कतार प्रणाली नहीं है, यह स्टेरॉयड पर सॉकेट की तरह है।

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

सेवा ब्रोकर एक डेटाबेस तकनीक है और SqlDependency के माध्यम से कोड के साथ अच्छी तरह से एकीकृत नहीं है, या स्ट्रीमइन्सटाइट मंच पर सक्षम नोटिफिकेशन नामक कुछ है।

मैं एमएसएमक्यू (जो ट्रांज़ेक्शनल कतारों के माध्यम से टिकाऊ मैसेजिंग का समर्थन करता है) के लिए जाता है क्योंकि यह हल्का वजन है, विंडोज का हिस्सा है, और इसमें कोर .net लाइब्रेरी सपोर्ट है।