संदेश कतार। डेटाबेस बनाम समर्पित एमक्यू


18

मैं संदेश कतार के संबंध में सलाह के बाद हूं। हमारे पास "नौकरी" के लिए एक संदेश कतार में पोस्ट करने की आवश्यकताएं हैं।

मूल सुझाव सिर्फ SQL सर्वर इंस्टेंस का उपयोग करना और उससे संदेशों को प्रोसेस करना था। मैंने इंटरनेट पर जो कुछ भी पढ़ा है वह बताता है कि एक संदेश कतार के लिए डेटाबेस का उपयोग करना एक स्केलेबल समाधान नहीं है। इस कारण से, RabbitMQ या कुछ अन्य 3 पार्टी MQ का उपयोग करने का सुझाव दिया गया था।

दूसरी बात यह है कि "नौकरी प्रसंस्करण" के लिए आवश्यकता 30 सेकंड से कम नहीं होगी, इसलिए यह प्रक्रिया जो नौकरी करती है वह डेटाबेस को हर 30 सेकंड में प्रदूषित कर देगी। मेरे लिए, यह इतना बुरा नहीं लगता है और संभवतः डेटाबेस में एक बड़ा भार जोड़े बिना ठीक काम करेगा।

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

मैं जिस दूसरे विकल्प पर विचार कर रहा था, वह उपयोगकर्ताओं को या तो दोनों के बीच चयन करने की अनुमति दे रहा था। यदि वे एक छोटे उपयोगकर्ता हैं तो Sql सर्वर समाधान ठीक होगा, लेकिन यदि वे एक बड़े उपयोगकर्ता हैं तो हम उन्हें तृतीय पक्ष MQ समाधान कॉन्फ़िगर करने की अनुमति देते हैं।

मैं किसी भी समाधान पर नहीं बेच रहा हूं, मैं सोच रहा हूं कि किसी के पास कुछ भी है जिसे मुझे सलाह या सलाह देना चाहिए।


1
क्या ये 'नौकरियां' एक 'आग और भूल' हैं या सर्वर को उस नौकरी की स्थिति जानने के लिए घर वापस फोन करना होगा?
c_maker

कितना स्केलेबल होना चाहिए? क्या आप एक दिन या कई अरब के माध्यम से कुछ सौ हजार संदेश चला रहे हैं?
Blrfl

टिप्पणियों के लिए धन्यवाद: नौकरी को अपूर्ण के रूप में चिह्नित करने की आवश्यकता है (जब तक अपूर्ण / असफल के रूप में चिह्नित नहीं किया जाता है तब तक इसे पूर्ण माना जाता है)। मुझे लगता है कि एक दिन में 20 000 से अधिक संदेश नहीं होंगे। सबसे अधिक संभावना केवल कुछ हजार।
user1653400

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

यहाँ कुछ अच्छे संकेत हैं: rusanu.com/2010/03/26/use-tables-as-queues
माइकल ग्रीन

जवाबों:


18

मैंने इंटरनेट पर जो कुछ भी पढ़ा है वह बताता है कि एक संदेश कतार के लिए डेटाबेस का उपयोग करना एक स्केलेबल समाधान नहीं है।

वास्तविकता को अक्सर " एक्स का उपयोग न करें क्योंकि यह स्केल नहीं करता है " (लिंक में कुछ आपत्तिजनक हो सकती है भाषा शामिल है) इस पैमाने पर हमेशा महत्वपूर्ण नहीं है। मैं यह कहना चाहूंगा कि यदि आप समग्र रूप से ग्रह के चेहरे पर हर अनुप्रयोग को देखते हैं, तो पैमाना शायद ही महत्वपूर्ण है।

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

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

हालांकि आपके एप्लिकेशन का संदेश वॉल्यूम डेटाबेस या संदेश पंक्तिबद्ध करने के लिए नहीं जा रहा है, जबकि मामूली हार्डवेयर पर भी एक पसीना आ रहा है, आपके पास शायद यह आवश्यक है कि आपके संदेश लेन-देन कैसे संभाले जाएं जो एक या दूसरे को बेहतर विकल्प बनाते हैं। वे आवश्यकताएं हैं जिनका आपको मूल्यांकन करना चाहिए।


मेरे पास एक डेटाबेस है जिसमें प्रतिदिन लाखों लेनदेन होते हैं। जो मुझे एसएमएस के माध्यम से संसाधित करने की आवश्यकता है। मैं वर्तमान में sql तालिका का उपयोग कतार के रूप में कर रहा हूं, लेकिन बड़ी मात्रा में डेटा एकत्र करने पर मैं अटक जाता हूं। मैं MQ का उपयोग नहीं कर सकता क्योंकि मुझे वास्तविक समय कॉन्फ़िगरेशन के आधार पर अपने एसएमएस को रूट करने की आवश्यकता है। यदि मैं एमक्यू का उपयोग करता हूं तो यह क्लाइंट के लिए वर्तमान कॉन्फ़िगरेशन का उपयोग नहीं करता है। जैसा कि हम बैकेंड पर प्रदाता बदल रहे हैं जब कुछ प्रदाता प्रक्रिया में विफल हो जाते हैं। तो तुम लोग मुझे मेरे परिदृश्य में क्या सुझाव देते हो?
मयूर राठौड़

@mayurRathod यह विषय एक अलग प्रश्न के लिए चारा की तरह लगता है। इसे ध्यान से शब्द दें, क्योंकि विशिष्ट उपकरण या संसाधनों के लिए अनुरोध ऑफ-टॉपिक के रूप में बंद हो जाएगा।
ब्लरफुल

9

संदेश कतार वास्तव में अपने आप में आ जाती है जब आपके पास उनमें से कई होते हैं और उनके बीच संदेश भेजते हैं, एक से अधिक उपभोक्ताओं के लिए प्रशंसक आदि।

यदि आपके पास सामान की एक 'जॉब कतार' है जिसे आप 'ऑफ लाइन' प्रोसेस करना चाहते हैं तो एक SQL टेबल ठीक काम करेगी।

यह सुनिश्चित करने के लिए मत भूलें कि आपके पास नौकरियों को चिह्नित करने का कोई तरीका है-प्रगति, पुराने लोगों को साफ करना और सिस्टम बंद होने पर सतर्क करना। लेकिन एक ही कतार के लिए मैन्युअल रूप से इन चीजों का प्रबंधन एक अलग कतार समाधान को बनाए रखने की तुलना में कम काम होगा।


5

जैसा कि अन्य उल्लेख किया है पैमाने शायद यहाँ महत्वपूर्ण नहीं है। दो अलग-अलग भंडारण तंत्रों का उपयोग करने की समस्या ट्रांजेक्शनल इंटीग्रिटी है।

यदि एक समर्पित संदेश कतार के साथ जा रहा है, तो आपको विफलता के मामले में निम्नलिखित में से किसी एक को चुनना होगा।

  1. अनुमति दें कि डेटा mb पर हो सकता है लेकिन db में नहीं
  2. अनुमति दें कि डेटा db में हो सकता है लेकिन mb में नहीं
  3. Db mq के बीच दो चरण प्रतिबद्ध या वितरित लेनदेन सेट करें जो जटिल हो सकता है

ये सभी समस्याएं दूर हो जाती हैं यदि आप सामान्य लेनदेन का उपयोग करके केवल एक स्थान पर डेटा बचाते हैं। इस कारण से कार्य पंक्ति के रूप में db का उपयोग करना एक बिलकुल ठीक समाधान है।


4

व्यावहारिकता के लिए, मेरे लिए संदेश कतार का उपयोग करने के मुख्य कारण हैं:

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

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


1

मैंने एक Mssql संदेश कतार समाधान बनाया है जो एक प्रदर्शन परीक्षण के अनुसार प्रति सेकंड 20k संचालन को संभाल सकता है, और हमें अधिकतर समय 10 / सेकंड की आवश्यकता होती है। मुझे लगता है कि तथ्य यह है कि आप वास्तव में प्राथमिकता बना सकते हैं एक विशेषता है कि समर्पित संदेश कतार की कमी है। और मेरे मामले में यह एक बड़ी आवश्यकता थी।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.