डेटाबेस लेनदेन के साथ घालमेल RabbitMQ

Question

स्थिति की कल्पना कीजिए:

var txn = new DatabaseTransaction(); 

var entry = txn.Database.Load<Entry>(id); 
entry.Token = "123"; 
txn.Database.Update(entry); 

PublishRabbitMqMessage(new EntryUpdatedMessage { ID = entry.ID }); 

// A bit more of processing 

txn.Commit(); 

अब EntryUpdatedMessage के एक उपभोक्ता संभवतः इस संदेश से पहले लेन-देन txn लिए प्रतिबद्ध है मिलता है और इसलिए कर सकते हैं अद्यतन देखने के लिए सक्षम नहीं होगा।

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

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

इसे संभालने का सही तरीका क्या है?

Answer 1

खरगोश एमक्यू आपको लेनदेन के बजाय प्रकाशक पुष्टि का उपयोग करने के लिए प्रोत्साहित करता है। लेनदेन अच्छी तरह से प्रदर्शन नहीं करते हैं।

किसी भी मामले में, लेनदेन आमतौर पर सेवा उन्मुख वास्तुकला के साथ बहुत अच्छी तरह से काम नहीं करते हैं। 'अंततः संगत' दृष्टिकोण को अपनाना बेहतर होता है, जहां बाद की तारीख में विफलता का पुन: प्रयास किया जा सकता है और डुप्लिकेट बेवकूफ संदेशों को नजरअंदाज कर दिया जाता है।

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