सिग्नलर Azure EventHub

Question

के साथ स्केलिंग सिग्नलर के लिए उच्च आवृत्ति स्केलिंग समाधान देख रहा हूं। मैं सोच रहा हूं कि क्या मैं इसे Azure EventHub के साथ कर सकता हूं। अगर मैं सिग्नलआर संदेशों के लिए इवेंटहब का उपयोग अपने बैकप्लेन के रूप में करता हूं, तो क्या यह मेरे लिए बाधा बन जाएगा?

मैंने this पृष्ठ की जांच की है लेकिन EventHub के बारे में कुछ भी नहीं है क्योंकि यह बिल्कुल नया है।

Answer 1

मैं सिग्नलआर के सटीक विनिर्देशों से बात नहीं कर सकता; हालांकि, आप सैद्धांतिक रूप से बैकप्लेन के लिए इवेंट हब्स का उपयोग कर सकते हैं, लेकिन आपको सीमाओं से अवगत होना चाहिए।

सिग्नलआर का बैकप्लेन स्केलआउट पैटर्न मानता है कि सभी सर्वरों के पास सभी संदेशों तक पहुंच होगी और उन सभी को अनुमान लगाया जाएगा। यह कमोडिटी हार्डवेयर या क्लाउड में एक बैकप्लेन क्या कर सकता है, इस पर एक स्पष्ट स्पष्ट सीमा प्रदान करता है। एक सामान्य क्लाउड में आप 100 एमबी/एस डेटा थ्रूपुट (1 जीबी/एस एनआईसी के लिए अच्छा राउंड नंबर), कमोडिटी हार्डवेयर (और एज़ूर की एचपीसी मशीन) के ऊपरी छोर को 1000 एमबी/एस (10 जीबीटी/सेकंड एनआईसी) बनाए रखने में सक्षम हो सकते हैं।

तो सवाल यह है कि Azure EventHubs आपको थ्रूपुट पर इस वास्तुशिल्प सीमा पर ले जा सकता है?

इसका उत्तर बस हाँ है। 100 या 1000 विभाजन आपको पर्याप्त लेखन थ्रूपुट, और 2 सर्वरों के लिए पर्याप्त पढ़ने की क्षमता प्रदान करेंगे।

अगला प्रश्न यह है कि, यदि आपको प्रति बैकप्लेन में केवल 100 एमबी/सेकेंड पढ़ने की आवश्यकता है, तो कितने सर्वर डेटा पढ़ सकते हैं (यानी यदि आप 100 एमबी/सेकेंड स्टॉक स्टॉक को प्रसारित कर रहे हैं जहां डेटा का आकार बढ़ता नहीं है सर्वर की संख्या के साथ)।

यहां जवाब है, जितना आप चाहते हैं लेकिन कुछ चाल हैं।

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

सबसे सरल समाधान उच्च स्तरीय ऑटोबाउंडिंग इवेंट प्रोसेसर होस्ट का उपयोग करने की संभावना है, प्रत्येक सर्वर के साथ एक निश्चित नाम के साथ प्रत्येक उपभोक्ता समूह है। प्रत्येक उपभोक्ता समूह में केवल एक सर्वर के साथ प्रत्येक सर्वर को सभी विभाजन प्राप्त होंगे (10 सर्वर के लिए 500 100 एमबी/सेकेंड हिट करने के लिए, उर्फ ​​$ 11k/month + $ 0.028 प्रति मिलियन ईवेंट)।

इस दृष्टिकोण में एक महत्वपूर्ण सीमा है: आप 20 consumer groups per event hub तक सीमित हैं। तो आप अनियंत्रित संख्या पाने के लिए एक साथ इवेंट हब्स चेन कर सकते हैं या इस दृष्टिकोण के साथ एक पेड़ बना सकते हैं।

दूसरा विकल्प उन विशिष्ट ग्राहकों का उपयोग करना है जो विशिष्ट विभाजन से जुड़ते हैं। A single partition in a consumer group can have 5 readers जिससे 5 के कारक द्वारा चेनिंग हब्स की आवश्यकता को कम किया जाता है जिससे प्रति घटना लागत 5 के कारक द्वारा काटती है (थ्रूपुट इकाई आवश्यकताओं को कम नहीं करता है)।

संक्षेप में, किसी भी बैकप्लेन को बाधा बनने से पहले इसे बोतल की गर्दन नहीं बननी चाहिए। लेकिन यदि आप ट्रैफिक में 100 एमबी/सेकेंड से आगे जाने की उम्मीद करते हैं तो बैकप्लेन पर कुछ न बनाएं।

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