Redis क्यों? इतिहास, उपयोग के मामले और बेहतरीन विकल्प

“बस इसे Redis में कैश कर दो” — आपने यह किसी कोड रिव्यू में, सिस्टम डिज़ाइन इंटरव्यू में, या Stack Overflow कमेंट में ज़रूर सुना होगा। यह अब लगभग एक रिफ्लेक्स बन चुका है। लेकिन Redis ही क्यों? एक अच्छे इंडेक्स वाले रेगुलर डेटाबेस से क्यों नहीं, या किसी और इन-मेमोरी स्टोर से? मैंने इसके इतिहास, आर्किटेक्चर, और विकल्पों के मौजूदा परिदृश्य में गहराई से देखा — और यह कहानी मीम से कहीं ज़्यादा दिलचस्प है।

Redis वास्तव में क्या है

पहले एक बात साफ़ कर लेते हैं। Redis सिर्फ एक कैश नहीं है। यही वो भ्रांति है जो लोगों को उलझा देती है। Redis का मतलब है REmote DIctionary Server [1], और यह एक इन-मेमोरी डेटा स्ट्रक्चर स्टोर है — यानी यह डेटा को डिस्क की बजाय RAM में रखता है। यही एक फ़ैसला इसकी तेज़ी का अधिकांश हिस्सा समझाता है।

लेकिन इसे “की-वैल्यू स्टोर” कहना इसे कम आंकना है। Redis नेटिव रूप से डेटा स्ट्रक्चर के एक समृद्ध सेट को समझता है [1]:

• Strings — बेसिक टाइप; काउंटर और बाइनरी ब्लॉब के रूप में भी उपयोग किया जाता है
• Lists — क्रमबद्ध, डुप्लीकेट सपोर्ट करते हैं; क्यूज़ और एक्टिविटी फ़ीड के लिए बेहतरीन
• Sets — यूनीक वैल्यू O(1) मेम्बरशिप चेक के साथ
• Sorted Sets — ऑर्डरिंग के लिए न्यूमेरिक स्कोर वाले यूनीक मेम्बर; रियल-टाइम लीडरबोर्ड के लिए उपयुक्त
• Hashes — एक की के भीतर मिनी हैशमैप; बिना सब कुछ सीरियलाइज़ किए ऑब्जेक्ट स्टोर करें
• Streams — प्रोसेसिंग के लिए अपेंड-ओनली इवेंट लॉग
• Bitmaps / HyperLogLogs — स्पेस-एफिशिएंट काउंटिंग और प्रोबेबिलिस्टिक डेटा
• Geospatial indexes — कोऑर्डिनेट्स का उपयोग करके नज़दीकी लोकेशन खोजें

यही वजह है कि Redis अधिकांश आधुनिक उपयोग के मामलों में Memcached से आगे रहता है। Memcached बहुत सरल एक्सेस पैटर्न के साथ रॉ स्ट्रिंग कैशिंग के लिए तेज़ है — और बस यही एकमात्र काम वह करता है। जैसे ही आपको एक सॉर्टेड लीडरबोर्ड, पब/सब चैनल, या रेट-लिमिटिंग काउंटर की ज़रूरत होती है, Memcached आपकी मदद नहीं कर सकता।

मूल कहानी

यह वह हिस्सा है जिसके सच में अच्छा होने की मुझे उम्मीद नहीं थी।

Salvatore Sanfilippo — जो ऑनलाइन antirez के नाम से जाने जाते हैं — एक सिसिलियन प्रोग्रामर हैं जो 2007 में LLOOGG नाम का एक रियल-टाइम वेब एनालिटिक्स टूल बना रहे थे [2]। आइडिया चतुर था: वेबसाइट मालिकों को लाइव अपने विज़िटर्स का व्यवहार दिखाना, जिसमें वे कौन से पेज देखते हैं और किस क्रम में। संदर्भ के लिए, Google Analytics ने रियल-टाइम ट्रैकिंग 2011 तक शिप नहीं की, इसलिए antirez सच में अपने समय से आगे थे [3]।

समस्या? MySQL इसे संभाल नहीं सका। हर पेज व्यू को इतनी तेज़ी से लिखा और क्वेरी किया जाना था कि लाइव डेटा दिखाया जा सके। असली ट्रैफिक में, MySQL का डिस्क I/O बॉटलनेक बन गया। Sanfilippo की अंतर्दृष्टि थी — डिस्क से लड़ना बंद करो। उन्होंने Tcl में LMDB (LLOOGG Memory Database) नाम का एक त्वरित प्रोटोटाइप लिखा, सिर्फ परिकल्पना परखने के लिए [2]। यह काम किया। तो उन्होंने इसे C में ठीक से फिर से लिखा।

वही प्रोटोटाइप Redis बना। पहला पब्लिक रिलीज़ 10 अप्रैल, 2009 को गया [1]। उनके दोस्त David Welton ने इसे Hacker News पर पोस्ट किया। शुरुआती प्रतिक्रिया ज़्यादातर चुप्पी रही — सिवाय Ezra Zygmuntowicz के, जो एक प्रसिद्ध Ruby on Rails डेवलपर थे, जिन्होंने तुरंत समझ लिया कि antirez ने क्या बनाया है और इसे फैलाने में मदद की [2]।

वहाँ से यह तेज़ी से आगे बढ़ा। यहाँ मोटा टाइमलाइन है:

1. 2010 — VMware ने Sanfilippo को Redis पर फुल-टाइम काम करने के लिए हायर किया [1]
2. 2012 — GitHub ने इसे एक्टिविटी फ़ीड के लिए अपनाया; Twitter ने ट्रेंडिंग टॉपिक्स और टाइमलाइन फैनआउट के लिए इस्तेमाल किया [3]
3. 2013 — VMware के पुनर्गठन पर Pivotal ने स्पॉन्सरशिप संभाली
4. 2015 — Redis Labs (अब Redis Inc.) मुख्य कमर्शियल स्टीवर्ड बने
5. 2020 — antirez ने सक्रिय विकास से पीछे कदम रखा

और LLOOGG, वह एनालिटिक्स टूल जिसने सब कुछ शुरू किया? यह 2014 में बंद होने तक Redis पर चला — दो अरब से ज़्यादा पेज व्यू संभालते हुए, 350–400 कमांड प्रति सेकंड पर, एक वर्चुअल मशीन पर जिसकी लागत $150 प्रति माह थी [2]। एक साइड प्रोजेक्ट जो एक डेवलपर की MySQL परफॉर्मेंस समस्या ठीक करने के लिए बनाया गया था, वह अब ग्रह पर लगभग हर गंभीर टेक स्टैक के अंदर चलता है।

यह इतना तेज़ क्यों है

तीन आर्किटेक्चरल फ़ैसले Redis को वह बनाते हैं जो वह है।

सब कुछ RAM में रहता है

यह एक बार कहने पर स्पष्ट हो जाता है, लेकिन स्पष्ट रूप से कहना ज़रूरी है। RAM तक पहुँचना एक स्पिनिंग डिस्क से लगभग 100,000 गुना तेज़ और रैंडम रीड के लिए SSD से लगभग 10 गुना तेज़ है [4]। डिस्क-आधारित डेटाबेस बफर पूल, पेज कैश और I/O क्यूज़ मैनेज करते हैं। Redis ये सब छोड़ देता है। आप एक की मांगते हैं, वह पहले से मेमोरी में है, काम हो गया।

सिंगल-थ्रेडेड इवेंट लूप

यह लोगों को चौंकाता है। क्या सिंगल-थ्रेडेड का मतलब धीमा नहीं है? Redis के लिए नहीं — क्योंकि Redis CPU-बाउंड नहीं, I/O-बाउंड है। सिंगल-थ्रेडेड मॉडल लॉक कंटेंशन को पूरी तरह खत्म कर देता है: कोई म्यूटेक्स नहीं, कोई रेस कंडीशन नहीं, थ्रेड्स के बीच कोई सिंक्रोनाइज़ेशन ओवरहेड नहीं। कमांड अटॉमिकली और सीक्वेंशियली एक्जीक्यूट होते हैं [4]। इवेंट लूप नॉन-ब्लॉकिंग I/O (आंतरिक रूप से epoll का उपयोग करते हुए) के ज़रिए हज़ारों समवर्ती कनेक्शन हैंडल करता है, इसलिए सिंगल थ्रेड कभी किसी धीमे क्लाइंट के लिए ब्लॉक नहीं होता [11]। Redis 6.0 से, वैकल्पिक थ्रेडेड I/O नेटवर्क रीड और राइट को मल्टीपल थ्रेड्स पर ऑफलोड कर सकता है — लेकिन कमांड एक्जीक्यूशन सिंगल-थ्रेडेड ही रहता है। यह दिखने से कहीं ज़्यादा साफ़ डिज़ाइन है।

एफिशिएंट प्रोटोकॉल और डेटा स्ट्रक्चर

RESP (Redis Serialization Protocol) मिनिमल और तेज़ी से पार्स होने वाला है। कोई SQL प्लानर नहीं, कोई JOIN रिज़ॉल्यूशन नहीं, कोई ऑप्टिमाइज़र ओवरहेड नहीं। और डेटा स्ट्रक्चर जेनेरिक इम्प्लीमेंटेशन नहीं हैं — सॉर्टेड सेट्स, उदाहरण के लिए, एक साथ स्किप लिस्ट + हैश टेबल कॉम्बिनेशन का उपयोग करके इम्प्लीमेंट किए जाते हैं, O(1) स्कोर लुकअप के साथ O(log N) इंसर्ट देते हैं [5]।

परिणाम: एक स्टैंडर्ड Redis इंस्टेंस GET/SET ऑपरेशन के लिए लगभग 0.167 मिलीसेकंड की मीडियन लेटेंसी के साथ प्रति सेकंड 100,000 से अधिक ऑपरेशन हैंडल करता है [4]। पाइपलाइनिंग के साथ — एक नेटवर्क राउंड ट्रिप में मल्टीपल कमांड बैच करके — आप उसी हार्डवेयर पर दस लाख ops/sec से आगे जा सकते हैं।

लोग वास्तव में Redis का उपयोग किस लिए करते हैं

कैशिंग (स्पष्ट वाला)

आपके पास एक Postgres क्वेरी है जो हर रिक्वेस्ट पर 180ms लेती है। आप Redis में 60-सेकंड TTL के साथ रिज़ल्ट कैश करते हैं। अब 95% रीड RAM से होती हैं और 1ms से कम में वापस आती हैं। यह प्रमुख उपयोग का मामला है — और वह कारण है कि Redis प्रभावी रूप से किसी भी कंपनी में डिफ़ॉल्ट इन्फ्रास्ट्रक्चर है जिसके पास असली ट्रैफिक है [11]।

GitHub ने शुरुआत में इसका उपयोग अपने एक्टिविटी फ़ीड के लिए किया। हर पेज लोड पर डेटाबेस जॉइन से यूज़र की टाइमलाइन रिकंस्ट्रक्ट करने के बजाय, उन्होंने Redis में प्री-कंप्यूटेड टाइमलाइन स्टोर की और राइट इवेंट पर उन्हें अपडेट किया [3]।

सेशन मैनेजमेंट

सोचें एक सेशन में क्या होता है: यूज़र ID, ऑथ टोकन, शायद एक कार्ट ID। यह छोटा है, लगभग हर ऑथेंटिकेटेड रिक्वेस्ट पर रीड होता है, और तेज़ होना ज़रूरी है। Redis एकदम सटीक है — आप TTL के साथ एक की सेट करते हैं और जब सेशन खत्म होना चाहिए तो यह ऑटो-एक्सपायर हो जाता है। स्टेल सेशन क्लीन करने के लिए कोई क्रॉन जॉब नहीं, आपके मुख्य डेटाबेस में कोई गार्बेज नहीं। Instagram ने अपने स्केल पर Redis में इन जोड़ियों के सैकड़ों करोड़ स्टोर किए [3]।

रेट लिमिटिंग

“इस IP ने पिछले 60 सेकंड में कितनी API कॉल की हैं?” Redis एक सिंगल अटॉमिक INCR + EXPIRE से इसका जवाब देता है। कोई ट्रांजैक्शन नहीं, कोई लॉकिंग नहीं, कोई रेस कंडीशन नहीं। Twitter ने अपने पूरे प्लेटफॉर्म पर API रेट लिमिट्स लागू करने के लिए इस पैटर्न का उपयोग किया [3]। यह शायद लीकी बकेट पैटर्न का सबसे एलीगेंट इम्प्लीमेंटेशन है जो मैंने देखा है — और यह कोड की तीन लाइनें हैं।

रियल-टाइम लीडरबोर्ड

यहीं पर सॉर्टेड सेट्स अपनी उपयोगिता साबित करते हैं। ZADD leaderboard 9500 "player:88" एक स्कोर जोड़ता है। ZRANGE leaderboard 0 9 WITHSCORES REV तुरंत टॉप 10 रिटर्न करता है, बिना री-सॉर्टिंग के, O(log N) इंसर्ट [5]। इस तरह मोबाइल गेम लाखों समवर्ती स्कोर अपडेट बिना रिलेशनल डेटाबेस को दबाए हैंडल करते हैं। यह बस काम करता है।

Pub/Sub मेसेजिंग

Redis में एक बिल्ट-इन पब्लिश/सब्सक्राइब मेसेजिंग सिस्टम है — पब्लिशर नेम्ड चैनल पर भेजते हैं, सब्सक्राइबर रियल टाइम में रिसीव करते हैं [9]। यह Kafka को ड्यूरेबल, रिप्लेड इवेंट स्ट्रीम के लिए रिप्लेस करने के लिए नहीं है (Redis Pub/Sub मेसेज पर्सिस्ट नहीं करता), लेकिन लाइटवेट रियल-टाइम नोटिफिकेशन के लिए — “नया चैट मेसेज”, “प्राइस अपडेट”, “फ़ॉलो इवेंट” — यह खूबसूरती से काम करता है और कोई इन्फ्रास्ट्रक्चर ओवरहेड नहीं जोड़ता।

वेक्टर सर्च और AI वर्कलोड

हाल ही में, Redis ने AI उपयोग के मामलों में गहरी रुचि ली है। Redis रेगुलर डेटा के साथ वेक्टर एम्बेडिंग स्टोर कर सकता है, जिससे यह LLM रिस्पॉन्स के सिमेंटिक कैशिंग और रिट्रीवल-ऑगमेंटेड जेनरेशन (RAG) पाइपलाइन के लिए उपयोगी है [4]। यदि आप LangChain, LangGraph, या mem0 के साथ कुछ बना रहे हैं, तो आपने शायद पहले से ही Redis को मेमोरी बैकएंड के रूप में देखा होगा। Redis 8.0 में नया Vector Sets टाइप antirez द्वारा खुद इस उपयोग के मामले के लिए लिखा गया था [13]।

लाइसेंस ड्रामा (यह वास्तव में मायने रखता है)

यह हिस्सा प्रासंगिक है यदि आप आज एक आर्किटेक्चर निर्णय ले रहे हैं। ईमानदारी से कहें, यह उलझ गया।

मार्च 2024 में, Redis Inc. ने प्रोजेक्ट का लाइसेंस परमिसिव BSD 3-Clause से ड्यूअल RSALv2 / SSPLv1 मॉडल में बदल दिया [6]। न तो OSI-अनुमोदित ओपन सोर्स है। SSPLv1 मूल रूप से MongoDB द्वारा क्लाउड प्रोवाइडर्स को टार्गेट करने के लिए बनाया गया था — यह मूलतः कहता है: यदि आप इसे एक मैनेज्ड सर्विस के रूप में ऑफर करते हैं, तो आपको अपना पूरा प्लेटफॉर्म ओपन-सोर्स भी करना होगा।

टार्गेट स्पष्ट था। AWS ElastiCache Redis से सैकड़ों करोड़ डॉलर कमा रहा था जबकि Redis Inc. मुफ़्त से पेड यूज़र्स में ~1% कन्वर्ज़न रेट से जूझ रहा था [6]। निराशा पूरी तरह समझ में आती है। एक्जीक्यूशन एक तबाही था।

कम्युनिटी की प्रतिक्रिया तत्काल थी। Linux डिस्ट्रीब्यूशन (openSUSE, Fedora) अपने रेपो से Redis हटाने लगे। हफ्तों के भीतर, पूर्व Redis मेंटेनर्स ने आखिरी BSD-लाइसेंस्ड वर्ज़न फोर्क किया और अप्रैल 2024 में Linux Foundation के तहत Valkey लॉन्च किया, AWS, Google Cloud, Oracle, Alibaba, और Ericsson के समर्थन से [7]।

फिर antirez खुद — जो 2020 में प्रोजेक्ट से पीछे हट गए थे — नवंबर 2024 में Redis Inc. में वापस आए। उन्होंने कोर्स करेक्शन के लिए ज़ोरदार दबाव डाला। 1 मई, 2025 को Redis 8.0 ट्राई-लाइसेंस: RSALv2, SSPLv1, या AGPLv3 के तहत लॉन्च हुआ [13]। AGPLv3 OSI-अनुमोदित ओपन सोर्स है — कम्युनिटी की ओर वापस एक वास्तविक कदम। Antirez ने इसके बारे में खुलकर लिखा: “मुझे खुशी है कि Redis फिर से ओपन सोर्स सॉफ्टवेयर है।”

क्या रिवर्सल ने नुकसान ठीक किया? ज़्यादा नहीं। Valkey तब तक क्रिटिकल मास हासिल कर चुका था [14]।

विकल्प

Valkey

हालिया ओपन-सोर्स इतिहास में सबसे महत्वपूर्ण फोर्क। Valkey Linux Foundation के तहत Redis 7.2.4 है — पूरी तरह प्रोटोकॉल-कम्पैटिबल, लगभग हर उपयोग के मामले के लिए ड्रॉप-इन रिप्लेसमेंट [7]। AWS ने ElastiCache को इसमें माइग्रेट किया। Google Cloud Memorystore इसे सपोर्ट करता है। Aiven ने मई और अगस्त 2024 के बीच 15,000 सर्वर माइग्रेट किए।

Valkey 8.1 कथित तौर पर Redis OSS की तुलना में ~8% अधिक ops/sec पर चलता है, P99 लेटेंसी 22% कम करता है, और 20% कम मेमोरी उपयोग करता है [7]। अधिकांश टीमों के लिए, यह सबसे सुरक्षित माइग्रेशन पथ है — पैकेज नाम बदलें, इमेज स्वैप करें, काम हो गया।

Dragonfly

C++ में ग्राउंड-अप रिराइट, Redis फोर्क नहीं। Dragonfly आधुनिक कंकरेंसी प्रिमिटिव — फाइबर, SIMD, शेयर्ड-नथिंग आर्किटेक्चर — का उपयोग सभी CPU कोर को एफिशिएंटली यूटिलाइज़ करने के लिए करता है [8]। दावा किए गए थ्रूपुट उसी हार्डवेयर पर Redis से 25 गुना बेहतर हैं, प्रति डेटासेट मेमोरी फुटप्रिंट भी कम।

कैवियट: यह ~95–98% Redis-कम्पैटिबल है। एडमिनिस्ट्रेटिव कमांड में एज-केस गैप हैं [8]। अत्यधिक थ्रूपुट आवश्यकताओं वाले नए प्रोजेक्ट के लिए, एक बेंचमार्क रन के लायक है। मौजूदा सेटअप माइग्रेट करने के लिए, कमिट करने से पहले अपने विशिष्ट कमांड उपयोग का परीक्षण करें।

KeyDB

मल्टी-थ्रेडेड Redis। वही प्रोटोकॉल, वही कमांड, लेकिन यह आपके सभी कोर पर चलता है। Snap द्वारा अधिग्रहित, जिसने इसमें उचित इंजीनियरिंग संसाधन लाए [8]। FLASH फीचर (SSD पर टियर्ड स्टोरेज) उन डेटासेट के लिए सच में दिलचस्प है जो पूरी तरह RAM में फिट नहीं होते। यदि आप परिचित Redis सेमेंटिक्स पर मल्टी-थ्रेडिंग चाहते हैं, KeyDB एक सिद्ध विकल्प है।

Memcached

बुज़ुर्ग राजनेता। Memcached Redis से पहले का है और न्यूनतम ऑपरेशनल ओवरहेड के साथ प्योर स्ट्रिंग कैशिंग के लिए सच में तेज़ है [10]। कोई पर्सिस्टेंस नहीं, कोई सॉर्टेड सेट नहीं, कोई Lua स्क्रिप्टिंग नहीं, कोई pub/sub नहीं — बस तेज़ की-वैल्यू स्टोरेज। यदि आपको बस “इस डेटाबेस रिज़ल्ट को 60 सेकंड के लिए कैश करना है” और कुछ नहीं, तो Memcached की सादगी एक फीचर है। लेकिन बेसिक स्ट्रिंग कैशिंग से परे किसी भी उपयोग के मामले के लिए, Redis (या Valkey) समान लेटेंसी पर आपको काफी ज़्यादा देता है।

आपको कौन सा चुनना चाहिए?

एक ही जवाब नहीं, लेकिन कुछ ईमानदार शॉर्टकट:

• पहले से Redis पर हैं, काम कर रहा है — AGPLv3 के तहत Redis 8.0 में अपग्रेड करना ठीक है। AGPLv3 आपको तभी प्रभावित करता है जब आप Redis को एक मैनेज्ड सर्विस में रैप करके बेच रहे हों।
• नया शुरू कर रहे हैं, AWS या GCP — ElastiCache या Memorystore के ज़रिए Valkey उपयोग करें। वही प्रोटोकॉल, साफ़ लाइसेंसिंग, AWS पर 20% सस्ता [7]।
• अत्यधिक थ्रूपुट आवश्यकताएं और नया प्रोजेक्ट — Dragonfly को गंभीरता से बेंचमार्क करें।
• केवल सिंपल कैशिंग — Memcached गलत जवाब नहीं है यदि आपको सच में एक्स्ट्रा की ज़रूरत नहीं है।
• Redis प्रोटोकॉल पर मल्टी-थ्रेडिंग चाहिए — KeyDB।

इस सब का अजीब फुटनोट: LLOOGG — वह एनालिटिक्स टूल जिसने सब कुछ शुरू किया — एक दशक से अधिक पहले बंद हो गया। वह साइड प्रोजेक्ट जो antirez ने एक डेवलपर की MySQL परफॉर्मेंस समस्या ठीक करने के लिए बनाया था, अब ग्रह पर लगभग हर गंभीर टेक स्टैक के अंदर चलता है। वे 2020 में हटे, 2024 में वापस आए, देखा कि एक फोर्क बारह महीनों के भीतर प्रमुख क्लाउड प्रोवाइडर पर डिफ़ॉल्ट बन गया, और फिर Redis को ओपन सोर्स की ओर वापस धकेलने में मदद की।

आप सच में इस आर्क की योजना नहीं बना सकते।

समाप्त

स्रोत

1. Redis - Wikipedia
2. Story: Redis and its creator antirez — Brachiosoft Blog
3. History of Redis: From Side Project to Industry Standard — OneUptime
4. Complete Guide to Redis in 2026 — DragonflyDB
5. Redis sorted sets | Docs — redis.io
6. Redis tightens its license terms, pleasing no one — The Register
7. Valkey Turns One: How the Community Fork Left Redis in the Dust — Momento
8. 8 Best Redis Alternatives — DragonflyDB
9. Complete Guide to Redis Publish Subscribe — GeeksforGeeks
10. The Good and the Bad of Redis In-Memory Database — AltexSoft
11. What is Redis Explained? — IBM
12. Redis Switches to SSPLv1: Restrictive License Sparks Fork — InfoQ
13. Redis is open source again — antirez.com
14. Redis Returns to Open Source under AGPL License: Is It Too Late? — InfoQ
15. Redis is now available under the AGPLv3 open source license — redis.io
16. Understanding Redis Threading — DEV Community