आशावादी कैशिंग Concurrency डिजाइन पैटर्न

Question

मेरे पास एक वेब सेवा है जो सर्वर के क्लस्टर पर चल रही है। यह वेब सेवा कुछ आंतरिक प्रसंस्करण करता है, और फिर एक बाहरी सेवा के लिए कॉल कर सकती है जो शुल्क लेती है।

मैं कुछ कैशिंग में रखना चाहता हूं ताकि अगर मुझे सेवा के लिए समान अनुरोध प्राप्त हों (जो होने की गारंटी है), तो मुझे प्रोसेसिंग समय/बिजली और लागत की लागत दोनों को प्रोसेस करना दोहराना नहीं है सेवा कॉल के बाहरी हिस्से में।

हालांकि, मैं कैसे इस कैशिंग प्रबंधन करने के लिए जब मैं निम्नलिखित की कमी

• सेवा उच्च उपलब्धता और scalability के लिए कई वेब सर्वर पर चल रहा है
• अनुरोध का समय लग सकता यह पता लगाने के लिए संघर्ष कर रहा हूँ जवाब देने के लिए 5 सेकंड तक, लेकिन इसी समय, मुझे 2 या 3 अन्य समान अनुरोध प्राप्त हुए होंगे।

वितरित वातावरण में काम करते समय पहले व्यक्ति ने जवाब दिया है (इसलिए कैश में उपलब्ध), जब तक कि मैं अन्य सेवा कॉल निष्पादित करने पर रोक नहीं सकता हूं।

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

Answer 1

आप

1. गणना अनुरोध
2. देखें कि क्या परिणाम पहले से ही इस हैश के लिए डेटाबेस में है, और यदि ऐसा है तो की एक क्रिप्टोग्राफिक हैश, यह
3. दुकान हैश डेटाबेस में के साथ वापसी कर सकता है एक "परिणाम लंबित" स्थिति
4. वेब सेवा को कॉल करें और परिणामस्वरूप डेटाबेस में पंक्ति को अपडेट करें।

चरण 2 पर, यदि हैश पहले से ही डेटाबेस में है, तो "परिणाम लंबित" स्थिति के साथ, आप प्रत्येक एक्स मिलीसेकंड डेटाबेस को मतदान कर सकते हैं और आखिरकार परिणाम वहां लौट सकते हैं।

शैतान, ज़ाहिर है, विवरण में है, क्योंकि आप क्या तुम मामले में क्या एक त्रुटि तब होती है तय करने के लिए होगा:

• आप बाद के सभी समान अनुरोधों के लिए एक त्रुटि वापसी करते हैं?
• क्या आप प्रतीक्षा थ्रेड को वेब सेवा को कॉल करने का प्रयास करते हैं?
• क्या आप एक त्रुटि वापस करते हैं, लेकिन केवल कुछ समय के लिए, और फिर पुनः प्रयास करें?

Answer 2

1.) सेवा उच्च उपलब्धता और scalability

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

यदि आप सिस्टम को अनावश्यक रखना चाहते हैं तो आपके पास केंद्रीय-कैश नहीं होना चाहिए। क्योंकि ज्यादातर बार "केंद्रीय" समाधान "विफलता का सिंगल प्वाइंट" का समानार्थी होता है - समाधान। यदि आप एप्लिकेशन सर्वर पर सिंक्रनाइज़ करते हैं तो लॉकिंग भी अधिक जटिल होती है।

आपके द्वारा पेश किए जाने वाले कितने कैश कैश हिट दर और आपके सिस्टम पर उपलब्ध संसाधनों पर थोड़ा सा निर्भर हैं। प्रति सेवा उदाहरण स्तर पर कैश करना सबसे आसान समाधान है।

2.) अनुरोध में जवाब देने में 5 सेकंड तक लग सकते हैं, लेकिन औसत समय में, मुझे 2 या 3 अन्य समान अनुरोध प्राप्त हुए होंगे।

यह एक डिज़ाइन बाधा भी है। आप अपने कैशिंग को बस 2 अलग-अलग चरणों में विभाजित करते हैं। अगर पहली धागा कैशिंग दिनचर्या और अपने मूल्य

को ताला पहुँच में प्रवेश करती है ताला समाप्त और संसाधित करने के बाद मान सम्मिलित

तुम भी जरूरत

1. सबसे पहले अपने समान अनुरोध के लिए एक महत्वपूर्ण सम्मिलित हालांकि अपवाद हैंडलिंग को संभालने के लिए।

   locking और connection तंत्र विभिन्न रणनीतियों

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

   Mutex/सेमाफोर या जो कुछ भी संरचना आप महत्वपूर्ण अनुभाग के लिए उपयोग लॉक करने के लिए अद्वितीय कुंजी पर निर्भर कर सकते (जब तक आप अपनी सेवा के लिए उपयोग को क्रमानुसार नहीं करना चाहती) का उपयोग आप समान के लिए गणना निवेदन।