मैं एक परियोजना के लिए Azure Event Hub का उपयोग करने पर विचार कर रहा हूं, जिस पर मैं वर्तमान में काम कर रहा हूं। हम आज कमांड के लिए सर्विस बस कतार का उपयोग कर रहे हैं और यहां हम एक कतार प्रति मैसेजटाइप का उपयोग कर रहे हैं।क्या ईवेंट हब संदेश प्रकार पर विभाजित होना चाहिए?
क्या यह कई इवेंट हब रखने के लिए समझ में आता है या क्या यह कई संदेश प्रकारों के लिए एक हब का उपयोग करना बेहतर है?
यह एक प्रश्न है जो ट्रेडऑफ से भरा हुआ है और इस बारे में निर्णय ले रहा है कि आप कौन से सिस्टम बनाने की उम्मीद करते हैं और भविष्य में और वे विभिन्न घटना प्रकारों का उपयोग कैसे कर सकते हैं।
नीचे some of the guidance जे Kreps से एक अंश अपाचे काफ्का के शीर्ष सीमाओं उपभोक्ता समूहों की संख्या पर कम अवधारण अवधियां और सीमाओं द्वारा लगाये गए प्रमुख अपवाद के साथ साथ ही घटना केन्द्रों के लिए अच्छी तरह से लागू होता है (पर सिस्टम डिजाइन करने के लिए प्रदान की है)।
चलिए शुद्ध ईवेंट डेटा-कंपनी के अंदर होने वाली गतिविधियों के साथ शुरू करते हैं। एक वेब कंपनी में ये क्लिक, इंप्रेशन और विभिन्न उपयोगकर्ता क्रियाएं हो सकती हैं। फेडेक्स में पैकेज डिलीवरी, पैकेज पिक अप, ड्राइवर पोजीशन, अधिसूचनाएं, स्थानान्तरण आदि शामिल हो सकते हैं।
इस प्रकार की घटनाओं को प्रति क्रिया प्रकार के एक लॉजिकल स्ट्रीम के साथ प्रदर्शित किया जा सकता है। सादगी के लिए मैं एवरो स्कीमा और विषय को वही चीज़ नाम देने की सलाह देता हूं, उदा। PageViewEvent। यदि घटना में प्राकृतिक प्राथमिक कुंजी है तो आप इसका उपयोग काफ़का में डेटा विभाजन के लिए कर सकते हैं, अन्यथा काफ्का क्लाइंट स्वचालित रूप से आपके लिए शेष डेटा लोड करेगा।
...
हम एक ही विषय में एकाधिक ईवेंट मिश्रण के साथ विभिन्न समय पर प्रयोग किया और पाया यह आम तौर पर जटिलता अनुचित करने के लिए नेतृत्व। इसके बजाय प्रत्येक कार्यक्रम को अपना विषय दें और उपभोक्ता हमेशा मिश्रित फ़ीड प्राप्त करने के लिए ऐसे कई विषयों की सदस्यता ले सकते हैं।
मैं आम तौर पर इस सलाह से सहमत हूं (और यदि आप इवेंट हब्स/काफ्का/किनेसिस पर सिस्टम तैयार कर रहे हैं तो आपको उस संपूर्ण ब्लॉग पोस्ट को पढ़ना चाहिए)। जिन सदस्यों को वे रुचि नहीं रखते हैं उन्हें अनदेखा करने वाले सब्सक्राइबरों को न केवल परेशान करना है, यदि घटनाओं में से कोई एक संयुक्त धारा पर हावी होना शुरू कर देता है तो यह समस्याग्रस्त हो जाता है।
लेकिन कई धाराएं रखने और उन्हें एक साथ जोड़ने के लिए लागत होती है, और उन्हें निर्णय लेने में वजन कम करने की आवश्यकता होती है। मैंने कुछ ऐसे लोगों को सूचीबद्ध किया है जो दिमाग में आते हैं।
आप एक ही स्रोत से अलग-अलग प्रकार की घटनाओं के बीच आदेश खो देते हैं जब तक आप इसे वापस जोड़ने का प्रयास नहीं करते।
यदि आप एक साथ विभिन्न विषयों पर प्रगति करना चाहते हैं तो आपको उन्हें प्रबंधित करने की आवश्यकता है।
यदि आप विषयों के बीच साझा की गई प्राथमिक कुंजी पर ईवेंट स्ट्रीम को विभाजित कर रहे हैं और प्रत्येक विषय में विभाजन को एक साथ यात्रा करना चाहते हैं, तो आप EventProcessorHost जैसे उच्च स्तरीय क्लाइंट का उपयोग नहीं कर सकते क्योंकि विभाजन अलग-अलग हो सकते हैं प्रक्रियाओं।
एक प्रति थ्रेड के साथ एक उपभोक्ता विषयों की संख्या से आवश्यक संख्या में थ्रेड को गुणा करता है। शायद एक मुद्दा नहीं जब तक कि आपके पास महंगे ढांचे नहीं हैं जिन्हें साझा नहीं किया जा सकता है।
अपने ही तैनाती में हम अलग अलग घटना प्रकार के लिए अलग-अलग घटना केन्द्रों का उपयोग भले ही हम वर्तमान में उन सब को कार्रवाई करने के लिए एक ही कोड का उपयोग करें। यह केवल इसलिए है क्योंकि मैं नए घटकों को जोड़ने की उम्मीद करता हूं जो केवल कुछ घटना प्रकारों की परवाह करते हैं। मुझे आशा है कि इससे मदद मिलती है, और सबसे बुरी बात यह है कि मैंने आपको कफका के सिद्धांत के सिद्धांत के बाद मार्गदर्शन देखने के लिए कहा है और यह अब तक रहा है।
बहुत अच्छे उत्तर के लिए धन्यवाद, मुझे लगता है कि मैं अब के लिए एक डोमेन के साथ एक स्ट्रीम शुरू करूंगा। इस तरह एक संभावित ग्राहक को घटनाओं की संख्या को अवहेलना करना होगा न्यूनतम और मैं अभी भी डोमेन के भीतर विभिन्न घटनाओं का आदेश प्राप्त करूंगा। –
एक कतार प्रति मैसेजटाइप का उपयोग करने के आपके वर्तमान कारण क्या हैं? क्या आप जो ईवेंट भेज रहे हैं उसकी मात्रा के कारण, या विभिन्न मैसागेटिप्स को संसाधित करना आसान बनाते हैं? वर्तमान में आपके पास कितने अलग संदेश प्रकार हैं? –
सभी प्रक्रियाओं को सभी मैसेजटाइप (कमांड) को संसाधित नहीं करना चाहिए। जब हमारे पास एक कतार प्रति मैसेज टाइप होता है तो प्रत्येक प्रक्रिया कतार/मैसेजटाइप की सदस्यता ले सकती है, जिस पर इसकी परवाह है। यह आदेशों के लिए समझ में आता है, लेकिन घटनाक्रम के लिए ईवेंट हब का उपयोग करने के बारे में हम क्या सोच रहे हैं। इन घटनाओं को संभावित रूप से प्रत्येक प्रक्रिया द्वारा संसाधित किया जा सकता है क्योंकि आदेशों के विपरीत जिन्हें केवल एक बार संसाधित किया जाना चाहिए। –
उस स्थिति में ऐसा लगता है जैसे आप एक इवेंट हब का उपयोग कर सकते हैं। प्रत्येक घटना उपभोक्ता (आपकी शब्दावली में प्रक्रिया) अपने स्वयं के उपभोक्ता समूह का उपयोग कर सकती है जो इसे इवेंट स्ट्रीम का अपना दृष्टिकोण देती है और घटनाओं को उचित तरीके से संसाधित करती है (अधिक जानकारी के लिए https://msdn.microsoft.com/en-us/library देखें /azure/dn836025.aspx)। ध्यान दें कि एक एकल इवेंट हब 20 उपभोक्ता समूहों तक का समर्थन करता है। –