2012-04-15 12 views
8

मैं एक साधारण एएसपीनेट वेब नियंत्रण को एक साथ रख रहा हूं, कि AJAX फॉर्म पोस्ट के परिणामस्वरूप एमएसक्यूएल डेटाबेस में एक रिकॉर्ड डाला गया है।एमएसएमक्यू के माध्यम से आवश्यक या ओवरकिल के माध्यम से वेब और डेटाबेस स्तरों को decoupling है?

यह संभव है कि इस नियंत्रण वाले पृष्ठ को एक छोटी सी जगह में कई हजारों हिट प्राप्त होंगी और मैं डेटाबेस कनेक्शन खोलने, रिकॉर्ड डालने और प्रत्येक अनुरोध के लिए कनेक्शन बंद करने के प्रदर्शन मुद्दे के बारे में चिंतित हूं ।

एक समाधान जो मुझे हुआ है, वेब नियंत्रण को एमएसएमक्यू कतार में एक संदेश देने के लिए है और सर्वर पर एक विंडोज सेवा समय-समय पर कतार पढ़ती है और बैच डालने का काम करती है।

क्या यह एक समझदार वास्तुकला की तरह लगता है कि वेब और डेटाबेस सर्वर एक ही मशीन पर चल रहे हैं। क्या यह जरूरी है?

डेटाबेस पर जो मैंने पढ़ा है उससे एमएसएमक्यू का उपयोग करने के अधिकांश लाभ प्रदर्शन के बजाए लचीलापन के साथ करना है, इसलिए मैं गलत पेड़ को भड़क रहा हूं।

किसी भी सलाह बहुत कृतज्ञता की सराहना की जाएगी

बहुत धन्यवाद

पीट

उत्तर

10

प्रसंस्करण अनुरोध ऑफ़लाइन इस तरह से जब आप अनुरोधों का एक उच्च मात्रा के साथ काम कर रहे हैं के लिए एक आम पैटर्न है।

चाहे आपको यह करना चाहिए या यहां तक ​​कि यह भी कई कारकों पर आधारित है।

मुख्य कारक यह है: क्या आपके कॉलर्स को उनके अनुरोधों को समकालिक रूप से प्रतिक्रिया देखने की आवश्यकता है?

मेरा मतलब क्या है कि कॉलर को तत्काल और पूर्ण निश्चितता के साथ पता होना चाहिए, अगर डेटाबेस ने कॉल प्रतिक्रिया के हिस्से के रूप में सफलतापूर्वक अपना डेटा किया है? यदि ऐसा है, तो ऑफ़लाइन प्रसंस्करण अनुरोध लेना वास्तव में एक विकल्प नहीं है।

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

पहली चीज जो लाभान्वित होगी, वह फ्रंट-एंड उपलब्धता मुद्दों है।

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

हालांकि, बैक-एंड काम की मात्रा को कम करके आईआईएस कर रहा है (स्थानीय कतार में लिखना वास्तव में डेटाबेस कॉल से संबंधित सस्ता है) आप उपलब्धता-आधारित विफलता की संभावना को भी कम कर रहे हैं।

दूसरा कतार का उपयोग करके आपके पास बैक-एंड ट्रैफिक थ्रॉटलिंग का साधन होगा, क्योंकि आपके पास बैक-एंड प्रोसेसिंग पर थ्रूपुट पर नियंत्रण है।

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

इसका मतलब यह है कि आप डेटाबेस विवाद के मुद्दों को प्राप्त करने की संभावना को कम कर रहे हैं क्योंकि आपके पास किसी भी समय डेटाबेस पर थ्रेड्स तक पहुंचने की संख्या पर अधिक नियंत्रण है।

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

इसके अलावा, आपको CQRS नामक एक आर्किटेक्चरल पैटर्न को पढ़ना चाहिए, जिसमें से केंद्रीय प्रिंसिपल में से एक है जो आपके डेटाबेस को ऑफ़लाइन लिखता है।

+0

क्रैकिंग उत्तर ह्यूग, इसके लिए बहुत बहुत धन्यवाद। पुष्टि की कि मुझे क्या संदेह है और एक बहुत कुछ और! विकल्पों की महान तुलना और स्पष्टीकरण के लिए –

+0

+ 1। आपका बहुत बहुत धन्यवाद। –

2

एक असीमित वास्तुकला में कई लाभ हैं (जैसा कि ह्यूग द्वारा पहचाना गया है) लेकिन निश्चित रूप से इसके साथ जुड़ी एक बड़ी लागत और जटिलता है। इसे ध्यान से संतुलित किया जाना चाहिए। 2 घटकों (वेब ​​ऐप और डीबी) से अब आपको 4 घटकों (वेब ​​ऐप, डीबी, बैच सेवा, एमएसएमक्यू) को विकसित, बनाए रखने और निगरानी करना होगा। आपने कहा कि वेब सर्वर और डीबी सर्वर एक ही मशीन है जो आपकी प्रदर्शन आवश्यकताओं को अजीब है। कल आपको वेब ऐप होस्ट करना पड़ सकता है, बैच सेवा और डीबी 3 अलग मशीनें हैं। अब एमएसएमक्यू में नेटवर्क भी शामिल है। एक और चीज जो गलत हो सकती है। मल्टीथ्रेडेड बैच प्रोसेसर भी आसान नहीं है, अगर आपको प्रत्येक संदेश को अनुक्रमित किया गया है (कम से कम किसी दिए गए इकाई के लिए) तर्क जटिल हो सकता है।

यदि संभव हो तो दोनों समाधानों का समाधान करें और निर्णय लें।

+2

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

संबंधित मुद्दे