खरगोश की कतारें स्मृति में रहती हैं और इसलिए डेटाबेस में इसे लागू करने की तुलना में बहुत तेज होंगी। एक (अच्छी) समर्पित संदेश कतार को कतार से संबंधित आवश्यक सुविधाएँ भी प्रदान करनी चाहिए जैसे कि थ्रॉटलिंग / प्रवाह नियंत्रण, और एक जोड़े को नाम देने के लिए विभिन्न रूटिंग एल्गोरिदम चुनने की क्षमता (खरगोश ये और अधिक प्रदान करता है)। आपके प्रोजेक्ट के आकार के आधार पर, आप संदेश पास करने वाले घटक को अपने डेटाबेस से अलग करना भी चाह सकते हैं, ताकि यदि एक घटक भारी भार का अनुभव करे, तो उसे दूसरे के संचालन में बाधा डालने की आवश्यकता नहीं है।
आपके द्वारा बताई गई समस्याओं के लिए:
-
डेटाबेस को व्यस्त और खराब प्रदर्शन को बनाए रखते हुए मतदान :Rabbitmq का उपयोग करके, निर्माता पुश . कर सकते हैं उपभोक्ताओं के लिए अद्यतन जो मतदान से कहीं अधिक प्रदर्शनकारी है। डेटा केवल उपभोक्ता को तब भेजा जाता है जब इसकी आवश्यकता होती है, फिजूलखर्ची की आवश्यकता को समाप्त करते हुए।
-
टेबल को लॉक करना -> फिर से खराब प्रदर्शन: लॉक करने के लिए कोई टेबल नहीं है :P
-
कार्य की लाखों पंक्तियाँ -> फिर से मतदान कम प्रदर्शन कर रहा है: जैसा कि ऊपर उल्लेख किया गया है, Rabbitmq तेजी से काम करेगा क्योंकि यह RAM में रहता है, और प्रवाह नियंत्रण प्रदान करता है। यदि आवश्यक हो, तो यह डिस्क का उपयोग अस्थायी रूप से संदेशों को संग्रहीत करने के लिए भी कर सकता है यदि यह रैम से बाहर हो जाता है। 2.0 के बाद, Rabbit ने अपने RAM उपयोग में काफी सुधार किया है। क्लस्टरिंग विकल्प भी उपलब्ध हैं।
AMQP के संबंध में, मैं कहूंगा कि वास्तव में एक अच्छी सुविधा "एक्सचेंज" है, और इसके लिए अन्य एक्सचेंजों को रूट करने की क्षमता है। यह आपको अधिक लचीलापन देता है और आपको विस्तृत रूटिंग टाइपोलॉजी की एक विस्तृत श्रृंखला बनाने में सक्षम बनाता है जो स्केलिंग के दौरान बहुत काम आ सकता है। एक अच्छे उदाहरण के लिए, देखें:
(source:springsource.com)
और:http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/
अंत में, रेडिस के संबंध में, हाँ, इसका उपयोग संदेश दलाल के रूप में किया जा सकता है, और यह अच्छा कर सकता है। हालाँकि, Rabbitmq में Redis की तुलना में अधिक संदेश कतारबद्ध सुविधाएँ हैं, क्योंकि Rabbitmq को एक पूर्ण-विशेषताओं वाले एंटरप्राइज़-स्तरीय समर्पित संदेश कतार के रूप में जमीन से बनाया गया था। दूसरी ओर रेडिस को मुख्य रूप से इन-मेमोरी की-वैल्यू स्टोर के रूप में बनाया गया था (हालाँकि यह अब उससे कहीं अधिक करता है; इसे स्विस आर्मी नाइफ के रूप में भी जाना जाता है)। फिर भी, मैंने कई लोगों को छोटे आकार की परियोजनाओं के लिए रेडिस के साथ अच्छे परिणाम प्राप्त करने के बारे में पढ़ा/सुना है, लेकिन बड़े अनुप्रयोगों में इसके बारे में बहुत कुछ नहीं सुना है।
यहां एक लंबे मतदान वाले चैट कार्यान्वयन में उपयोग किए जा रहे रेडिस का एक उदाहरण दिया गया है:http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/
