कतारों का डिजाइन और नामकरण

बिंदुओं, कतारों को व्यवस्थित करने और उन्हें सुविधाजनक बनाने के लिए उन्हें सही तरीके से कैसे नाम दिया जाए, इस पर कुछ नियम।

| exchange | type | binding_queue | binding_key | |-------------------------------------------------------| | user.write | topic | user.created.app2 | user.created | 

नियम १

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

नियम २

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

नियम ३

आपूर्तिकर्ताओं को कतारों के बारे में कुछ भी जानने की जरूरत नहीं है। एएमक्यूपी के मुख्य विचारों में से एक बिंदुओं और कतारों के बीच जिम्मेदारियों का विभाजन है, ताकि आपूर्तिकर्ताओं को यह ध्यान रखने की आवश्यकता न हो कि संदेश ग्राहक तक पहुंचता है।

उदाहरण और समाधान

मान लीजिए कि आप "कस्टम" संबंधित रिकॉर्ड घटनाओं के लिए अंक और कतारें डिजाइन करना चाहते हैं। रिकॉर्डिंग की घटनाओं को एक या एक से अधिक अनुप्रयोगों में निकाल दिया जाएगा, और इन संदेशों का उपयोग कुछ अन्य अनुप्रयोगों द्वारा किया जाएगा।

 | object | event | |------------------| | user | created | | user | updated | | user | deleted | 

पहला सवाल जो आमतौर पर पूछा जाता है, वह है एक वस्तु ("उदाहरण में उपयोगकर्ता" वस्तु) की विभिन्न घटनाएं, क्या मुझे तीनों घटनाओं को प्रकाशित करने के लिए एक विनिमय बिंदु का उपयोग करना चाहिए, या प्रत्येक घटना के लिए 3 अलग-अलग बिंदुओं का उपयोग करना चाहिए? या, संक्षेप में, एक विनिमय बिंदु, या कई?

इस प्रश्न का उत्तर देने से पहले, मैं एक और प्रश्न पूछना चाहता हूं: क्या हमें वास्तव में इस मामले के लिए एक अलग बिंदु की आवश्यकता है? क्या होगा यदि हम सभी 3 प्रकार की घटनाओं को एक "राइट" इवेंट के रूप में सार करते हैं, जिनके उपप्रकार "बनाए गए", "अपडेट" और "हटाए गए" हैं?

 | object | event | sub-type | |-----------------------------| | user | write | created | | user | write | updated | | user | write | deleted | 

समाधान 1

सबसे सरल समाधान "user.write" कतार बनाना और उपयोगकर्ता के रिकॉर्डिंग ईवेंट से इस कतार तक सभी संदेशों को वैश्विक विनिमय बिंदु के माध्यम से प्रकाशित करना है।

निर्णय २

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

 | queue | subscriber | |-------------------------------| | user.write.app1 | app1 | | user.write.app2 | app2 | | exchange | type | binding_queue | |---------------------------------------| | user.write | fanout | user.write.app1 | | user.write | fanout | user.write.app2 | 

दूसरा समाधान ठीक काम करता है अगर हर ग्राहक वास्तव में "user.write" घटनाओं के सभी उपप्रकार को संभालना चाहता है। उदाहरण के लिए, यदि सब्सक्राइबर का एप्लिकेशन केवल ट्रांजेक्शन लॉग स्टोर करने के लिए डिज़ाइन किया गया है।

दूसरी ओर, यह बहुत अच्छा नहीं होता है जब कुछ ग्राहक आपके संगठन के बाहर होते हैं और आप उन्हें केवल कुछ विशिष्ट घटनाओं के बारे में सूचित करना चाहते हैं, उदाहरण के लिए, app2 को उपयोगकर्ता निर्माण के बारे में एक संदेश प्राप्त करना चाहिए और अपडेट के बारे में पता नहीं होना चाहिए और घटनाओं को हटाना चाहिए।

निर्णय ३

उपरोक्त समस्या को हल करने के लिए, हमें "user.write" प्रकार से "user.created" घटना को निकालना होगा। एक विषय प्रकार के साथ एक विनिमय बिंदु हमारी मदद कर सकता है। संदेश प्रकाशित करते समय, हम user.created / user.updated / user.deleted को एक बिंदु पर रूटिंग कुंजी के रूप में उपयोग करेंगे, इसलिए हम संचार कुंजी "उपयोगकर्ता। *" को कतार में रख सकते हैं "user.write.app1" और संचार कुंजी "user.created"। कतार में "user.created.app2"।

 | queue | subscriber | |---------------------------------| | user.write.app1 | app1 | | user.created.app2 | app2 | | exchange | type | binding_queue | binding_key | |-------------------------------------------------------| | user.write | topic | user.write.app1 | user.* | | user.write | topic | user.created.app2 | user.created | 

निर्णय ४

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

 | queue | subscriber | |---------------------------------| | user.write.app1 | app1 | | user.created.app2 | app2 | | exchange | type | binding_queue | binding_key | |--------------------------------------------------------| | user.write | direct | user.write.app1 | user.created | | user.write | direct | user.write.app1 | user.updated | | user.write | direct | user.write.app1 | user.deleted | | user.write | direct | user.created.app2 | user.created | 

हम सवाल पर लौटते हैं "एक बिंदु, या बहुत?"। जब तक सभी समाधान केवल एक बिंदु का उपयोग करते हैं, यह ठीक काम करता है, कुछ भी बुरा नहीं है। किन स्थितियों में हमें कई बिंदुओं की आवश्यकता हो सकती है?

निर्णय ५

आइए एक उदाहरण देखें, जब ऊपर वर्णित, अद्यतन, और हटाए गए घटनाओं के अलावा, हमारे पास घटनाओं का एक और समूह है: इनपुट और आउटपुट - घटनाओं का एक समूह जो "डेटा रिकॉर्डिंग" के बजाय "उपयोगकर्ता व्यवहार" का वर्णन करता है। घटनाओं के विभिन्न समूहों के लिए, कुंजियों की पूरी तरह से अलग-अलग राउटिंग रणनीतियों और समझौतों और कतारों के नाम की आवश्यकता हो सकती है, और इसके लिए अलग-अलग विनिमय बिंदुओं की आवश्यकता होती है।

 | queue | subscriber | |----------------------------------| | user.write.app1 | app1 | | user.created.app2 | app2 | | user.behavior.app3 | app3 | | exchange | type | binding_queue | binding_key | |--------------------------------------------------------------| | user.write | topic | user.write.app1 | user.* | | user.write | topic | user.created.app2 | user.created | | user.behavior | topic | user.behavior.app3 | user.* | 

लेख RabbitMQ एक्सचेंज और कतार डिजाइन व्यापार से मुक्त अनुवाद।