Redis — in-memory key-value আর cache

১ · Redis কী — মেমরিতে রাখা data structure server

পর্ব ৫৬-এ NoSQL-এর চার পরিবার দেখেছেন; তার সবচেয়ে সরল পরিবার key-value store. Redis সেই পরিবারের সবচেয়ে পরিচিত সদস্য, তবে সাধারণ key-value-এর চেয়ে বেশি: মান শুধু একটি লেখা নয়, একটি পূর্ণ data structure — তালিকা, সেট, ক্রম-সাজানো সেট। তাই Redis নিজেকে বলে “data structure server”. নামটি এসেছে REmote DIctionary Server থেকে। ইতালির প্রোগ্রামার Salvatore Sanfilippo (antirez) ২০০৯ সালে একটি real-time ওয়েব-বিশ্লেষণ প্রকল্পের প্রয়োজনে এটি লেখা শুরু করেন।

কেন এত দ্রুত

• সব ডেটা RAM-এ। পর্ব ৩৯-এ দেখেছেন, মেমরি থেকে পড়া মোটামুটি ১০০ ন্যানোসেকেন্ডের ঘরে, SSD থেকে কয়েক দশ মাইক্রোসেকেন্ড বা বেশি। Redis-এ ডিস্ক শুধু টিকিয়ে রাখার জন্য (অংশ ৮), পড়ার পথে নয়।
• সরল কাজ। SQL পার্স, optimizer, join, plan — কিছুই নেই। GET key মানে একটি hash table-এ খোঁজ, গড়ে O(1).
• একটি থ্রেডে কমান্ড চালানো। Redis-এর মূল থ্রেড একটি event loop: হাজারো client-এর connection একসাথে খোলা রাখে (Linux-এ epoll), আর যে client-এর কমান্ড তৈরি, সেটি চালায় — একবারে একটি। lock লাগে না, থ্রেডে থ্রেডে ঝগড়াও নেই।

এই single-threaded মডেল নিয়ে একটু সাবধানে বলা দরকার। Redis 6.0 (২০২০) থেকে ঐচ্ছিক I/O থ্রেড আছে, যা network থেকে পড়া আর উত্তর পাঠানোর কাজ ভাগ করে নেয়; পরের সংস্করণগুলোতে (Redis 8 আর Valkey 8 সহ) এই অংশে আরও উন্নতির কথা বলা হয়েছে। মেমরি ফেরত দেওয়া বা AOF-এর fsync-এর মতো কিছু কাজও পেছনের থ্রেডে চলে। কিন্তু ডেটা বদলানো কমান্ডগুলো এখনো ক্রমানুসারে, একটি একটি করে চলে — এটাই মূল কথা। এর দুটি ফল:

Redis এখানে চালানো যায় না, তাই এই পর্বের Redis কমান্ডগুলো redis-cli-এর ছবি — redis>-এর পরে কমান্ড, নিচের লাইনে সার্ভারের উত্তর। নিজের কম্পিউটারে চালাতে Docker-এ docker run -p 127.0.0.1:6379:6379 redis (শুধু নিজের কম্পিউটার থেকে ঢোকা যাবে; নিরাপত্তা অংশ ৯-এ), তারপর redis-cli. প্রথম পরিচয়:

redis> PING
PONG
redis> SET greeting "Assalamu Alaikum"
OK
redis> GET greeting
"Assalamu Alaikum"
redis> EXISTS greeting missing:key
(integer) 1
redis> DEL greeting
(integer) 1
redis> GET greeting
(nil)

(nil) মানে key নেই — SQL-এর NULL-এর মতো “অজানা” নয়, শুধু “এখানে কিছু রাখা হয়নি”. EXISTS দুটি key-এর মধ্যে কয়টি আছে তা গোনে।

২ · Key-এর নাম, TTL, string আর hash

Key-এর নামকরণ — app:entity:id

Redis-এ টেবিল বা schema নেই; সব key একটি বিশাল সমতল অভিধানে থাকে। শৃঙ্খলা আসে নামের রীতি থেকে: কোলন দিয়ে ভাগ করা অংশ, বড় থেকে ছোট — shop:product:101, app:session:a91f, rl:otp:01711000001. এই key naming convention তিনটি কাজ করে: এক নজরে বোঝা যায় key কার, ভিন্ন অ্যাপের key একে অপরকে মুছে ফেলে না, আর একটি অংশের সব key SCAN 0 MATCH shop:product:* দিয়ে খোঁজা যায়। নাম পাঠযোগ্য রাখুন, কিন্তু অপ্রয়োজনে লম্বা নয় — কোটি key-এ প্রতিটি বাড়তি বাইট মেমরি।

String — সবচেয়ে সরল মান

Redis-এর string আসলে বাইটের ক্রম: লেখা, সংখ্যা, JSON, এমনকি ছবি — একটি মান সর্বোচ্চ ৫১২ MB (বাস্তবে ছোট রাখুন)। সংখ্যার মতো দেখতে string-এ INCR atomic যোগ করে:

redis> SET shop:product:101:price 15000
OK
redis> INCR stats:views:2025-10-10
(integer) 1
redis> INCRBY stats:views:2025-10-10 9
(integer) 10
redis> SET otp:01711000001 482913 EX 120     # ১২০ সেকেন্ডের মেয়াদ
OK
redis> TTL otp:01711000001
(integer) 120
redis> SET otp:01711000001 771204 EX 120 NX  # NX: না থাকলেই লেখো
(nil)
redis> SET flash:sale:banner on PX 1500       # PX: মিলিসেকেন্ডে
OK

NX (Not eXists) লেখার আগে দেখে key আছে কি না — আছে, তাই (nil), পুরোনো OTP বদলায়নি। এই এক শব্দই পরে lock বানাবে (অংশ ৭)। উল্টো XX: থাকলেই লেখে।

TTL আর মেয়াদ শেষ হওয়া

TTL (time to live) হলো key-এর বাকি আয়ু। EXPIRE key 60 মেয়াদ বসায়, PERSIST সরায়, TTL বাকি সেকেন্ড বলে: -1 মানে key আছে কিন্তু মেয়াদ নেই, -2 মানে key-ই নেই। দুটি সূক্ষ্ম নিয়ম, যা ভুলের বড় উৎস:

• নতুন করে SET করলে মেয়াদ মুছে যায় (যদি না KEEPTTL বা নতুন EX দেন)। কিন্তু INCR, HSET, LPUSH-এর মতো মান-বদলানো কমান্ড মেয়াদ রেখে দেয়।
• মেয়াদ শেষ মানে সাথে সাথে মেমরি খালি নয়। Redis দুই পথে মোছে: কেউ পড়তে এলে তখন দেখে মুছে দেয় (passive), আর পেছনে নিয়মিত কিছু মেয়াদি key-এর নমুনা নিয়ে মেয়াদোত্তীর্ণগুলো মোছে (active). পাঠক কখনো মেয়াদোত্তীর্ণ মান পান না, তবে মেমরি একটু দেরিতে ফেরত আসে।

Hash — একটি বস্তুর কয়েকটি ঘর: user session

Hash একটি key-এর ভেতরে field → value-এর ছোট অভিধান — relational সারির মতো, তবে schema ছাড়া। ব্যবহারকারী লগইন করলে তাঁর session রাখার আদর্শ জায়গা:

redis> HSET app:session:a91f user_id 1 name "Rahim Uddin" cart_items 2
(integer) 3
redis> EXPIRE app:session:a91f 1800          # ৩০ মিনিট নিষ্ক্রিয় থাকলে লগআউট
(integer) 1
redis> HINCRBY app:session:a91f cart_items 1
(integer) 3
redis> HGET app:session:a91f name
"Rahim Uddin"
redis> HGETALL app:session:a91f
1) "user_id"
2) "1"
3) "name"
4) "Rahim Uddin"
5) "cart_items"
6) "3"

প্রতিটি অনুরোধে EXPIRE আবার চালালে মেয়াদ সরে সরে যায় — sliding expiry: শেষ কাজের ৩০ মিনিট পর লগআউট। মেয়াদ পুরো key-এর, আলাদা field-এর নয়; Redis 7.4-এ field-ভিত্তিক মেয়াদের কমান্ড (HEXPIRE) যোগ হয়েছে বলে ঘোষণা আছে, তবে পুরোনো সংস্করণে নেই।

একই কাজ relational ডেটাবেসে কেমন? নিচের sessions টেবিলে চারটি session: session_id, user_id, cart_items আর expires_at (মেয়াদ শেষের সময়)। লাইভ এডিটরে “এখন” হলো '2025-10-10 12:00:00' — হাতে লেখা, যাতে ফল প্রতিবার একই হয়:

-- প্রতিটি অনুরোধে: session বৈধ কি না
SELECT user_id, cart_items FROM sessions
WHERE session_id = 'c55d' AND expires_at > '2025-10-10 12:00:00';
-- মেয়াদ বাড়ানো (Redis-এ EXPIRE)
UPDATE sessions SET expires_at = datetime('2025-10-10 12:00:00', '+30 minutes')
WHERE session_id = 'c55d';
-- আলাদা পরিষ্কারের job: মেয়াদোত্তীর্ণ সারি মোছা
DELETE FROM sessions WHERE expires_at <= '2025-10-10 12:00:00';
SELECT session_id, user_id, expires_at FROM sessions ORDER BY expires_at;

৩ · List, set আর sorted set — queue, unique visitor আর leaderboard

List — সরল queue

List হলো দুই মাথা-খোলা ক্রম (linked list-এর মতো): LPUSH বাঁ দিকে ঢোকায়, RPOP ডান দিক থেকে বের করে — দুটিই O(1). এক দিকে ঢোকানো, অন্য দিকে বের করা মানে FIFO queue: একটি অ্যাপ SMS পাঠানোর কাজ জমা রাখে, পেছনের worker একটি একটি করে নিয়ে পাঠায়।

redis> LPUSH queue:sms "otp:01711000001" "otp:01811000002"
(integer) 2
redis> RPOP queue:sms                        # আগে যে এসেছে, সে আগে
"otp:01711000001"
redis> BRPOP queue:sms 5                     # খালি হলে ৫ সেকেন্ড অপেক্ষা
1) "queue:sms"
2) "otp:01811000002"
redis> LMOVE queue:sms queue:sms:working RIGHT LEFT
(nil)

BRPOP (blocking) worker-কে বারবার জিজ্ঞেস করা থেকে বাঁচায়। কিন্তু RPOP-এর পর worker crash করলে কাজটি হারায় — বের করা হয়ে গেছে, পাঠানো হয়নি। নিরাপদ রূপ LMOVE (Redis 6.2+): কাজটি একটি “চলছে” তালিকায় সরানো, পাঠানো শেষে সেখান থেকে মোছা; এখানে queue খালি, তাই (nil). এর চেয়ে গুরুতর প্রয়োজনে stream (অংশ ৪)।

Set — অনন্য সদস্য: unique visitor

Set-এ প্রতিটি সদস্য একবারই থাকে। একই ভিজিটর দশবার এলেও একবার গোনা — SADD জানায় কয়টি নতুন যোগ হলো, SISMEMBER আর SCARD O(1):

redis> SADD visitors:2025-10-01 u1 u2 u3 u1 u2
(integer) 3
redis> SADD visitors:2025-10-02 u2 u4 u2 u5 u1
(integer) 4
redis> SCARD visitors:2025-10-02
(integer) 4
redis> SISMEMBER visitors:2025-10-01 u4
(integer) 0
redis> SINTER visitors:2025-10-01 visitors:2025-10-02
1) "u1"
2) "u2"

set-এ ক্রম নির্দিষ্ট নয়, তাই SINTER-এর ফল অন্য ক্রমেও আসতে পারে। একই প্রশ্ন SQL-এ — page_views টেবিলে প্রতিটি পাতা দেখার একটি সারি (visitor_id, day):

SELECT day, COUNT(*) AS views, COUNT(DISTINCT visitor_id) AS unique_visitors
FROM page_views GROUP BY day;
-- দুই দিনেই এসেছেন (Redis-এ SINTER)
SELECT visitor_id FROM page_views WHERE day = '2025-10-01'
INTERSECT
SELECT visitor_id FROM page_views WHERE day = '2025-10-02';
SELECT COUNT(DISTINCT visitor_id) AS either_day FROM page_views;

Sorted set — leaderboard-এর জন্য বানানো

Sorted set (ZSET) হলো এমন set, যার প্রতিটি সদস্যের একটি সংখ্যা — score — আছে, আর সদস্যরা সবসময় score-এর ক্রমে সাজানো। ভেতরে দুটি গঠন একসাথে: সদস্য থেকে score খোঁজার hash table (O(1)), আর ক্রম রাখার skip list. skip list-এর প্রতিটি লিংক জানে সে কয়টি সদস্য ডিঙিয়ে যায় (span); ওপর থেকে নামার পথে সেগুলো যোগ করলেই অবস্থান — তাই ZADD, ZINCRBY, ZREVRANK প্রত্যাশিত O(log N), আর প্রথম M জন আনা O(log N + M). একটি অনলাইন কুইজ প্রতিযোগিতার মাসিক leaderboard, ধাপে ধাপে:

একই leaderboard SQL-এ — scores টেবিলে player আর score, একই পাঁচজন:

UPDATE scores SET score = score + 400 WHERE player = 'Tanim';   -- ZINCRBY
SELECT player, score, RANK() OVER (ORDER BY score DESC) AS pos
FROM scores ORDER BY score DESC LIMIT 3;
-- একজনের অবস্থান: তাঁর চেয়ে বেশি কয়জন, যোগ ১
SELECT COUNT(*) + 1 AS tanim_pos FROM scores
WHERE score > (SELECT score FROM scores WHERE player = 'Tanim');
EXPLAIN QUERY PLAN SELECT player, score FROM scores ORDER BY score DESC LIMIT 3;
CREATE INDEX scores_by_score ON scores(score);
EXPLAIN QUERY PLAN SELECT player, score FROM scores ORDER BY score DESC LIMIT 3;

৪ · Stream, pub/sub, bitmap আর HyperLogLog

Stream (Redis 5.0, ২০১৮) হলো শুধু-যোগ-করা একটি log — প্রতিটি entry-র সময়ভিত্তিক id আর কয়েকটি field. list-এর queue-এর চেয়ে শক্ত: entry পড়লেও মোছে না, আর একটি consumer group-এর কয়েকজন worker কাজ ভাগ করে নেয়; প্রত্যেকে কাজ শেষে XACK দিয়ে জানায়, না জানালে কাজটি “অপেক্ষমাণ” তালিকায় থাকে, পরে অন্য কেউ তুলে নিতে পারে:

redis> XADD orders:events * order_id 1011 status paid
"1760090400000-0"
redis> XGROUP CREATE orders:events mailer $ MKSTREAM
OK
redis> XREADGROUP GROUP mailer w1 COUNT 10 BLOCK 5000 STREAMS orders:events >
(nil)
redis> XADD orders:events * order_id 1012 status paid
"1760090401500-0"
redis> XREADGROUP GROUP mailer w1 COUNT 10 STREAMS orders:events >
1) 1) "orders:events"
   2) 1) 1) "1760090401500-0"
         2) 1) "order_id"
            2) "1012"
            3) "status"
            4) "paid"
redis> XACK orders:events mailer 1760090401500-0
(integer) 1

* মানে id Redis বানাবে (মিলিসেকেন্ডের সময়-ক্রমিক সংখ্যা; এখানকার সংখ্যাগুলো উদাহরণ)। group তৈরির সময় $ মানে “এখন থেকে নতুনগুলো”, তাই 1011 group পায়নি, আর প্রথম XREADGROUP ৫ সেকেন্ড অপেক্ষা করে খালি হাতে ফেরে; > মানে “কাউকে এখনো দেওয়া হয়নি এমন entry”. বড় মাপের event streaming-এ Kafka-র মতো ব্যবস্থা বেশি প্রচলিত; Redis stream মাঝারি প্রয়োজনে সরল বিকল্প।

Pub/Sub. SUBSCRIBE chat:room:7 করে রাখা সবাই PUBLISH chat:room:7 "hello"-এর বার্তা সাথে সাথে পান। কিন্তু Redis বার্তা জমিয়ে রাখে না: যিনি সেই মুহূর্তে সংযুক্ত নেই, তিনি পাবেন না — বড়জোর একবার (at-most-once). লাইভ notification, চ্যাটের “টাইপ করছেন…”, বা কয়েকটি সার্ভারকে “cache মুছে দাও” বলার জন্য ভালো; হারানো চলবে না এমন কাজে stream.

Bitmap. string-কে bit-এর সারি হিসেবে ব্যবহার: SETBIT active:2025-10-10 4217 1 মানে ৪,২১৭ নম্বর ব্যবহারকারী আজ সক্রিয়, BITCOUNT active:2025-10-10 মোট সক্রিয়। ১ কোটি ব্যবহারকারীর জন্য ১ কোটি bit = ১২,৫০,০০০ বাইট, প্রায় ১.২৫ MB প্রতিদিন — set-এ একই তথ্য এর বহু গুণ জায়গা নিত। শর্ত: id-গুলো ছোট, ঘন সংখ্যা হতে হবে।

HyperLogLog. কোটি অনন্য ভিজিটর গুনতে সব id মনে রাখার দরকার নেই, যদি সামান্য ভুল চলে। PFADD আর PFCOUNT একটি সম্ভাবনাভিত্তিক গঠনে প্রতি key সর্বোচ্চ প্রায় ১২ KB নেয়, আর Redis-এর নথি অনুযায়ী আদর্শ ত্রুটি প্রায় ০.৮১%. দুই দিনের HLL মেলানোও যায় (PFMERGE), কিন্তু “u4 এসেছিলেন কি না” প্রশ্নের উত্তর দেয় না — সদস্য মনে রাখে না।

৫ · Caching pattern — cache-aside থেকে write-behind

Redis-এর সবচেয়ে বড় ব্যবহার cache: ধীর বা দামি কোনো উত্তরের কপি হাতের কাছে রাখা। পর্ব ৫৩-এ cache-এর স্তরগুলো দেখেছেন; এখন অ্যাপের ভেতরের cache-এর নকশা। প্রথমে দেখুন cache কোন ধরনের কোয়েরিকে রক্ষা করে — দোকানের হোম পেজে “সবচেয়ে বেশি বিক্রি” তালিকা, তিনটি টেবিলের join আর aggregation (db-shop: orders-এ অর্ডারের status, order_items-এ প্রতিটি অর্ডারের পণ্য, পরিমাণ আর বিক্রয়মূল্য, products-এ পণ্যের নাম):

SELECT p.product_id, p.name, SUM(oi.quantity) AS units,
       SUM(oi.quantity * oi.unit_price) AS revenue
FROM order_items oi
JOIN orders o   ON o.order_id = oi.order_id
JOIN products p ON p.product_id = oi.product_id
WHERE o.status <> 'cancelled'
GROUP BY p.product_id, p.name
ORDER BY revenue DESC LIMIT 3;
EXPLAIN QUERY PLAN
SELECT p.product_id, SUM(oi.quantity * oi.unit_price) AS revenue
FROM order_items oi JOIN orders o ON o.order_id = oi.order_id
JOIN products p ON p.product_id = oi.product_id
WHERE o.status <> 'cancelled' GROUP BY p.product_id ORDER BY revenue DESC LIMIT 3;

Cache-aside — অ্যাপ নিজে cache সামলায়

Cache-aside (lazy loading নামেও পরিচিত) সবচেয়ে প্রচলিত নকশা। Redis ডেটাবেসের কথা কিছু জানে না; অ্যাপ দুজনের সাথে আলাদা কথা বলে:

এবার একই নকশা Python-এ, একটি SQLite “ডেটাবেস” আর একটি dict-কে Redis ধরে। সময় আসল ঘড়ি নয়, একটি সংখ্যা (now), তাই ফল প্রতিবার একই। ১০ মিনিট ধরে প্রতি ১০ সেকেন্ডে একটি অনুরোধ — কয়বার ডেটাবেসে যেতে হলো? তারপর দাম বদলের সময় key না মুছলে কী হয়?

import sqlite3
db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE products (id INTEGER PRIMARY KEY, name TEXT, price INTEGER)")
db.execute("INSERT INTO products VALUES (101, 'Mobile Phone', 15000)")
cache, stats = {}, {"cache_hit": 0, "db_query": 0}   # key -> (value, expires_at)
def get_product(pid, now, ttl=300):
    key = f"shop:product:{pid}"
    if (entry := cache.get(key)) and entry[1] > now:          # GET key
        stats["cache_hit"] += 1; return entry[0]
    stats["db_query"] += 1                                   # miss: ask the database
    row = db.execute("SELECT name, price FROM products WHERE id = ?", (pid,)).fetchone()
    cache[key] = (row, now + ttl); return row                # SET key value EX ttl
def update_price(pid, price, delete_key):
    db.execute("UPDATE products SET price = ? WHERE id = ?", (price, pid))
    if delete_key: cache.pop(f"shop:product:{pid}", None)    # DEL key
for t in range(0, 600, 10): get_product(101, t)              # a request every 10 s for 10 min
print("10 minutes  :", stats)
update_price(101, 14500, delete_key=False); print("t=595 no DEL:", get_product(101, 595))
update_price(101, 14000, delete_key=True);  print("t=596 DEL   :", get_product(101, 596), stats)

10 minutes  : {'cache_hit': 58, 'db_query': 2}
t=595 no DEL: ('Mobile Phone', 15000)
t=596 DEL   : ('Mobile Phone', 14000) {'cache_hit': 59, 'db_query': 3}

আরও তিনটি নকশা

Invalidation — কে, কখন key মুছবে

পর্ব ৫৩-এ দেখেছেন, cache invalidation কঠিন। cache-aside-এ দুটি ফাঁদ বিশেষভাবে পরিচিত। এক, “DB আপডেট হলো, কিন্তু DEL-এর আগে অ্যাপ crash” — key থেকে যায়, TTL-ই ভরসা। দুই, একটি দৌড় (race condition): পাঠক A miss পেয়ে পুরোনো মান পড়লেন, এর মধ্যে লেখক B DB বদলে DEL করলেন, তারপর A পুরোনো মানটি SET করলেন — cache-এ আবার পুরোনো। তাই কেউ কেউ DEL কয়েকশো মিলিসেকেন্ড পর আরেকবার করেন (delayed double delete), কেউ মানের সাথে version রাখেন। সবচেয়ে শক্ত পথ: invalidation-কে লেখার একই transaction-এর অংশ বানানো — পর্ব ২৯-এর trigger দিয়ে একটি outbox টেবিলে “কোন key মুছতে হবে” লিখে রাখা, আর আলাদা একটি worker সেটি পড়ে DEL করে:

CREATE TABLE cache_invalidations (id INTEGER PRIMARY KEY, cache_key TEXT NOT NULL);
CREATE TRIGGER product_cache_bust AFTER UPDATE OF price, stock ON products
BEGIN
  INSERT INTO cache_invalidations (cache_key)
  VALUES ('shop:product:' || NEW.product_id);
END;
UPDATE products SET price = 1100 WHERE product_id = 102;
UPDATE products SET stock = stock - 1 WHERE category_id = 1 AND stock > 0;
UPDATE products SET name = 'DSA Book (2nd ed.)' WHERE product_id = 104;
SELECT id, cache_key FROM cache_invalidations;

৬ · Cache stampede আর eviction — মেমরি ভরলে বা key ফুরোলে

Stampede — একসাথে হাজারো miss

হোম পেজের key-টি প্রতি সেকেন্ডে ৫,০০০ বার পড়া হয়, আর এর পেছনের কোয়েরি ৪০০ ms নেয়। key-এর মেয়াদ শেষ হলো। পরের ৪০০ ms-এ যত অনুরোধ আসে, প্রত্যেকে miss পায় আর প্রত্যেকে একই কোয়েরি ডেটাবেসে পাঠায় — পর্ব ৫৩-এর Little's law-এ প্রায় ৫,০০০ × ০.৪ = ২,০০০টি একই কোয়েরি একসাথে। ডেটাবেস ধীর হয়, কোয়েরি আরও লম্বা হয়, আরও অনুরোধ miss পায়। একে বলে cache stampede বা thundering herd. প্রতিকার তিনটি, প্রায়ই একসাথে:

• একজনই বানাবে (lock): miss পেলে SET lock:home 1 NX PX 5000; যে lock পেল সে ডেটাবেসে যায়, বাকিরা একটু অপেক্ষা করে আবার cache পড়ে — বা পুরোনো মানটি দেখায়।
• মেয়াদে jitter: deploy-এর পর হাজারো পণ্যের key একসাথে EX 3600 পেলে এক ঘণ্টা পর একসাথে মরবে। TTL-এ এলোমেলো ভাগ যোগ করুন — ৩,৬০০ ± ১০% মানে মৃত্যু ছড়িয়ে যায় ৭২০ সেকেন্ডে।
• আগেই নবায়ন: মেয়াদ শেষের কিছু আগে, পেছনে একজন কাজটি নতুন করে বানায় — ব্যবহারকারী কখনো miss দেখেন না। একটি পরিচিত পদ্ধতি সম্ভাবনাভিত্তিক: মেয়াদ যত কাছে, প্রতিটি পাঠকের আগেভাগে নবায়ন করার সম্ভাবনা তত বেশি; ২০১৫ সালের একটি গবেষণাপত্রে (Vattani ও সহলেখক, VLDB) এর গাণিতিক রূপ “XFetch” নামে প্রস্তাব করা হয়।

redis> GET shop:home:top3
(nil)
redis> SET lock:shop:home:top3 w17 NX PX 5000   # worker w17 পেল
OK
redis> SET lock:shop:home:top3 w42 NX PX 5000   # w42 পেল না: অপেক্ষা
(nil)
redis> SET shop:home:top3 "[...]" EX 3437       # 3600 - jitter
OK
redis> DEL lock:shop:home:top3
(integer) 1

maxmemory আর eviction policy

RAM সীমিত। maxmemory 2gb সীমা বসায়; সীমায় পৌঁছালে eviction policy ঠিক করে কী হবে:

Redis-এর LRU নিখুঁত নয়: সব key-এর একটি ক্রমিক তালিকা রাখলে প্রতিটি key-এ বাড়তি মেমরি লাগত। তাই প্রতিবার কয়েকটি key-এর নমুনা নেয় (maxmemory-samples, ডিফল্ট ৫) আর তাদের মধ্যে সবচেয়ে পুরোনোটি সরায় — আনুমানিক, কিন্তু সস্তা। LFU-তে প্রতিটি key-এর একটি ছোট, সময়ের সাথে ক্ষয় হওয়া ব্যবহার-গণক থাকে। পর্ব ৩৯-এর buffer pool-এর মতো এখানেও প্রশ্ন একই: একবার-পড়া scan কি গরম ডেটা ভাসিয়ে দেবে? নিচে ৩টি key-এর জায়গায় নিখুঁত LRU আর LFU-র তুলনা — একটি crawler (bot) মাঝখানে চারটি পাতা একবার করে পড়ে:

from collections import OrderedDict
def simulate(requests, maxkeys, policy):
    cache, hits, evicted = OrderedDict(), 0, []           # key -> access count; order = recency
    for key in requests:
        if key in cache:
            hits += 1; cache[key] += 1; cache.move_to_end(key)   # touched: most recent now
            continue
        if len(cache) == maxkeys:                             # memory full: evict one key
            if policy == "lru": victim = next(iter(cache))    # least recently used
            else: victim = min(cache, key=cache.get)          # least frequently used
            del cache[victim]; evicted.append(victim)
        cache[key] = 1
    return hits, evicted
hot = "home p1 home p2 home p1 home p1"
bot = "x1 x2 x3 x4"                                           # a crawler reads 4 pages once
reqs = (hot + " " + bot + " " + hot).split()
print(len(reqs), "requests")
for policy in ("lru", "lfu"):
    hits, ev = simulate(reqs, 3, policy)
    print(f"{policy}: hits {hits:2}, evicted {' '.join(ev)}")

20 requests
lru: hits 10, evicted p2 home p1 x1 x2 x3 x4
lfu: hits 12, evicted p2 x1 x2 x3 x4

৭ · Rate limiting আর distributed lock

Fixed window — INCR আর EXPIRE

OTP পাঠাতে প্রতিটি SMS-এর খরচ আছে, আর কেউ একটি নম্বরে হাজারবার OTP চাইলে সেটি অপব্যবহার — কারও ফোনে বিরক্তি, প্রতিষ্ঠানের বিল। Rate limiting মানে একটি সময়ের মধ্যে অনুরোধের সংখ্যা সীমিত রাখা। সবচেয়ে সরল রূপ fixed window: প্রতিটি নম্বরের জন্য একটি গণক, প্রথম অনুরোধে ৬০ সেকেন্ডের মেয়াদ, সীমা ৩:

Fixed window-এর একটি জানা দুর্বলতা আছে: window-এর সীমানায় ভিড়। নিচের otp_requests টেবিলে প্রতিটি অনুরোধের নম্বর (phone) আর সময় t (১০:০০:০০ থেকে সেকেন্ডে)। প্রথম নম্বরটি ৫৮ থেকে ৬২ সেকেন্ডের মধ্যে ছয়বার চেয়েছে। এখানে window ঘড়ির মিনিটে বাঁধা (t / 60) — key-এর নামে মিনিট রেখে (rl:otp:…:16) Redis-এও এভাবে করা যায়:

-- fixed window: প্রতিটি ৬০ সেকেন্ডের খোপে কয়টি
SELECT phone, t / 60 AS win, COUNT(*) AS reqs, COUNT(*) > 3 AS blocked_some
FROM otp_requests GROUP BY phone, win ORDER BY phone, win;
-- sliding window: প্রতিটি অনুরোধের আগের ৬০ সেকেন্ডে কয়টি
SELECT phone, t,
       COUNT(*) OVER (PARTITION BY phone ORDER BY t
                      RANGE BETWEEN 59 PRECEDING AND CURRENT ROW) AS last_60s
FROM otp_requests ORDER BY phone, t;

Redis-এ sliding window-এর প্রচলিত রূপ sorted set: প্রতিটি অনুরোধ একটি সদস্য, score তার সময়। প্রতিবার ৬০ সেকেন্ডের পুরোনোগুলো মুছে বাকিগুলো গোনা — নির্ভুল, কিন্তু প্রতি নম্বরে অনুরোধের সমান সদস্য, তাই মেমরি বেশি। মাঝামাঝি পথ: আগের আর এখনকার window-এর দুটি গণককে ভার দিয়ে মেলানো (sliding window counter). চারটি কমান্ড একসাথে পাঠাতে MULTI/EXEC:

redis> MULTI
OK
redis> ZREMRANGEBYSCORE rl:sw:01711000001 0 1760090340000
QUEUED
redis> ZADD rl:sw:01711000001 1760090400000 req-8f2a
QUEUED
redis> ZCARD rl:sw:01711000001
QUEUED
redis> EXPIRE rl:sw:01711000001 60
QUEUED
redis> EXEC
1) (integer) 0
2) (integer) 1
3) (integer) 1
4) (integer) 1

এখানে এখনকার সময় ১৭৬০০৯০৪০০০০০ ms; তার ৬০,০০০ ms আগে পর্যন্ত সব মোছা, নতুনটি যোগ, তারপর গোনা — ফল ১, সীমার মধ্যে। সদস্যের নাম অনন্য রাখুন (এখানে একটি অনুরোধ-id), নইলে একই মিলিসেকেন্ডের দুটি অনুরোধ একটি হয়ে যায়। Redis-এর MULTI/EXEC সবগুলো কমান্ড একসাথে, মাঝে কাউকে না ঢুকিয়ে চালায় — কিন্তু relational transaction-এর মতো rollback নেই: একটি কমান্ড ব্যর্থ হলেও বাকিগুলো চলে।

Distributed lock — SET NX PX, আর তার সীমা

কয়েকটি সার্ভারে চলা একটি অ্যাপে “রাতের হিসাব-মেলানোর job একসাথে একজনই চালাবে” — এর জন্য distributed lock. সঠিক রূপের তিনটি অংশ: অনন্য একটি token (কে lock নিল), NX (না থাকলেই), আর PX মেয়াদ (lock-ধারী মরে গেলেও lock একসময় ছাড়বে)। ছাড়ার সময় শুধু নিজের lock মুছতে হবে — তাই token মিলিয়ে মোছা, একটি atomic Lua script-এ:

redis> SET lock:nightly-recon 7f3c9a NX PX 30000
OK
redis> SET lock:nightly-recon b81e44 NX PX 30000     # অন্য সার্ভার
(nil)
redis> EVAL "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end" 1 lock:nightly-recon 7f3c9a
(integer) 1

শুধু DEL কেন নয়? ধরুন সার্ভার A-র কাজ ৩০ সেকেন্ডের বেশি লাগল; lock মেয়াদে ছেড়ে গেল, B নিল; তারপর A শেষ করে DEL করলে B-র lock মুছে যায়। token মিলিয়ে মুছলে A শুধু নিজেরটি মুছতে পারে। তবু মৌলিক সীমা থেকে যায়: A যদি garbage collection বা network-এর কারণে ৩০ সেকেন্ড থেমে থাকে, সে জানবেই না তার lock গেছে, আর দুজন একসাথে কাজ করবে। এজন্য গুরুত্বপূর্ণ কাজে fencing token পরামর্শ দেওয়া হয়: প্রতিটি lock-এর সাথে একটি বাড়তে থাকা সংখ্যা, আর ডেটাবেস পুরোনো সংখ্যার লেখা প্রত্যাখ্যান করে। বহু Redis node-এ একসাথে lock নেওয়ার Redlock অ্যালগরিদম নিয়ে ২০১৬ সালে প্রকাশ্য বিতর্ক হয়েছিল — Martin Kleppmann ঘড়ি আর বিরতির অনুমান নিয়ে সমালোচনা করেন, antirez জবাব দেন (ভাবনার প্রশ্ন ৩)। ব্যবহারিক নিয়ম: lock যদি শুধু দক্ষতার জন্য হয় (একই কাজ দুবার হলে একটু অপচয়), একটি Redis-এর SET NX PX যথেষ্ট; শুদ্ধতা নির্ভর করলে (দুবার হলে টাকা দুবার কাটে) ডেটাবেসের নিজের constraint বা lock (পর্ব ৪৬), অথবা consensus-ভিত্তিক ব্যবস্থা।

৮ · Persistence, replication, Sentinel আর Cluster

মেমরির ডেটা বিদ্যুৎ গেলেই শেষ — লোডশেডিংয়ে কম্পিউটার বন্ধ হলে খোলা Word ফাইলের মতো। Redis দুইভাবে ডিস্কে টিকিয়ে রাখে:

RDB-এ fork-এর পর child আর parent একই মেমরির page ভাগ করে; parent কোনো page বদলালে তবেই সেটির কপি হয় (copy-on-write) — তাই লেখা-ভারী সময়ে snapshot-এর সময় মেমরি অনেক বাড়তে পারে, সার্ভারে বাড়তি RAM রাখুন। AOF পর্ব ৪৮-এর WAL-এর আত্মীয়, তবে একটি পার্থক্য গুরুত্বপূর্ণ: PostgreSQL commit-এর আগে log ডিস্কে নিশ্চিত করে, আর Redis-এর ডিফল্ট everysec উত্তর আগে দেয়, fsync পরে। নতুন সংস্করণে দুটি মেশানো যায় (AOF-এর শুরুতে RDB). ডিফল্ট কনফিগে সাধারণত RDB চালু আর AOF বন্ধ থাকে — সংস্করণ আর প্যাকেজভেদে দেখে নিন।

Replication. একটি primary, এক বা একাধিক replica; replica প্রথমে একটি snapshot নেয়, তারপর কমান্ডের ধারা। এটি asynchronous: primary client-কে OK বলে আগে, replica-য় পাঠায় পরে। primary মরে গিয়ে replica উঠে এলে শেষ কয়েকটি স্বীকৃত লেখা হারাতে পারে (পর্ব ৫২)। WAIT 1 100 অন্তত একটি replica-র স্বীকৃতির জন্য অপেক্ষা করে, কিন্তু Redis-এর নথিও বলে এটি Redis-কে strongly consistent বানায় না।

Sentinel. কয়েকটি আলাদা Sentinel প্রক্রিয়া (সাধারণত অন্তত তিনটি) primary-কে নজরে রাখে; যথেষ্টসংখ্যক (quorum) একমত হলে একটি replica-কে primary বানায় আর client-দের নতুন ঠিকানা জানায় — স্বয়ংক্রিয় failover, sharding ছাড়া।

Redis Cluster. ডেটা এক মেশিনের RAM-এ না ধরলে sharding (পর্ব ৫৪)। Cluster key-জগৎকে ঠিক ১৬,৩৮৪টি hash slot-এ ভাগ করে: slot = CRC16(key) mod 16384, আর প্রতিটি primary node কিছু slot-এর মালিক। ভুল node-এ কমান্ড গেলে সে MOVED উত্তর দিয়ে সঠিক node দেখায়; client সেটি মনে রাখে। node যোগ করলে কিছু slot সরানো হয় — key ধরে নয়, slot ধরে। একটি নিয়ম মনে রাখতেই হবে: এক কমান্ডে কয়েকটি key (MSET, SINTER, MULTI, Lua) তখনই চলে, যখন সবাই একই slot-এ — নইলে CROSSSLOT error. hash tag দিয়ে সেটি নিশ্চিত করা যায়: {user:42}:cart আর {user:42}:profile-এ শুধু বন্ধনীর ভেতরের অংশ hash হয়, তাই দুটি একই slot-এ।

redis> CLUSTER KEYSLOT user:42:cart
(integer) 12984
redis> CLUSTER KEYSLOT {user:42}:cart
(integer) 15880
redis> CLUSTER KEYSLOT {user:42}:profile
(integer) 15880

hash tag ছাড়া user:42:cart যায় slot ১২,৯৮৪-এ; tag দিলে দুটি key-ই শুধু user:42 থেকে hash হয়, তাই দুটিই ১৫,৮৮০-এ। সাবধান: খুব বেশি key একই tag-এ রাখলে একটি slot, তাই একটি node, অতিরিক্ত ভারী হয়।

৯ · লাইসেন্স ও Valkey, Memcached আর নিরাপত্তা

২০২৪-এর লাইসেন্স বদল আর Valkey

Redis বহু বছর BSD লাইসেন্সে ছিল — একটি permissive open source লাইসেন্স। ২০২৪ সালের মার্চে Redis Ltd. (প্রকল্পের পেছনের প্রতিষ্ঠান) ঘোষণা করে, Redis 7.4 থেকে নতুন সংস্করণ RSALv2 আর SSPL-এর দ্বৈত লাইসেন্সে আসবে; ঘোষিত উদ্দেশ্য ছিল বড় cloud প্রতিষ্ঠানগুলো যেন অবদান ছাড়া এটিকে সেবা হিসেবে বিক্রি না করে। SSPL-কে Open Source Initiative open source লাইসেন্স হিসেবে স্বীকৃতি দেয় না। প্রতিক্রিয়ায় কয়েক সপ্তাহের মধ্যে Linux Foundation-এর অধীনে শেষ BSD সংস্করণ থেকে একটি fork শুরু হয় — Valkey — যাতে AWS, Google Cloud, Oracle-সহ কয়েকটি প্রতিষ্ঠান যুক্ত হয়। পরে, ২০২৫ সালের Redis 8-এ AGPLv3 একটি তৃতীয় বিকল্প হিসেবে যোগ হয়েছে বলে Redis ঘোষণা করেছে। দুই প্রকল্প এখন আলাদা পথে চলছে, যদিও কমান্ড আর protocol এখনো ব্যাপকভাবে মেলে। নিজের প্রকল্পে কোনটি নেবেন, তা প্রতিষ্ঠানের লাইসেন্স-নীতি, cloud সেবা আর প্রয়োজনীয় বৈশিষ্ট্য দেখে ঠিক করুন — বিস্তারিত সর্বশেষ সরকারি সূত্রে যাচাই করে নিন, কারণ এই অবস্থা এখনো বদলাচ্ছে।

Redis বনাম Memcached

Memcached (২০০৩, LiveJournal-এর জন্য Brad Fitzpatrick) in-memory cache-এর পুরোনো ও পরীক্ষিত নাম:

নিরাপত্তা — Redis কখনো ইন্টারনেটে খোলা নয়

Redis বানানো হয়েছিল বিশ্বস্ত, ভেতরের network-এর জন্য। পাসওয়ার্ড ছাড়া খোলা Redis পেলে যে কেউ সব ডেটা পড়তে, মুছতে বা CONFIG-এর মতো কমান্ড দিয়ে সার্ভারের ক্ষতি করতে পারে; ইন্টারনেটে খোলা Redis সার্ভার দখল হওয়ার ঘটনা নিরাপত্তা গবেষকেরা বহুবার জানিয়েছেন। Redis 3.2 থেকে protected mode আছে (পাসওয়ার্ড বা bind না থাকলে বাইরের connection প্রত্যাখ্যান), কিন্তু ভরসা কনফিগে রাখুন:

bind 10.0.1.15 127.0.0.1      # শুধু private network-এর ঠিকানা, কখনো 0.0.0.0 নয়
protected-mode yes
port 6379
# ACL (Redis 6+): প্রতিটি অ্যাপের আলাদা ব্যবহারকারী, ন্যূনতম অনুমতি
user default off
user shopapp on >use-a-long-random-secret ~shop:* +@read +@write -@dangerous
# TLS (Redis 6+), যদি network বিশ্বস্ত না হয়
# tls-port 6380
# tls-cert-file /etc/redis/tls/redis.crt
# tls-key-file  /etc/redis/tls/redis.key

সাথে: firewall বা cloud-এর security group-এ শুধু অ্যাপ সার্ভারগুলোকে 6379-এ ঢুকতে দিন; পাসওয়ার্ড কোডে নয়, secrets manager-এ; -@dangerous দিয়ে FLUSHALL, CONFIG, KEYS-এর মতো কমান্ড অ্যাপের ব্যবহারকারীর জন্য বন্ধ — পর্ব ৫১-এর least privilege. cache-এ ব্যক্তিগত তথ্য (NID নম্বর, ফোন) রাখলে সেটিও ডেটাবেসের মতোই সুরক্ষার দাবি রাখে।

১০ · AI-এর যুগে Redis আর cache

“আমার API-তে Redis cache যোগ করো” — AI কয়েক সেকেন্ডে কোড দেয়, আর সেটি চলেও। কিন্তু cache-এর ভুল প্রায় কখনো error দেখায় না; দেখায় পুরোনো দাম, ভুল স্টক বা হঠাৎ ডেটাবেসের ওপর ঝাঁপিয়ে পড়া। সাধারণ ভুল:

AI-এর দেওয়া cache-কোড চালুর আগে — চেকলিস্ট

• প্রতিটি SET-এ মেয়াদ আছে, আর মেয়াদে কিছুটা jitter
• ডেটা বদলানোর প্রতিটি পথে (UPDATE, DELETE, admin প্যানেল, batch job) key মোছা হয়
• cache বন্ধ করে দিলেও অ্যাপ সঠিক উত্তর দেয় — শুধু ধীর
• hit ratio, evicted_keys আর ডেটাবেসের ভার আগে-পরে মেপেছি
• lock আর rate limit-এর কোডে atomic রূপ (NX, EX, MULTI বা Lua)
• Redis শুধু private network-এ, পাসওয়ার্ড বা ACL সহ; secrets কোডে নেই