वेब आधारित IMAP क्लाइंट का निर्माण करते समय, क्या मुझे वेब सर्वर सीधे आईएमएपी सर्वर पर बात करनी चाहिए या क्या मेरे पास मध्य में डेटाबेस होना चाहिए जो आवश्यक होने पर सिंक्रनाइज़ हो जाए?क्या एक वेब आधारित IMAP क्लाइंट का अपना डेटाबेस होना चाहिए?
तथ्य यह है कि आप सवाल पूछ रहे हैं इसका मतलब है कि आप चिंतित हैं कि वेबमेल फ्रंट एंड आईएमएपी बैकएंड के साथ प्रभावी ढंग से काम नहीं करेगा। मैं कुछ कारणों के बारे में सोच सकते हैं, कृपया मुझे सही अगर मैं गलत हूँ:
एक महत्वपूर्ण निर्णय बिंदु बनाने की आवश्यकता है, लेकिन मुझे लगता है कि यह इस बात पर निर्भर करता है कि आपको जिस आईएमएपी सर्वर से कनेक्ट करने की आवश्यकता है वह आपके संगठन के लिए आंतरिक या बाहरी है।
इस पृष्ठभूमि में, आप क्योंकि आप जानते हैं कि इस परत जोड़ने हो जाएगा, यदि आप एक डेटाबेस के बिना प्राप्त कर सकते हैं विचार कर रहे हैं समयरेखा (डिजाइन, विकास और परीक्षण के लिए)
आंतरिक IMAP सर्वर - प्रदर्शन
सबसे पहले, यह शायद प्रणाली बेंचमार्क करने के लिए एक अच्छा विचार है, अगर वहाँ वास्तव में एक प्रदर्शन हिट है देखने के लिए। मेरा आंत कहता है कि वहां एक होना जरूरी नहीं है, क्योंकि वहाँ बहुत अधिक प्रतिक्रियाशील वेबमेल सिस्टम हैं।
सबसे पहले, बहुत अच्छे IMAP प्रॉक्सी सर्वर हैं जो आपको IMAP कनेक्शन को जीवित रहने की विलम्ब को कम करने में सक्षम बनाता है। उदाहरणों में शामिल हैं:
दूसरे, यदि आप एक प्रणाली के रूप में IMAP सर्वर और वेबमेल वेब अनुप्रयोग को देखो, यह शायद समझ में आता है, जिसे आप अभी तक एक और डेटाबेस में IMAP डेटा कैश नहीं है। आप आईएमएपी सर्वर से डाटाबेस लेटेंसीज को अपने डेटाबेस में पेश करेंगे, डेटा और डाटाबेस मैनेजमेंट सिरदर्द लेंगे और विफलता के कई नए बिंदुओं के साथ सिस्टम जटिलताओं को पेश करेंगे।
इसके बजाय, क्या आप अपने आईएमएपी सर्वर को वेबमेल ऐप के उपयोग के लिए अनुकूलित कर सकते हैं? इसमें अतिरिक्त सर्वर खरीदने या अपने वर्तमान को अपग्रेड करना शामिल हो सकता है - लेकिन साथ ही, आपका वेबमेल सर्वर इतना छोटा होगा और आपको इसके लिए डेटाबेस सर्वर नहीं खरीदना होगा।
आईएमएपी सर्वर के पास प्रदर्शन के लिए लगभग निश्चित रूप से आंतरिक कैश हैं, और लगभग निश्चित रूप से एक डेटाबेस (अपने स्वयं के कैशिंग आदि के साथ) का उपयोग करता है - इसे कई वर्षों से कई वर्षों में ट्यून और डिबग किया गया है। आप उस अनुभव और परिपक्वता का उपयोग कर सकते हैं।
चलो एक काल्पनिक समस्या की कल्पना करें - प्रणाली बड़ी हो जाती है और प्रदर्शन समस्याओं का सामना करना शुरू कर देती है। कस्टम डीबी टेबल के साथ कस्टम एप्लिकेशन को ट्यून करना और स्केल करना आसान है, या वाणिज्यिक समर्थन के साथ व्यापक रूप से उपयोग किए जाने वाले वाणिज्यिक या ओपन सोर्स आईएमएपी सर्वर को स्केल करना आसान है और अच्छा, परीक्षण किया गया दस्तावेज?
बाहरी IMAP सर्वर - यातायात को कम करने और अधिकतम प्रदर्शन
इस चिंता के साथ, उद्देश्य क्योंकि वे समय (नेटवर्क विलंबता) या पैसे में महंगे हैं IMAP प्रोटोकॉल कॉल को कम करना है।
सबसे पहले, आप एक IMAPProxy (जैसा ऊपर वर्णित) का उपयोग कर सकते कनेक्शन जिंदा रहने सुनिश्चित करने के लिए और उन में लॉग इन किया।
साथ ही, मैं तर्क है कि आप एक डेटाबेस का उपयोग करने की आवश्यकता है, लेकिन एक कैश के मोड में एक पूर्ण डेटा मॉडल के बजाय। उदाहरण के लिए, यदि आप एक NoSQL डीबी इस्तेमाल कर सकते हैं (या तो मुख्य-मान या वस्तु डाटाबेस) बल्कि एक एसक्यूएल डीबी से:
इस तरह से लागू करने काम बहुत का उपयोग-केस या उपयोगकर्ता के कहानी विशिष्ट कर देगा, लागत और जोखिम को कम करें और सिस्टम को अधिक टेस्टेबल बनाएं। यदि आपके कार्यान्वयन में कोई गंभीर समस्या है, तो पूरे कैश को फ़्लश किया जा सकता है और सेवा बहाल की जाएगी।
डेटा और डेटाबेस प्रबंधन भी बहुत आसान होगा, और पूर्ण उपयोगकर्ता का मेलबॉक्स संग्रहीत नहीं किया जाएगा।
बाहरी IMAP सर्वर - कट मॉडल
यह धारणाओं आप एक बाहरी IMAP सेवा के लिए एक वेबमेल क्लाइंट प्रदान कर रहे हैं, और आप जानते हैं कि समय-समय पर कि बाहरी IMAP सेवा ऑफ़लाइन चला जाता है, अभी तक आप अभी भी ईमेल प्रदान करने की आवश्यकता उपयोगकर्ताओं के लिए।
यहां, आपको स्पष्ट रूप से स्थानीय डेटाबेस में उपयोगकर्ताओं के ईमेल को दर्पण करने की आवश्यकता है। मैं सुझाव दूंगा कि आप एक आर्किटेक्चरल समाधान देखें जहां आपके पास स्थानीय IMAP सर्वर है और आप तीसरे पक्ष के IMAP सर्वर को मिरर करने के लिए कई ओपन सोर्स IMAP सिंक्रनाइज़ेशन टूल का उपयोग करते हैं।यहाँ लाभ हैं:
नुकसान कर रहे हैं:
आप स्थानीय रूप से कई IMAP सर्वर से एक का उपयोग कर सकते हैं और तुल्यकालन के लिए, यहाँ कुछ संभावनाएं हैं:
(अस्वीकरण : मैंने इन औजारों का उपयोग नहीं किया है एफ)
इस पूरी तरह से आवश्यकताओं पर निर्भर करता है, सेवा के महत्व प्रदान किया जाना है और समय की राशि है जो आप है ;-)
मैं याहू, rediffmail IMAP के साथ मामलों में जहां मेल randon समय पर redownloaded थे देखा है मेरी ब्लैकबेरी पर। (आपकी जानकारी के लिए। ब्लैकबेरी मेल सेवाएं पहले सभी मेलों को आईएमएपी सर्वर से अपने सर्वर पर डाउनलोड करती हैं और फिर इसे डिवाइस पर वितरित करती हैं।)
इंटरमीडिएट का उपयोग करना एक अच्छा विचार है क्योंकि यह किसी भी सर्वर को कम कर सकता है संबंधित मुद्दों जैसे मेल फ़ेच त्रुटि, यादृच्छिक बग या सर्वर क्रैश। यहां तक कि मेल से संबंधित गतिविधियां मेल की तरह तेज़ी से मेल की जाएंगी, हटाए जाएंगे, अलग-अलग फ़ोल्डर में ले जाया जा सकता है, भले ही नियत IMAP सर्वर डाउन हो।
समस्या इससे थोड़ा अधिक जटिल है। वास्तविक संदेशों को सिंक्रनाइज़ करना वास्तविक समस्या नहीं है क्योंकि मैं यह सुनिश्चित करने के लिए यूआईडी का उपयोग कर सकता हूं कि वेबसाइट + अन्य क्लाइंट सिंक हो। समस्या यह है कि फ़ोल्डर में यूआईडी नहीं है, ऐसा लगता है कि आपको उन्हें हर बार डाउनलोड करना होगा, जो समय लेने वाला हो सकता है। (एसओ पर पोस्ट ट्रिगर्स पोस्ट दबाकर, यह बेवकूफ यूएक्स है, जारी है :) किसी इमेप फ़ोल्डर और डेटाबेस पर संदेशों को डुप्लिकेट करना मेरे लिए गलत लगता है, विशेष रूप से क्योंकि स्टोरेज लागत बढ़ जाएगी। –
मैं मानता हूं कि सभी संदेशों को imap से डेटाबेस में डुप्लिकेट करना एक अच्छा विचार नहीं है। हालांकि डेटाबेस पर हाल के संदेशों को कैशिंग करना कुछ भी गलत नहीं है। और आप डेटाबेस में एक इंडेक्स बनाना चाहते हैं ताकि आपका वेब इंपैप क्लाइंट बहुत बेहतर और तेज खोज कर सके। – howanghk
मुझे लगता है कि उपयोगकर्ता डेटाबेस दृष्टिकोण से काफी लाभ उठाएगा और शायद डेटाबेस में संग्रहीत हालिया संदेशों की संख्या सीमित करके भंडारण लागत को काटा जा सकता है। यह उपयोगकर्ता को एक स्नैपी प्रारंभिक लोड प्रदान करेगा ताकि वे नवीनतम ईमेल पढ़ सकें और IMAP सर्वर सिंक की प्रतीक्षा किए बिना बाहर निकल सकें। डेटाबेस दृष्टिकोण फ़ोल्डर समस्या का समाधान भी हो सकता है क्योंकि आप पिछली बार कनेक्ट किए गए डाउनलोड को कैश कर सकते हैं, फिर उपयोगकर्ता को सर्वर सिंक के लिए प्रतीक्षा करने से रोकने में पृष्ठभूमि में अपडेट करें। संक्षेप में उपयोगकर्ता डेटाबेस दृष्टिकोण के साथ खुश होगा और यही मायने रखता है।
कम से कम एक डेटाबेस है जो संदेश शीर्षलेख संग्रहीत करता है; मेरे अनुभव में आईएमएपी सर्वर से हेडर लाने के प्रदर्शन को वांछित होने के लिए बहुत कुछ छोड़ देता है। आईएमएपी सर्वर को मारने के बिना उपयोगकर्ता को खोज करने की अनुमति देता है (संदेश बॉडी सर्च के अलावा यदि आप केवल डेटाबेस में हेडर संग्रहित कर रहे हैं)। –