Redis pattern: cache, counter, rate limit, queue, leaderboard

Redis backend কাজের একটি সুইস আর্মি নাইফ। বাস্তব সমস্যা মেটানো pattern এবং এড়ানোর ভুলগুলো দেখুন।

NewsReport•২৯ অক্টোবর, ২০২৬•২ মিনিটে পড়া

Redis কাজের data structure-সহ একটি in-memory data store। এই pattern-গুলো বেশিরভাগ বাস্তব ব্যবহার ঢাকে।

১. Cache (cache-aside)

value = redis.get(key)
if value is missing:
    value = database.query(...)
    redis.set(key, value, ex=300)   # ৫ মিনিটে মেয়াদ শেষ

সবসময় TTL দিন, আর মূল data বদলালে key মুছুন বা আপডেট করুন। একসাথে মেয়াদ শেষ এড়াতে TTL-এ random jitter দিন।

২. Counter

INCR page:views:42 atomic, তাই race condition ছাড়াই অনেক server নিরাপদে গুনতে পারে। Page view, like ও quota-তে ব্যবহার করুন। স্থায়ী রেকর্ড চাইলে নিয়মিত মোট সংখ্যা মূল database-এ লিখুন।

৩. Rate limiting

rate:user42:2026-10-25T10:15-এর মতো key-তে INCR করুন এবং window-এর দৈর্ঘ্যে EXPIRE দিন। সংখ্যা সীমা ছাড়ালে প্রত্যাখ্যান। মসৃণ সীমার জন্য sorted set (sliding window) বা Lua script-এ token bucket ব্যবহার করুন, যাতে যাচাই ও আপডেট atomic হয়।

৪. Leaderboard ও ranking

Sorted set member-দের score অনুযায়ী ক্রমে রাখে:

ZINCRBY leaderboard 10 "player:7"
ZREVRANGE leaderboard 0 9 WITHSCORES    # সেরা ১০
ZREVRANK leaderboard "player:7"          # একজন খেলোয়াড়ের rank

সব অপারেশন দ্রুত (লগারিদমিক)। "সবচেয়ে বেশি দেখা article"-এও একই ধারণা (এই সাইট তার view count sorted set-এ রাখে)।

৫. Session

Random session ID-র নিচে TTL সহ session data রাখুন। দ্রুত, server জুড়ে ভাগ করা, আর মেয়াদ শেষ বিল্ট-ইন।

৬. Queue ও stream

List (LPUSH / BRPOP) সহজ job queue বানায়। Stream consumer group, acknowledgement ও replay যোগ করে, আসল message queue-র কাছাকাছি। গুরুতর কাজে Kafka বা RabbitMQ ভাবুন, কিন্তু অনেক background job-এ Redis যথেষ্ট।

৭. Pub/sub

Channel-এ message publish করুন, subscriber সাথে সাথে পায়। Server-দের মধ্যে real-time notification-এ ভালো। Message সংরক্ষিত হয় না: offline subscriber মিস করে।

৮. Distributed lock

SET lock:job <id> NX PX 30000, owner যাচাই করা script দিয়ে ছাড়ুন। ডুপ্লিকেট কাজ এড়াতে ঠিক, কিন্তু সঠিকতার গ্যারান্টি নয় (distributed lock পর্ব দেখুন)।

ফাঁদ

Memory সীমিত। maxmemory ও eviction policy দিন, নয়তো Redis সব RAM নিতে পারে।
Persistence database-এর durability নয়। সেটিংস অনুযায়ী crash-এ সাম্প্রতিক write হারাতে পারে। সাবধানে কনফিগার না করলে সত্যের উৎস অন্য জায়গায় রাখুন।
বড় key ও ধীর command (যেমন KEYS *) সবাইকে আটকায়, কারণ command এক thread-এ চলে। SCAN ব্যবহার করুন।
Key-র নাম: app:object:id:field-এর মতো পরিষ্কার ছক ব্যবহার করুন।
নিরাপত্তা: Redis কখনো ইন্টারনেটে খুলবেন না। Private address-এ bind করুন, পাসওয়ার্ড দিন ও command সীমিত করুন।

মূল কথা: দ্রুত, অস্থায়ী বা উদ্ভূত data-র জন্য (cache, counter, সীমা, ranking, session, হালকা queue) Redis ব্যবহার করুন, সত্যের উৎস database-এ রাখুন, এবং memory ও access সুরক্ষিত রাখুন।

Backend ও Database সিরিজ, পর্ব ২ (performance ও operations): 6 নম্বর (মোট 6)। আগের লেখা: Downtime ছাড়া নিরাপদ database migration.