2012-04-23 14 views
63

मैं वर्तमान में अपने सत्रों को स्टोर करने के लिए डीबी (mysql) का उपयोग कर रहा हूं। यह बहुत अच्छा काम करता है लेकिन यह थोड़ा धीमा है।रेडिस के साथ सत्र स्टोर करना कितना सुरक्षित है?

मुझे रेडिस का उपयोग करने के लिए कहा गया है, लेकिन मुझे आश्चर्य है कि यह एक अच्छा विचार है क्योंकि मैंने सुना है कि रेडिस लिखने में देरी करता है, इसलिए मुझे थोड़ा डर है क्योंकि सत्रों को वास्तविक समय होना चाहिए।

क्या आपको ऐसी समस्याएं मिली हैं?

+1

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

+1

हाँ, लेकिन यह मेरी आवश्यकता का हिस्सा है, उपयोगकर्ताओं को वापस लॉग इन नहीं करना चाहिए, जिस तरह से कुछ उपयोगकर्ता डेटा सत्र में बने रहते हैं, जबकि उपयोगकर्ता लॉग इन नहीं होते हैं (अतिथि उपयोगकर्ता)। वे रेडिस रैम के लिए जाएंगे लेकिन लॉगिंग और/या बैकअप सक्षम होंगे। अगर हम कुछ सत्र खो देते हैं तो यह स्वीकार्य है। – Trent

+0

ठीक है, अगर आप हार्ड डिस्क स्टोरेज का उपयोग कर रहे हैं, तो रेडिस का उपयोग करने का क्या मतलब है? यह शायद प्रदर्शन को बढ़ाने के लिए डिस्क पर वास्तविक प्रतिबद्धता में देरी करता है, वैसे ही अगर MySQL ऐसा कॉन्फ़िगर किया गया हो तो ऐसा कर सकता है। क्या आपने अपने MySQL को तेज़ I/O उपप्रणाली में ले जाने पर विचार किया था?ऐसा नहीं है कि रेडिस उसी हार्डवेयर पर 50 गुना तेजी से काम करेगा, अगर इसे एक ही I/O subsys का उपयोग करना है। –

उत्तर

110

रेडिस सत्रों को संग्रहित करने के लिए बिल्कुल सही है। सभी परिचालन स्मृति में किया जाता है, और इसलिए पढ़ता है और लिखता तेज़ होगा।

दूसरा पहलू सत्र स्थिति का दृढ़ता है। Redis आपको अपनी हार्ड डिस्क पर सत्र स्थिति को जारी रखने के तरीके में बहुत लचीलापन देता है। आप अधिक जानने के लिए http://redis.io/topics/persistence के माध्यम से जा सकते हैं, लेकिन एक उच्च स्तर पर है, आपके विकल्प हैं -

  1. आप किसी भी सत्र को खोने का जोखिम नहीं उठा सकते हैं, तो आपके विन्यास फाइल में appendfsync always निर्धारित किया है। इसके साथ, रेडिस गारंटी देता है कि डिस्क पर किसी भी लेखन ऑपरेशन को सहेजा जाता है। नुकसान यह है कि लिखने के संचालन धीमे हो जाएंगे।
  2. यदि आप लगभग 1s डेटा खोने के ठीक हैं, तो appendfsync everysec का उपयोग करें। यह उचित डेटा गारंटी
9

असल में दो मुख्य प्रकार उपलब्ध हैं: async snapsnots और fsync()। उन्हें क्रमशः आरडीबी और एओएफ कहा जाता है। persistence modes on the official page पर अधिक।

डिमोनाइज्ड प्रक्रिया का सिग्नल हैंडलिंग डिस्क पर सिंक्रनाइज़ करता है जब इसे उदाहरण के लिए SIGTERM प्राप्त होता है, इसलिए डेटा रीबूट के बाद भी होगा। मुझे लगता है कि डिफ़ॉल्ट सेटिंग्स (आरडीबी स्नैपशॉट्स) के साथ भी, आप एक ईमानदारी भ्रष्टाचार को देखने से पहले डेमॉन या ओएस को क्रैश करना होगा।

एओएफ सेटिंग एक एपेंड केवल फ़ाइल का उपयोग करती है जो सर्वर को प्राप्त आदेशों को लॉग करता है, और सहेजी गई फ़ाइल से, डीबी को ठंडे स्टार्ट पर स्क्रैच से पुन: प्रयास करता है। डिफ़ॉल्ट डिस्क-सिंक नीति प्रत्येक सेकेंड (आईआईआरसी) में एक बार फ्लश करना है, लेकिन प्रत्येक कमांड पर लॉक और लिखने के लिए सेट किया जा सकता है।

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

मैं डिफ़ॉल्ट आरडीबी सेटिंग स्वयं का उपयोग कर रहा हूं और स्नैपशॉट को रिमोट एफ़टीपी में सहेज रहा हूं। मैंने एक विफलता नहीं देखी है जिसके कारण डेटा हानि हुई है। तीव्र हार्डवेयर विफलता या पावर आउटेज सबसे अधिक संभावना है, लेकिन मुझे एक वीपीएस पर होस्ट किया गया है। ऐसा होने का स्लिम मौका :)

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