PricingLoginStart free
Cloud & IT Cert Prep · पाठ

सत्र संग्रहण और लीडरबोर्ड पैटर्न

अपने अनुप्रयोग सर्वरों से HTTP सत्र स्थिति का भार हटाने के लिए ElastiCache का उपयोग कीजिए और Redis क्रमबद्ध सेटों से रीयल-टाइम लीडरबोर्ड लागू कीजिए।

पाठ 4, कुल 4 में से13 चरण

सत्र संग्रहण और लीडरबोर्ड पैटर्न, CoddyKit पर Cloud & IT Cert Prep का एक निःशुल्क पाठ है। यह 4 में से 4वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह Cloud & IT Cert Prep सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Cloud & IT Cert Prep पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

Server-Side Sessions की समस्या

Traditional web applications session data को server की memory में store करते हैं। यह single server के साथ काम करता है, लेकिन horizontally scale करने पर टूट जाता है — यदि user की अगली request किसी अलग EC2 instance पर route हो जाए, तो उस instance को user के session की कोई जानकारी नहीं होती और user log out हो जाता है। Sticky sessions (load balancer में session affinity) इस समस्या को कुछ हद तक हल करते हैं, लेकिन load balancing की effectiveness घटा देते हैं। Scalable solution है session state को सभी instances के लिए accessible shared, low-latency store में ले जाना — और ElastiCache Redis ठीक यही प्रदान करता है।

Session Storage के लिए Redis

Sessions को Redis में store करने से आपको ये लाभ मिलते हैं: सभी application servers पर sub-millisecond session reads, automatic session expiry के लिए built-in TTL, race conditions रोकने के लिए atomic session updates और key delete करके session को तुरंत invalidate करने की क्षमता। Application session ID को cookie में store करता है; हर request पर session data प्राप्त करने के लिए वह Redis में session ID lookup करता है। सभी application servers एक ही Redis share करते हैं, इसलिए कोई भी server किसी भी user की request handle कर सकता है।

# Session storage with Redis (Python Flask example)
import redis, json, uuid
from datetime import timedelta

redis_client = redis.Redis(host='prod-redis-primary', port=6379)
SESSION_TTL = int(timedelta(hours=8).total_seconds())

def create_session(user_id):
    session_id = str(uuid.uuid4())
    session_data = {'user_id': user_id, 'logged_in': True}
    redis_client.setex(f'session:{session_id}', SESSION_TTL, json.dumps(session_data))
    return session_id

def get_session(session_id):
    data = redis_client.get(f'session:{session_id}')
    return json.loads(data) if data else None

Session TTL और Sliding Expiry

Fixed TTL का अर्थ है कि activity की परवाह किए बिना session creation के N seconds बाद expire हो जाता है। sliding TTL (हर access पर expiry बढ़ाना) user के लिए अधिक सुविधाजनक है — session last access के N seconds बाद expire होता है। Redis में sliding TTL लागू करने के लिए हर successful session read पर session key पर EXPIRE (या EXPIREAT) call करके expiry countdown reset करें। इससे active users अनपेक्षित रूप से log out नहीं होते, जबकि inactive sessions स्वतः expire होकर memory खाली करते हैं।

# Sliding TTL session implementation
def get_session_with_sliding_ttl(session_id, redis_client, ttl_seconds=1800):
    session_key = f'session:{session_id}'

    # Pipeline: GET + EXPIRE in one round trip
    pipe = redis_client.pipeline()
    pipe.get(session_key)
    pipe.expire(session_key, ttl_seconds)  # Reset TTL on access
    results = pipe.execute()

    data = results[0]
    if data:
        return json.loads(data)
    return None   # Session expired or not found

Redis में Shopping Cart

E-commerce shopping cart Redis के लिए स्वाभाविक रूप से उपयुक्त है। प्रत्येक cart को Redis Hash के रूप में store किया जाता है, जहाँ field product SKU और value quantity होती है। HINCRBY और HDEL जैसे Hash operations पूरे cart को retrieve और rewrite किए बिना atomic updates की सुविधा देते हैं। TTL के साथ मिलकर (abandoned carts को 24 घंटे बाद expire करने के लिए), Redis प्रत्येक add-to-cart event के लिए relational database के overhead के बिना तेज़, persistent cart store प्रदान करता है।

# Shopping cart operations using Redis Hash
cart_key = f'cart:{user_id}'

# Add item (or increase quantity)
# HINCRBY cart:user42 SKU-001 2
redis_client.hincrby(cart_key, 'SKU-001', 2)

# Remove item
# HDEL cart:user42 SKU-001
redis_client.hdel(cart_key, 'SKU-001')

# Get all items in cart
# HGETALL cart:user42
cart = redis_client.hgetall(cart_key)  # {b'SKU-001': b'2', b'SKU-002': b'1'}

# Set TTL for cart abandonment (24 hours)
redis_client.expire(cart_key, 86400)

लीडरबोर्ड आर्किटेक्चर

रीयल-टाइम लीडरबोर्ड Redis के क्लासिक उपयोगों में से एक है, जिसे क्रमबद्ध सेट (ZSET) सक्षम बनाते हैं। प्रत्येक खिलाड़ी की प्रविष्टि का एक स्कोर होता है; क्रमबद्ध सेट हर समय सदस्यों को बढ़ते हुए स्कोर के क्रम में रखता है। लीडरबोर्ड से जुड़ी पूछताछ (शीर्ष N खिलाड़ी, खिलाड़ी की रैंक, किसी स्कोर-सीमा में आने वाले खिलाड़ी) O(log n) या O(log n + m) होती है—लाखों खिलाड़ियों के लिए भी यह अत्यंत तेज़ है। Redis के क्रमबद्ध सेट जटिल डेटाबेस पूछताछ करने या हर पृष्ठ-दृश्य पर रैंक की दोबारा गणना करने की आवश्यकता के बिना गेमिंग, फिटनेस और सामाजिक रैंकिंग सुविधाओं की नींव प्रदान करते हैं।

# Real-time leaderboard with Redis Sorted Set

# Add or update a player's score
# ZADD game:weekly:leaderboard 15750 'player:alice'
redis_client.zadd('game:weekly:leaderboard', {'player:alice': 15750})

# Increment score (atomic)
# ZINCRBY game:weekly:leaderboard 500 'player:alice'
redis_client.zincrby('game:weekly:leaderboard', 500, 'player:alice')

# Get top 10 players (highest scores first)
# ZREVRANGE game:weekly:leaderboard 0 9 WITHSCORES
top_10 = redis_client.zrevrange('game:weekly:leaderboard', 0, 9, withscores=True)

खिलाड़ी की रैंक और आस-पास के खिलाड़ी

'शीर्ष 10 दिखाएँ' के अलावा लीडरबोर्ड की दो सामान्य सुविधाएँ हैं: किसी खिलाड़ी की रैंक दिखाना और किसी दिए गए खिलाड़ी के आस-पास के खिलाड़ियों को दिखाना। Redis के क्रमबद्ध सेट से दोनों काम आसानी से हो जाते हैं। ZREVRANK किसी खिलाड़ी की घटते हुए स्कोर के क्रम में 0-आधारित रैंक लौटाता है। किसी खिलाड़ी से ऊपर और नीचे के 5 खिलाड़ियों को दिखाने के लिए पहले उसकी रैंक प्राप्त करें, फिर रैंक-5 से रैंक+5 तक ZREVRANGE का उपयोग करें। इससे केवल Redis की दो कमांड में व्यक्तिगत लीडरबोर्ड दृश्य मिल जाता है—जटिल SQL विंडो फ़ंक्शन की आवश्यकता नहीं होती।

# Get Alice's rank (0-indexed, so add 1 for display)
# ZREVRANK game:weekly:leaderboard 'player:alice'
rank = redis_client.zrevrank('game:weekly:leaderboard', 'player:alice')
print(f'Alice is rank #{rank + 1}')

# Get 5 players above and below Alice
start = max(0, rank - 5)
end = rank + 5
nearby = redis_client.zrevrange(
    'game:weekly:leaderboard', start, end, withscores=True
)
print('Players near Alice:', nearby)

Redis के साथ अनुरोध-दर सीमित करना

अनुरोध-दर सीमित करना (किसी समय-खंड में कोई क्लाइंट कितने अनुरोध कर सकता है, इसे सीमित करना) Redis का एक और महत्वपूर्ण उपयोग है। स्लाइडिंग विंडो एल्गोरिदम एक क्रमबद्ध सेट का उपयोग करता है, जिसमें प्रत्येक सदस्य अनुरोध का टाइमस्टैम्प होता है। प्रत्येक अनुरोध पर: विंडो से पुराने सदस्यों को हटाएँ, बचे हुए सदस्यों की गिनती करें, गिनती सीमा से अधिक होने पर अनुरोध अस्वीकार करें और नया टाइमस्टैम्प जोड़ें। यह मिलीसेकंड स्तर की सटीकता के साथ अनुरोध-दर सीमित करता है—निश्चित-विंडो काउंटर से कहीं अधिक सटीक और डेटाबेस के अतिरिक्त भार के बिना।

# Sliding window rate limiter (100 requests per 60 seconds)
import time

def is_rate_limited(user_id, redis_client, limit=100, window_seconds=60):
    key = f'ratelimit:{user_id}'
    now = time.time()
    window_start = now - window_seconds

    pipe = redis_client.pipeline()
    pipe.zremrangebyscore(key, '-inf', window_start)  # Remove old
    pipe.zcard(key)                                    # Count current
    pipe.zadd(key, {str(now): now})                   # Add this request
    pipe.expire(key, window_seconds)
    results = pipe.execute()

    request_count = results[1]
    return request_count >= limit  # True = rate limited

Redis के साथ वितरित लॉकिंग

वितरित लॉक कई एप्लिकेशन सर्वरों में साझा संसाधन तक अनन्य पहुँच का समन्वय करते हैं। Redis की SET key value NX EX ttl कमांड परमाणु रूप से लॉक प्राप्त करती है—यह कुंजी को तभी सेट करती है जब वह मौजूद न हो (NX = Not eXists), और लॉक रखने वाला सर्वर क्रैश होने पर डेडलॉक रोकने के लिए TTL सेट करती है। संचालन पूरा होने पर लॉक रखने वाला सर्वर कुंजी हटा देता है। Redlock एल्गोरिदम (बहुमत के निर्णय के लिए कई Redis नोड का उपयोग करके) अधिक मज़बूत वितरित लॉक प्रदान करता है, हालांकि इससे जटिलता बढ़ती है। अधिकांश उपयोगों के लिए एकल Redis नोड का लॉक पर्याप्त होता है।

# Distributed lock with Redis SET NX EX
import uuid

def acquire_lock(redis_client, resource, ttl_seconds=30):
    lock_id = str(uuid.uuid4())  # Unique ID to identify this lock holder
    key = f'lock:{resource}'
    acquired = redis_client.set(key, lock_id, nx=True, ex=ttl_seconds)
    return lock_id if acquired else None

def release_lock(redis_client, resource, lock_id):
    key = f'lock:{resource}'
    # Only delete if we still own the lock (Lua script for atomicity)
    lua = 'if redis.call("get",KEYS[1])==ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end'
    redis_client.eval(lua, 1, key, lock_id)

सत्र संग्रहण: ElastiCache बनाम DynamoDB

ElastiCache Redis और DynamoDB दोनों सत्र डेटा संग्रहीत कर सकते हैं, लेकिन इनके लाभ-हानि अलग-अलग हैं। ElastiCache Redis: माइक्रोसेकंड विलंबता, मेमोरी में (स्थायित्व सक्षम न होने पर अस्थिर), सरल डेटा मॉडल, VPC आवश्यक। DynamoDB: एक-अंकीय मिलीसेकंड विलंबता (DAX Redis की बराबरी कर सकता है), बनाए रखने के लिए किसी क्लस्टर की आवश्यकता नहीं, पूरी तरह प्रबंधित, डिफ़ॉल्ट रूप से टिकाऊ, Global Tables के साथ विश्व स्तर पर सुलभ, ऑन-डिमांड क्षमता के साथ सर्वररहित। SAA-C03 परीक्षा के लिए: यदि प्रश्न माइक्रोसेकंड विलंबता या जटिल इन-मेमोरी संचालन पर ज़ोर देता है, तो Redis चुनें। यदि इसमें स्थायित्व, सर्वररहित या वैश्विक स्तर पर ज़ोर हो, तो DynamoDB पर विचार करें।

Redis के साथ भौगोलिक-स्थान अनुक्रमण

Redis में एक अंतर्निहित भौगोलिक डेटा प्रकार (GEO कमांड) है, जो अक्षांश/देशांतर निर्देशांक संग्रहीत करता है और निकटता-आधारित पूछताछ सक्षम करता है। GEOADD, GEODIST और GEORADIUS (अब Redis 6.2 में GEOSEARCH) का उपयोग करके आप किसी बिंदु की दी गई त्रिज्या के भीतर आने वाले सभी स्थान O(n + log n) समय में ढूँढ सकते हैं। उपयोग: आस-पास के ड्राइवर ढूँढना (राइड-शेयरिंग), 5 किमी के भीतर रेस्तराँ ढूँढना और दूरी के आधार पर खोज परिणामों को क्रमित करना। इससे अलग भौगोलिक डेटाबेस की आवश्यकता नहीं रहती और स्थान संबंधी पूछताछ इन-मेमोरी गति पर होती है।

# Store driver locations
# GEOADD drivers 13.361389 38.115556 'driver:001'
# GEOADD drivers 15.087269 37.502669 'driver:002'

# Find all drivers within 10 km of a point
# GEOSEARCH drivers FROMLONLAT 13.5 38.1 BYRADIUS 10 km ASC COUNT 5 WITHCOORD

# Result: sorted list of driver IDs within 10 km with coordinates

अद्वितीय आगंतुकों की गिनती के लिए HyperLogLog

HyperLogLog एक संभाव्य डेटा संरचना है, जो सेट में मौजूद अद्वितीय तत्वों की गिनती का अनुमान निश्चित मात्रा की मेमोरी (Redis में 12 KB) का उपयोग करके लगाती है, चाहे कितने भी अद्वितीय आइटम जोड़े जाएँ। इसकी मानक त्रुटि लगभग 0.81% होती है। तत्व जोड़ने के लिए PFADD और अनुमान प्राप्त करने के लिए PFCOUNT का उपयोग करें। जब सटीक गिनती आवश्यक न हो और मेमोरी दक्षता महत्वपूर्ण हो, तब यह दैनिक सक्रिय उपयोगकर्ताओं, अद्वितीय पृष्ठ-दृश्यों या अद्वितीय IP पतों की गिनती के लिए उपयोगी है। लाखों अद्वितीय उपयोगकर्ता IDs को Redis Set में संग्रहीत करने पर GBs मेमोरी लगेगी; HyperLogLog केवल 12 KB लेता है।

# Count unique daily visitors using HyperLogLog
date = '2024-01-15'
hll_key = f'unique_visitors:{date}'

# Track a visitor (PFADD is idempotent for the same user)
# PFADD unique_visitors:2024-01-15 'user:12345'
redis_client.pfadd(hll_key, 'user:12345')
redis_client.pfadd(hll_key, 'user:67890')
redis_client.pfadd(hll_key, 'user:12345')  # Duplicate — not counted again

# Get estimated unique visitor count
# PFCOUNT unique_visitors:2024-01-15
count = redis_client.pfcount(hll_key)
print(f'Unique visitors today (estimate): {count}')

त्वरित जाँच

इस पाठ से AWS Solutions Architect (SAA-C03) की अवधारणाओं के बारे में अपनी समझ जाँचें।

इंटरैक्टिव पाठ में इसका उत्तर दें

पाठ का पुनरावलोकन

इस पाठ में आपने सीखा: Redis सत्र संग्रहण सभी Instances को साझा सत्र स्थिति तक मिलीसेकंड से कम विलंबता में पहुँच देकर स्थिति-रहित क्षैतिज स्केलिंग सक्षम करता है, Redis क्रमबद्ध सेट O(log n) रैंक पूछताछ के साथ रीयल-टाइम लीडरबोर्ड चलाते हैं, और विशेषीकृत Redis डेटा प्रकार (अद्वितीय गिनती के लिए HyperLogLog, निकटता के लिए GEO, वितरित लॉक) सामान्य आर्किटेक्चरल समस्याओं को कुशलता से हल करते हैं। इससे ElastiCache के साथ कैशिंग पाठ्यक्रम पूरा होता है—अब हम उच्च उपलब्धता और दोष-सहिष्णु आर्किटेक्चर का अध्ययन करेंगे।

शुरुआत निःशुल्क

एआई शिक्षक के साथ Cloud & IT Cert Prep सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम
150
पाठ
600
निःशुल्क सीखना शुरू करेंपूरा पाठ्यक्रम देखें

अक्सर पूछे जाने वाले प्रश्न

क्या “सत्र संग्रहण और लीडरबोर्ड पैटर्न” पाठ निःशुल्क है?

हाँ—“सत्र संग्रहण और लीडरबोर्ड पैटर्न” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और Cloud & IT Cert Prep पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। Cloud & IT Cert Prep पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“सत्र संग्रहण और लीडरबोर्ड पैटर्न” में मैं क्या सीखूँगा?

अपने अनुप्रयोग सर्वरों से HTTP सत्र स्थिति का भार हटाने के लिए ElastiCache का उपयोग कीजिए और Redis क्रमबद्ध सेटों से रीयल-टाइम लीडरबोर्ड लागू कीजिए। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Cloud & IT Cert Prep का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या Cloud & IT Cert Prep शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Cloud & IT Cert Prep शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 4वाँ पाठ है।

“सत्र संग्रहण और लीडरबोर्ड पैटर्न” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस Cloud & IT Cert Prep पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर Cloud & IT Cert Prep पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

  1. Redis बनाम Memcached: सही इंजन चुनना
  2. ElastiCache Redis प्रतिकृति समूह और क्लस्टर मोड
  3. कैशिंग रणनीतियाँ: लेज़ी लोडिंग और राइट-थ्रू
  4. सत्र संग्रहण और लीडरबोर्ड पैटर्न
← Cloud & IT Cert Prep पर वापस जाएँ