उत्कृष्ट प्रश्न मैट (+1), और मुझे लगता है कि श्री ओलिवर ने खुद जवाब (+1) के रूप में जवाब दिया!
मैं थोड़ा अलग दृष्टिकोण में फेंकना चाहता था जिसे मैं अपने आप देख रहा हूं ताकि आप देख रहे 3,000 प्रतिबद्ध-प्रति-सेकंड की बाधाओं में मदद कर सकें।
सीक्यूआरएस पैटर्न, जो लोग जोलिवर के इवेंटस्टोर का उपयोग करने का प्रयास कर रहे हैं, वे कई "स्केल आउट" उप-पैटर्न की अनुमति देते हैं। पहला व्यक्ति आमतौर पर कतार छोड़ देता है, यह घटना स्वयं को प्रतिबद्ध करती है, जिसमें आप एक बाधा देख रहे हैं। "कतार बंद" जिसका मतलब वास्तविक काम से ऑफलोड किया गया है और उन्हें कुछ लिखने-अनुकूलित, गैर-अवरुद्ध I/O प्रक्रिया में डालना है, या " कतार"।
मेरे ढीला व्याख्या है:
कमान प्रसारण -> कमान हैंडलर -> इवेंट प्रसारण -> ईवेंट हैंडलर्स -> इवेंट स्टोर
इन पैटर्न में वास्तव में दो पैमाने बाहर अंक यहाँ कर रहे हैं: कमांड हैंडलर और इवेंट हैंडलर। जैसा कि ऊपर बताया गया है, इवेंट हैंडलर भागों या इवेंटस्टोर लाइब्रेरी में आपके मामले में कमेट्स को स्केल करने के साथ सबसे अधिक शुरुआत होती है, क्योंकि यह आमतौर पर इसे कहीं भी जारी रखने की आवश्यकता के कारण सबसे बड़ी बाधा है (उदा। माइक्रोसॉफ्ट एसक्यूएल सर्वर डेटाबेस)।
मैं स्वयं कुछ अलग-अलग प्रदाताओं का उपयोग कर रहा हूं ताकि इन कामों को "कतार" करने के लिए सर्वोत्तम प्रदर्शन के लिए परीक्षण किया जा सके। कॉच डीबी और .NET के ऐपफैब्रिक कैश (जिसमें एक महान GetAndLock() सुविधा है)। [ओटी] मुझे वास्तव में ऐपफैब्रिक की टिकाऊ-कैश विशेषताएं पसंद हैं जो आपको अनावश्यक कैश सर्वर बनाने देती हैं जो कई क्षेत्रों में आपके क्षेत्रों का बैकअप लेती है - इसलिए, आपका कैश तब तक जीवित रहता है जब तक कम से कम 1 सर्वर ऊपर और चल रहा हो। [/ OT]
तो, कल्पना करें कि आपके इवेंट हैंडलर इवेंटस्टोर को सीधे काम नहीं लिखते हैं। इसके बजाए, आपके पास एक हैंडलर उन्हें "कतार" प्रणाली में डालें, जैसे कि विंडोज एज़ूर क्यूई, कॉच डीबी, मेमकेचे, ऐपफैब्रिक कैश इत्यादि। बिंदु यह है कि घटनाओं को कतार में रखने के लिए बहुत कम ब्लॉक वाले सिस्टम को चुनना है, लेकिन कुछ यह अनावश्यकता के साथ टिकाऊ है (मेमकैच रिडंडेंसी विकल्पों के लिए मेरा सबसे पसंदीदा पसंदीदा है)। आपके पास उस अनावश्यकता होनी चाहिए, अगर कोई सर्वर गिरता है, तो आपके पास अभी भी घटना कतारबद्ध है।
अंततः इस "कतारबद्ध घटना" से प्रतिबद्ध होने के लिए, कई विकल्प हैं। मुझे इसके लिए विंडोज़ एज़ूर की कतार पैटर्न पसंद है, क्योंकि कई "श्रमिकों" के कारण आप लगातार कतार में काम की तलाश कर सकते हैं। लेकिन यह विंडोज़ एज़ूर होने की ज़रूरत नहीं है - मैंने बैकग्राउंड थ्रेड में चल रहे "कतार" और "वर्कर रोल" का उपयोग करके स्थानीय कोड में अज़ूर की कतार पैटर्न की नकल की है। यह वास्तव में अच्छी तरह से तराजू।
कहें कि आपके पास 10 उपयोगकर्ता लगातार अपडेट किए गए कार्यक्रमों के लिए इस "कतार" में देख रहे हैं (मैं आमतौर पर प्रति ईवेंट प्रकार में एक एकल कार्यकर्ता भूमिका लिखता हूं, क्योंकि आप प्रत्येक प्रकार के आंकड़ों की निगरानी करते हैं, इसलिए स्केलिंग आसान हो जाता है)। दो घटनाओं को कतार में डाला जाता है, पहले दो श्रमिक तुरंत एक संदेश उठाते हैं, और उन्हें एक ही समय में सीधे उन्हें अपने ईवेंटस्टोर में डालें (मल्टीथ्रेडिंग, जैसा कि जोनाथन ने अपने जवाब में उल्लेख किया था। उस पैटर्न के साथ आपकी बाधा आपके द्वारा चुने गए डेटाबेस/ईवेंटस्टोर बैकिंग का भी होगा। कहें कि आपका इवेंटस्टोर एमएसएसक्यूएल का उपयोग कर रहा है और बाधा अभी भी 3,000 आरपीएस है। यह ठीक है, क्योंकि सिस्टम को 'पकड़ने' के लिए बनाया गया है जब उन आरपीएस नीचे गिरते हैं, 20,000 विस्फोट के बाद 50 आरपीएस कहते हैं। यह प्राकृतिक पैटर्न सीक्यूआरएस है: "अंतिम संगति"।
मैंने कहा कि सीक्यूआरएस पैटर्न के मूल निवासी पैटर्न थे। जैसा कि मैंने ऊपर बताया है, दूसरा, कमांड हैंडलर (या कमांड इवेंट्स) है। यह एक है जिसे मैंने भी किया है, खासकर यदि आपके पास एक बहुत ही समृद्ध डोमेन डोमेन है क्योंकि मेरे क्लाइंट में से एक है (प्रत्येक कमांड पर प्रोसेसर-गहन सत्यापन जांच के दर्जनों)। उस स्थिति में, मैं कुछ कार्यकर्ता भूमिकाओं द्वारा पृष्ठभूमि में संसाधित होने के लिए वास्तव में कमांड को स्वयं कतार में डाल दूंगा।यह आपको एक अच्छा स्केल आउट पैटर्न भी देता है, क्योंकि अब इवेंटनस्टोर समेत आपके पूरे बैकएंड को थ्रेड किया जा सकता है।
जाहिर है, इसका नकारात्मक पक्ष यह है कि आप कुछ वास्तविक समय सत्यापन जांच खो देते हैं। मैं हल करता हूं कि मेरे डोमेन को संरचित करते समय आमतौर पर दो श्रेणियों में सत्यापन को विभाजित करके। एक डोमेन में अजाक्स या रीयल-टाइम "लाइटवेट" सत्यापन है (जैसे प्री-कमांड चेक की तरह)। और अन्य हार्ड-विफलता सत्यापन जांच हैं, जो केवल डोमेन में किए जाते हैं लेकिन रीयलटाइम जांच के लिए उपलब्ध नहीं हैं। इसके बाद आपको डोमेन मॉडल में कोड-इन-विफलता की आवश्यकता होगी। मतलब, कुछ विफल होने पर हमेशा बाहर निकलने के लिए कोड, आमतौर पर उपयोगकर्ता को वापस एक अधिसूचना ईमेल के रूप में कुछ गलत हो जाता है। चूंकि उपयोगकर्ता अब इस कतारबद्ध कमांड द्वारा अवरुद्ध नहीं है, इसलिए आदेश विफल होने पर उन्हें अधिसूचित करने की आवश्यकता है।
और आपकी सत्यापन जांच जो 'बैकएंड' पर जाने की आवश्यकता है, आपकी क्वेरी या "केवल-पढ़ने" डेटाबेस पर जा रही है, riiiight? एक अद्वितीय ईमेल पता, कहने के लिए इवेंटस्टोर में न जाएं। आप अपने सामने के अंत की क्वेरीज़ के लिए अपने अत्यधिक उपलब्ध पढ़ने-योग्य डेटास्टोर के खिलाफ अपना सत्यापन कर रहे होंगे। हेक, एक सिंगल कॉच डीबी दस्तावेज़ सिस्टम में सभी ईमेल पतों की केवल एक सूची के लिए समर्पित है क्योंकि सीक्यूआरएस के आपके प्रश्न भाग के रूप में।
सीक्यूआरएस सिर्फ सुझाव है ... यदि आपको वास्तव में भारी सत्यापन विधि की रीयलटाइम जांच की आवश्यकता है, तो आप इसके आसपास एक क्वेरी (केवल पढ़ने के लिए) स्टोर बना सकते हैं, और सत्यापन को तेज कर सकते हैं - प्रीकॉमैंड चरण पर, पहले यह कतार में डाला जाता है। लचीलापन के बहुत सारे। और मैं यह भी तर्क दूंगा कि खाली उपयोगकर्ता नाम और खाली ईमेल जैसी चीजों को मान्य करना भी एक डोमेन चिंता नहीं है, लेकिन यूआई जिम्मेदारी (डोमेन में वास्तविक समय सत्यापन करने की आवश्यकता को बंद करना)। मैंने कुछ परियोजनाओं का आर्किटेक्चर किया है जहां मेरे एमवीसी/एमवीवीएम व्यू मॉडल्स पर बहुत समृद्ध यूआई सत्यापन था। बेशक, मेरे डोमेन को बहुत सख्त सत्यापन था, यह सुनिश्चित करने के लिए कि यह प्रसंस्करण से पहले मान्य है। लेकिन मध्यस्थ इनपुट-सत्यापन जांच को स्थानांतरित करना, या जिसे मैं "हल्के वजन" सत्यापन को कॉल करता हूं, व्यूमोडेल परतों में ऊपर, मेरे डोमेन तक पहुंचने के बिना, अंतिम उपयोगकर्ता को निकट-तत्काल प्रतिक्रिया देता है। (आपके डोमेन के साथ समन्वयित रखने के लिए युक्तियां भी हैं)।
तो संक्षेप में, संभवतया उन घटनाओं को कतारबद्ध करने से पहले उन घटनाओं को कतार में देखना देखें। यह इवेंटस्टोर की बहु-थ्रेडिंग सुविधाओं के साथ अच्छी तरह से फिट बैठता है क्योंकि जोनाथन ने अपने जवाब में उल्लेख किया है।
जवाब जोनाथन के लिए धन्यवाद। स्पष्ट करने के लिए;) प्रत्येक Commit एक नया EventSource है, इसलिए मैं प्रति सेकेंड 3K विशिष्ट ईवेंट स्रोतों का उपयोग कर रहा हूं। नेटवर्क हॉप को उजागर करने से चीजों में सुधार नहीं हुआ लेकिन यह एक वैध बिंदु है। जहां तक लेनदेन का संबंध है, मैं लेनदेन में स्पष्ट रूप से शामिल नहीं हूं लेकिन यह लेनदेन का उपयोग न करने जैसा ही नहीं हो सकता है। मैं सीरियलाइजेशन के लिए जेएसओएन का उपयोग कर रहा हूं हालांकि हम सीपीयू बाध्य नहीं हैं, मुझे नहीं लगता कि यह अभी तक सीमित है। मैंने गिटहब (https://github.com/MattCollinge/EventStore-Performance-Tests.git) पर टेस्ट दोहन प्रकाशित किया है। – MattC