Redis अभी टेक कम्युनिटी में गर्म है। यह Antirez की एक छोटी व्यक्तिगत परियोजना से उद्योग मानक इन-मेमोरी डेटा स्टोरेज बनने तक एक लंबा सफर तय कर चुका है। इसके साथ Redis का सही तरीके से उपयोग करने के लिए सर्वोत्तम प्रथाओं का एक सेट आता है जिस पर अधिकांश लोग सहमत हो सकते हैं। नीचे हम Redis का सही तरीके से उपयोग करने पर 10 त्वरित सुझावों का पता लगाएंगे।
1. KEYS * का उपयोग करना बंद करें
ठीक है, तो शायद आप पर चिल्लाना इस लेख को शुरू करने का एक शानदार तरीका नहीं है। लेकिन यह काफी संभवतः सबसे महत्वपूर्ण बिंदु है। अक्सर मैं एक Redis इंस्टेंस को देखता हूं, एक त्वरित commandstats खींचता हूं, और एक चमकता हुआ KEYS मुझे वापस घूरता हुआ दिखाई देता है। सभी निष्पक्षता में, एक प्रोग्रामेटिक दृष्टिकोण से यह एक छद्मकोड रखने के लिए समझ में आएगा जो ऐसा कुछ करता है:
for key in 'keys *': doAllTheThings()लेकिन जब आपके पास, कहें, 13 मिलियन कुंजियाँ हैं, तो चीजें धीमी होने वाली हैं। चूंकि KEYS O(n) है जहां n वापस की गई कुंजियों की संख्या है, आपकी जटिलता dbsize से बंधी है। साथ ही, इस पूरे ऑपरेशन के दौरान, आपके इंस्टेंस के खिलाफ कुछ और नहीं चलाया जा सकता।
विकल्प के रूप में, SCAN देखें जो आपको अपने डेटाबेस के माध्यम से इंक्रीमेंट्स में स्कैन करने की अनुमति देता है। यह एक इटरेटर पर काम करता है ताकि आप फिट देखते ही रुक और जा सकें।
2. पता लगाएं कि Redis को क्या धीमा कर रहा है
चूंकि Redis के पास सबसे वर्बोज लॉग नहीं हैं, इसलिए अक्सर यह ट्रैक करना मुश्किल होता है कि वास्तव में आपके इंस्टेंस के अंदर क्या चल रहा है। सौभाग्य से Redis आपको commandstat यूटिलिटी प्रदान करता है जो आपको यह दिखाता है:
127.0.0.1:6379> INFO commandstats
# Commandstats
cmdstat_get:calls=78,usec=608,usec_per_call=7.79
cmdstat_setex:calls=5,usec=71,usec_per_call=14.20
cmdstat_keys:calls=2,usec=42,usec_per_call=21.00
cmdstat_info:calls=10,usec=1931,usec_per_call=193.10यह आपको सभी कमांड्स का ब्रेकडाउन देता है, वे कितनी बार चलाए गए हैं, निष्पादित करने में लगे माइक्रोसेकंड्स की संख्या (कुल और प्रति कॉल औसत)
इसे रीसेट करने के लिए बस CONFIG RESETSTAT चलाएं, और आपके पास एक बिल्कुल नई स्लेट है।
3. Redis-Benchmark को बेसलाइन के रूप में उपयोग करें, सुसमाचार सत्य नहीं
Redis के निर्माता सल्वाटोर ने इसे प्रतिभाशाली ढंग से कहा: "Redis को GET/SET करते हुए टेस्ट करना फेरारी को यह टेस्ट करने जैसा है कि बारिश होने पर यह मिरर को साफ करने में कितना अच्छा है।" बहुत बार लोग मुझसे आश्चर्य करते हैं कि उनके Redis-Benchmark परिणाम इष्टतम से कम क्यों हैं। लेकिन हमें कई अलग-अलग कारकों को ध्यान में रखना होगा, जैसे:
- हम किन क्लाइंट-साइड सीमाओं में भाग सकते थे?
- क्या वर्जनिंग में कोई अंतर था?
- क्या किए जा रहे टेस्ट प्रासंगिक हैं कि एप्लिकेशन क्या करेगा?
Redis-Benchmark यह सुनिश्चित करने के लिए एक शानदार बेसलाइन प्रदान करता है कि आपका redis-server असामान्य रूप से व्यवहार नहीं कर रहा है, लेकिन इसे कभी भी सच्चे "लोड टेस्ट" के रूप में नहीं लिया जाना चाहिए। लोड टेस्ट्स को इस बात को प्रतिबिंबित करने की आवश्यकता है कि आपका एप्लिकेशन कैसे व्यवहार करता है, और प्रोडक्शन के जितना संभव हो उतना करीब वातावरण से।
4. हैशेज आपके सबसे अच्छे दोस्त हैं
हैशेज को डिनर पर आमंत्रित करें। हैशेज को वाइन और डाइन करें। आप चकित होंगे कि वे कितनी खुशी ला सकते हैं यदि आप उन्हें बस मौका दें। मैंने इससे पहले बहुत सारी कुंजी संरचनाएं देखी हैं:
foo:first_name foo:last_name foo:addressउपरोक्त उदाहरण में, foo शायद एक उपयोगकर्ता के लिए उपयोगकर्ता नाम होगा, और उनमें से प्रत्येक एक अलग कुंजी है। यह त्रुटियों के लिए जगह जोड़ता है, और गुना में अनावश्यक कुंजियाँ जोड़ता है। इसके बजाय, एक हैश पर विचार करें। अचानक आपके पास केवल एक कुंजी है:
127.0.0.1:6379> HSET foo first_name "Joe"
(integer) 1
127.0.0.1:6379> HSET foo last_name "Engel"
(integer) 1
127.0.0.1:6379> HSET foo address "1 Fanatical Pl"
(integer) 1
127.0.0.1:6379> HGETALL foo
1) "first_name"
2) "Joe"
3) "last_name"
4) "Engel"
5) "address"
6) "1 Fanatical Pl"
127.0.0.1:6379> HGET foo first_name
"Joe"5. वह TTL सेट करें!
जब भी संभव हो, एक्सपायरिंग कुंजियों का लाभ उठाएं। एक आदर्श उदाहरण अस्थायी प्रमाणीकरण कुंजियों जैसी चीज़ को स्टोर करना है। जब आप ऑथ कुंजी प्राप्त करते हैं—आइए OAUTH को एक उदाहरण के रूप में उपयोग करें—आपको अक्सर एक समाप्ति समय दिया जाता है। जब आप कुंजी सेट करते हैं, तो इसे उसी समाप्ति के साथ सेट करें, और Redis आपके लिए साफ कर देगा! उन सभी कुंजियों के माध्यम से पुनरावृत्ति करने के लिए KEYS * की कोई और आवश्यकता नहीं, है ना?
6. उचित निष्कासन नीति चुनना
जब हम कुंजियों को साफ करने के विषय पर हैं, तो आइए निष्कासन पर स्पर्श करें। जब आपका Redis इंस्टेंस भर जाता है, तो Redis कुंजियों को बाहर निकालने का प्रयास करेगा। आपके उपयोग के मामले के आधार पर, मैं volatile-lru की अत्यधिक अनुशंसा करता हूं—यह मानते हुए कि आपके पास एक्सपायरिंग कुंजियाँ हैं। यदि आप कैश जैसी कोई चीज़ चला रहे हैं और आपके पास एक्सपायरी सेट नहीं है, तो आप allkeys-lru पर विचार कर सकते हैं। मैं यहां उपलब्ध विकल्पों की जांच करने की सलाह दूंगा।
7. यदि आपका डेटा महत्वपूर्ण है, Try/Except
यदि आपके Redis इंस्टेंस में डेटा पहुंचना बिल्कुल महत्वपूर्ण है, तो मैं try/except डालने की भारी अनुशंसा करता हूं। चूंकि लगभग सभी Redis क्लाइंट्स "फायर-एंड-फॉरगेट" के लिए कॉन्फ़िगर किए गए हैं, इसलिए जब कोई कुंजी वास्तव में डेटाबेस तक नहीं पहुंचती है, तो इसके लिए हमेशा विचार करना चाहिए। इस मामले में आपके Redis कॉल में जोड़ी गई जटिलता अगले से कुछ भी नहीं है, और आप अपने महत्वपूर्ण डेटा को सुनिश्चित कर सकते हैं जहां यह होना चाहिए।
8. एक इंस्टेंस को फ्लड न करें
जब भी संभव हो, वर्कलोड को कई Redis इंस्टेंस में विभाजित करें। संस्करण 3.0.0 के अनुसार, Redis क्लस्टर अब उपलब्ध है। Redis क्लस्टर आपको कुंजी रेंज के आधार पर दी गई मास्टर्स/स्लेव्स के सेट्स के बीच कुंजियों को अलग करने की अनुमति देता है। क्लस्टर के पीछे के जादू का पूर्ण ब्रेकडाउन यहां पाया जा सकता है। और यदि आप एक ट्यूटोरियल ढूंढ रहे हैं, तो आगे न देखें। यदि क्लस्टरिंग एक विकल्प नहीं है, तो नेमस्पेसिंग पर विचार करें और अपनी कुंजियों को कई इंस्टेंस में वितरित करें। अपने डेटा को पार्टीशन करने पर एक अद्भुत लेख redis.io वेबसाइट पर यहां पाया जा सकता है।
9. अधिक कोर = अधिक बेहतर, है ना?!
गलत। Redis एक सिंगल थ्रेडेड प्रक्रिया है और अधिकतम दो कोर का उपभोग करेगी यदि आपके पास पर्सिस्टेंस सक्षम है। जब तक आप एक ही होस्ट पर कई इंस्टेंस चलाने की योजना नहीं बनाते—उम्मीद है कि केवल उस मामले में देव टेस्टिंग के लिए!—आपको Redis इंस्टेंस के लिए दो कोर से अधिक की आवश्यकता नहीं होनी चाहिए।
10. सभी चीजों को HA बनाएं!
Redis Sentinel अब बहुत अच्छी तरह से टेस्टेड है, और कई उपयोगकर्ता इसे प्रोडक्शन में चला रहे हैं (ObjectRocket शामिल!)। यदि आप अपने एप्लिकेशन के लिए Redis पर बहुत अधिक भरोसा कर रहे हैं, तो आपको ऑनलाइन रहने के लिए HA (उच्च उपलब्धता) समाधान पर विचार करने की आवश्यकता है। बेशक, यदि आप स्वयं उस सब का प्रबंधन नहीं करना चाहते हैं, तो ObjectRocket आपके उपभोग के लिए 24x7 सपोर्ट के साथ अपना HA प्लेटफॉर्म प्रदान करता है, इसे आज़माएं।
