NoSQL 6 — Redis: mẫu thiết kế thực chiến

Bài trước đã đi qua chất liệu: các kiểu dữ liệu Redis, tính nguyên tử, TTL, MULTI/EXEC, Lua, pipeline. Bài này lắp những chất liệu đó thành mẫu thiết kế (pattern) — các cách kết hợp lệnh Redis đã được kiểm chứng để giải những bài toán lặp đi lặp lại trong hệ thống thực. Mỗi mẫu được trình bày theo một trục cố định: vấn đề gặp phải → giải pháp bằng Redis → cạm bẫy phải tránh. Bối cảnh xuyên suốt là hệ thống ngân hàng NCB: cache số dư và hạn mức, giới hạn tần suất gọi API, chống double-submit khi chuyển tiền.

Lưu ý về sandbox: SQL sandbox của Knowledge Base chạy trên PostgreSQL (chỉ đọc). Mọi khối lệnh Redis/pseudocode trong bài không chạy được ở đây — chúng chỉ minh hoạ cú pháp và luồng logic. Chỉ khối SQL đối chiếu ở cuối bài mới được đánh dấu "▶ Chạy được".

1. Caching — mẫu quan trọng nhất

Vấn đề. Database chính (PostgreSQL, core banking) trả lời chậm và đắt cho những truy vấn lặp lại: đọc số dư tài khoản, hồ sơ khách, hạn mức thẻ — cùng một dữ liệu bị hàng nghìn request hỏi lại trong vài giây. Ta muốn một lớp trả lời trong dưới mili-giây và giảm tải cho DB.

Giải pháp. Đặt Redis làm cache giữa ứng dụng và DB. Có bốn chiến lược khác nhau ở chỗ ai đọc/ghi DB và khi nào.

Cache-aside (lazy loading)

Đây là mẫu phổ biến nhất. Ứng dụng tự quản lý cache: đọc cache trước, miss thì đọc DB rồi tự nạp vào cache.

# pseudocode — cache-aside đọc số dư
val = REDIS.GET("balance:55021")
if val is not null:
    return val                       # cache hit
val = DB.query("SELECT balance FROM accounts WHERE id=55021")
REDIS.SET("balance:55021", val, EX=30)   # nạp vào cache, TTL 30s
return val

• Chỉ nạp thứ được hỏi (lazy) → cache chỉ chứa dữ liệu nóng, tiết kiệm RAM.
• Ứng dụng chịu trách nhiệm cho cả đọc lẫn ghi cache và xử lý miss.
• Nếu Redis chết, hệ thống vẫn chạy (chậm hơn) vì ứng dụng luôn có đường lui về DB.

Read-through và write-through

Với read-through, ứng dụng chỉ nói chuyện với cache; chính lớp cache (thường là một thư viện/proxy) tự đi đọc DB khi miss. Với write-through, mỗi lần ghi, ứng dụng ghi vào cache và cache ghi xuống DB đồng bộ trước khi trả về.

Write-behind (write-back)

Ứng dụng ghi vào cache và trả về ngay; việc ghi xuống DB được gom lại và thực hiện bất đồng bộ sau đó (theo lô hoặc theo lịch). Cho throughput ghi cao nhất, nhưng nếu Redis mất trước khi kịp flush xuống DB thì mất dữ liệu. Trong ngân hàng, write-behind không dùng cho dữ liệu giao dịch/sổ cái (yêu cầu bền vững tuyệt đối); chỉ hợp cho dữ liệu chịu mất được như đếm lượt xem, log hành vi.

TTL và eviction

Cache phải có TTL để dữ liệu cũ tự hết hạn, và Redis phải có chính sách eviction khi RAM đầy. Chính sách phổ biến cho cache là allkeys-lru (đẩy key ít dùng gần đây nhất ra) hoặc allkeys-lfu (ít dùng theo tần suất). Nếu dùng Redis vừa làm cache vừa lưu dữ liệu không được mất (session, lock), tách thành instance riêng — vì eviction có thể xoá cả key quan trọng.

Cạm bẫy caching

Ba lỗ hổng kinh điển, đều xoay quanh cái gì xảy ra khi cache không có dữ liệu:

• Cache invalidation (mất đồng bộ). DB đổi nhưng cache còn giá trị cũ → khách thấy số dư sai. Với dữ liệu nhạy như số dư, dùng TTL ngắn (vài giây tới vài chục giây) và/hoặc chủ động xoá key ngay khi ghi DB (DEL balance:55021 sau mỗi giao dịch trên tài khoản đó). "Có hai việc khó trong khoa học máy tính: đặt tên và invalidate cache."

• Cache stampede (dogpile). Một key nóng hết hạn đúng lúc cao điểm → hàng nghìn request cùng miss, cùng lao vào DB một lúc, DB sập. Chống bằng: (1) lock/mutex — chỉ cho một request đi tính lại, số còn lại chờ hoặc trả giá trị cũ; (2) TTL jitter — thêm ngẫu nhiên vài giây vào TTL để các key không hết hạn cùng khoảnh khắc; (3) early recompute — làm mới trước khi key thật sự hết hạn.

# pseudocode — chống stampede bằng lock (SET NX)
val = REDIS.GET(key)
if val is not null: return val
if REDIS.SET(lock_key, token, NX=True, PX=5000):   # giành quyền tính lại
    val = DB.query(...)
    REDIS.SET(key, val, EX = 30 + random(0..5))     # TTL có jitter
    REDIS.DEL(lock_key)
    return val
else:
    sleep(50ms); return REDIS.GET(key)              # kẻ khác đang tính, chờ

• Cache penetration (xuyên cache). Kẻ tấn công cố tình hỏi những key không tồn tại (id khách không có thật) → luôn miss, mọi request đều đập vào DB. Chống bằng: cache cả kết quả rỗng (SET id:999999 "" EX 60) hoặc dùng Bloom filter để loại nhanh id chắc chắn không tồn tại.

• Cache avalanche (tuyết lở). Rất nhiều key hết hạn cùng lúc (ví dụ đều đặt TTL 3600s lúc khởi động), hoặc cả Redis chết → toàn bộ tải đổ về DB. Chống bằng TTL jitter (như trên) và replica/cluster để Redis không là điểm chết đơn lẻ (xem vận hành Redis).

2. Session store

Vấn đề. API/web cần lưu trạng thái phiên (session) của người dùng — token đăng nhập, vai trò, giỏ giao dịch đang thao tác — nhưng muốn ứng dụng stateless để scale ngang: request có thể rơi vào bất kỳ server nào.

Giải pháp. Lưu session trong Redis, khoá bằng session id, gắn TTL để phiên tự hết hạn (đăng xuất tự động sau khi bất hoạt). Mọi server ứng dụng cùng đọc/ghi một Redis → session chia sẻ, server nào cũng phục vụ được.

SET session:af93k2 '{"cust":10023,"role":"teller","mfa":true}' EX 1800
GET session:af93k2                 # mỗi request đọc phiên
EXPIRE session:af93k2 1800         # gia hạn TTL mỗi lần hoạt động (sliding)
DEL session:af93k2                 # đăng xuất

Dùng Hash thay String nếu cần cập nhật từng trường (ví dụ đánh dấu đã qua MFA) mà không phải ghi lại cả object: HSET session:af93k2 mfa true, nhưng nhớ EXPIRE lại vì HSET trên key có TTL không tự làm mới TTL.

Cạm bẫy. (1) Redis session không bền nếu không cấu hình persistence — Redis chết, mọi người bị đăng xuất; chấp nhận được với session nhưng phải biết trước. (2) Nếu bật allkeys-lru, session có thể bị evict giữa chừng khi RAM đầy → dùng instance riêng hoặc chính sách volatile-lru (chỉ evict key có TTL). (3) Session chứa dữ liệu nhạy cảm → không nhét mật khẩu/PAN thẻ vào, và cân nhắc mã hoá.

3. Rate limiting — chống lạm dụng API

Vấn đề. API mở (đăng nhập, OTP, tra cứu, chuyển tiền) bị lạm dụng: brute-force mật khẩu, spam OTP (tốn tiền SMS), bot cào dữ liệu. Cần giới hạn "mỗi client tối đa N request trong T giây".

Giải pháp. Redis là công cụ chuẩn nhờ counter nguyên tử. Ba thuật toán, tăng dần độ mượt:

Fixed window — INCR + EXPIRE

Chia thời gian thành cửa sổ cố định (mỗi phút). Đếm request trong cửa sổ hiện tại; vượt ngưỡng thì từ chối.

# pseudocode — tối đa 5 OTP / phút cho mỗi số điện thoại
key = "rl:otp:0912345678:" + current_minute       # ví dụ ...:2026-07-03T09:41
n = REDIS.INCR(key)
if n == 1: REDIS.EXPIRE(key, 60)                   # đặt TTL khi tạo cửa sổ mới
if n > 5: reject("too many requests")

INCR nguyên tử nên đếm chính xác kể cả nhiều tiến trình song song. Cạm bẫy: hiệu ứng biên cửa sổ — client gửi 5 request cuối giây thứ 59 và 5 request đầu phút sau → 10 request trong ~2 giây vẫn lọt vì rơi vào hai cửa sổ.

Sliding window

Khắc phục hiệu ứng biên bằng cách tính trên cửa sổ trượt theo thời điểm thật. Cách chính xác: dùng Sorted Set với score = timestamp, mỗi request là một phần tử; xoá phần tử cũ hơn (now − T), rồi đếm phần tử còn lại.

# pseudocode — sliding window 60s bằng Sorted Set
ZREMRANGEBYSCORE key 0 (now - 60000)      # bỏ phần tử ngoài cửa sổ
n = ZCARD key
if n >= limit: reject
ZADD key now  request_id                  # ghi request mới
EXPIRE key 60

Chính xác nhưng tốn RAM hơn (lưu từng request). Biến thể sliding window counter dùng hai cửa sổ cố định và nội suy — nhẹ hơn, gần chính xác.

Token bucket

Mỗi client có một "xô" chứa token, nạp thêm với tốc độ cố định (ví dụ 1 token/giây), mỗi request tiêu 1 token; hết token thì từ chối. Cho phép burst (dùng dồn token tích luỹ) nhưng chặn được tốc độ trung bình — mô hình quota mượt nhất. Thường cài bằng Lua script để nạp-tính-tiêu diễn ra nguyên tử.

Cạm bẫy chung. Rate limit phải nguyên tử (nhiều node cùng đếm) → ưu tiên INCR/Lua, tránh đọc-rồi-ghi tách rời. Và quyết định chặn cứng (reject) hay làm chậm (queue) tuỳ nghiệp vụ: OTP nên reject, còn API báo cáo có thể xếp hàng. Liên quan tới xử lý bất đồng bộ và backpressure, xem async & performance.

4. Distributed lock

Vấn đề. Nhiều tiến trình/worker cùng muốn thao tác trên một tài nguyên và chỉ được phép một làm tại một thời điểm: ví dụ chỉ một job được chạy quyết toán cuối ngày, hay chỉ một worker xử lý một khoản vay. Cần một khoá phân tán vì các tiến trình nằm trên nhiều máy.

Giải pháp. Dùng SET key token NX PX ttl — đặt key chỉ khi chưa tồn tại (NX) kèm thời gian sống (PX, mili-giây). Ai đặt được là người giữ khoá.

# giành khoá: chỉ thành công nếu key chưa có
SET lock:eod_settlement  worker-7-uuid  NX PX 30000
# ... làm việc trong tối đa 30s ...
# nhả khoá AN TOÀN bằng Lua: chỉ DEL nếu token đúng của mình
EVAL "if redis.call('GET',KEYS[1])==ARGV[1] then
        return redis.call('DEL',KEYS[1]) else return 0 end"
     1  lock:eod_settlement  worker-7-uuid

Hai chi tiết bắt buộc:

1. PX (TTL) trên khoá — nếu worker giữ khoá chết mà không nhả, TTL đảm bảo khoá tự hết hạn, tránh deadlock vĩnh viễn.
2. Token ngẫu nhiên + nhả khoá bằng Lua — chỉ người đang giữ mới được DEL. Không có bước kiểm token, worker A có thể vô tình xoá khoá mà worker B vừa giành được (sau khi khoá của A hết hạn) → hai worker cùng chạy.

Cạm bẫy — Redlock và giới hạn. Với một Redis đơn lẻ, nếu node đó chết đúng lúc, khoá mất. Redlock là thuật toán giành khoá trên nhiều Redis độc lập (quá bán) để tăng an toàn. Tuy nhiên Redlock gây tranh cãi: dưới các giả định về clock drift, GC pause, hay network delay, không một khoá phân tán nào dựa trên timeout đảm bảo loại trừ tuyệt đối. Nguyên tắc thực chiến: đừng dùng distributed lock của Redis làm cơ chế đúng-đắn duy nhất cho thao tác không được phép trùng. Với tính đúng đắn tuyệt đối (không trừ tiền hai lần), phải dựa vào ràng buộc ở tầng DB (unique constraint, transaction ACID) — Redis lock chỉ nên đóng vai tối ưu hiệu năng (giảm tranh chấp), không phải bảo đảm cuối cùng.

5. Leaderboard và counter real-time

Vấn đề. Cần bảng xếp hạng và bộ đếm cập nhật liên tục, thời gian thực: top chi nhánh theo doanh số, đếm số giao dịch/lượt truy cập trong ngày. Làm bằng SELECT ... GROUP BY ORDER BY trên bảng giao dịch tỷ dòng thì mỗi lần đọc phải quét lại toàn bảng.

Giải pháp. Counter bằng INCR/INCRBY (String) — nguyên tử, O(1). Leaderboard bằng Sorted Set: score là chỉ số xếp hạng, Redis giữ luôn được sắp.

INCR   txn:count:2026-07-03                       # +1 mỗi giao dịch
INCRBY txn:amount:2026-07-03  5000000             # cộng dồn giá trị
ZINCRBY leaderboard:sales:2026-07  5000000  "cn_cau_giay"   # cộng doanh số chi nhánh
ZREVRANGE leaderboard:sales:2026-07  0 4  WITHSCORES        # top 5, O(log N)
ZRANK    leaderboard:sales:2026-07  "cn_thanh_xuan"          # thứ hạng một chi nhánh

Điểm mạnh: mỗi cập nhật là incremental (cộng dồn tăng dần) O(log N), mỗi lần đọc top-N cũng O(log N + N) — không phụ thuộc tổng số giao dịch. Nhúng chiều thời gian vào key (:2026-07-03, :2026-07) để counter/bảng tự rollover theo ngày/tháng và gắn TTL dọn dẹp.

Cạm bẫy. (1) Counter Redis là thống kê phái sinh, không phải sổ cái — số dư/tổng tiền chính thức phải nằm ở DB ACID; Redis chỉ là bản đếm nhanh, chấp nhận sai lệch tạm thời và có thể rebuild từ DB. (2) Đừng quên TTL, nếu không keyspace phình theo thời gian.

6. Queue, Pub/Sub và Streams

Ba cơ chế cho ba nhu cầu khác nhau về truyền tin.

Queue — hàng đợi tác vụ (List)

Vấn đề: xử lý việc nặng (gửi SMS, sinh báo cáo, chấm điểm rủi ro) bất đồng bộ, tách khỏi luồng request. Giải pháp: producer LPUSH job vào List, worker BRPOP lấy ra (blocking, không cần poll).

LPUSH  queue:sms  '{"to":"0912...","tpl":"OTP","code":"482913"}'
BRPOP  queue:sms  5      # worker chờ tối đa 5s, lấy job từ đuôi → FIFO

Cạm bẫy: BRPOP lấy job ra là job rời khỏi queue; nếu worker chết giữa chừng, job mất. Muốn an toàn dùng LMOVE/BLMOVE sang một list "đang xử lý" và chỉ xoá khi xong (reliable queue) — hoặc dùng Streams.

Pub/Sub — thông báo real-time

Vấn đề: phát một sự kiện tới nhiều người nghe ngay lập tức (đẩy thông báo biến động số dư tới các session đang mở). Giải pháp: PUBLISH lên một kênh, mọi SUBSCRIBE đang nghe nhận được.

SUBSCRIBE  notify:cust:10023           # client đang online lắng nghe
PUBLISH    notify:cust:10023  '{"type":"balance","new":14500000}'

Cạm bẫy quan trọng: Pub/Sub là fire-and-forget — ai không đang subscribe lúc publish sẽ không bao giờ nhận được tin (không lưu lại, không replay). Không dùng Pub/Sub cho dữ liệu không được phép mất. Cần bền + replay → dùng Streams.

Streams — hàng đợi bền, có consumer group

Vấn đề: cần một log sự kiện append-only, bền, cho phép nhiều worker chia nhau xử lý với đảm bảo "mỗi sự kiện được xử lý và xác nhận". Giải pháp: Redis Stream — như Kafka thu nhỏ: XADD ghi sự kiện (có id tự tăng, lưu lại), consumer group cho phép nhiều worker cùng đọc mà chia phần, XACK xác nhận đã xử lý.

XADD  txn:events *  account 55021  amount 5000000  kind debit
XGROUP CREATE  txn:events  scoring  0                # tạo consumer group
XREADGROUP GROUP scoring w1 COUNT 10 STREAMS txn:events >   # w1 lấy phần của mình
XACK  txn:events  scoring  1720000000000-0           # xác nhận xử lý xong

Khác Pub/Sub, Stream lưu sự kiện nên đọc lại được; khác List, consumer group theo dõi ai đã xử lý gì và những message chưa XACK (pending) có thể claim lại khi worker chết → không mất việc. Khi quy mô/độ bền vượt tầm Redis, đây là ranh giới cân nhắc Kafka.

7. Idempotency key — chống double-submit

Vấn đề. Khách nhấn "Chuyển tiền" hai lần, hoặc mạng chập chờn khiến client retry cùng một request → nguy cơ thực hiện giao dịch hai lần. Cần đảm bảo mỗi thao tác chỉ chạy đúng một lần dù request tới nhiều lần.

Giải pháp. Client sinh một idempotency key duy nhất cho mỗi ý định giao dịch (ví dụ UUID gắn với lần nhấn nút). Server dùng SET NX để "chốt" key đó: chỉ request đầu tiên đặt được key mới được thực thi; các request trùng sau đó thấy key đã tồn tại → trả lại kết quả cũ, không thực thi lại.

# request mang header Idempotency-Key: 9f2c-...-a1
if REDIS.SET("idem:transfer:9f2c-...-a1", "processing", NX=True, EX=86400):
    result = execute_transfer(...)                 # lần đầu → chạy thật
    REDIS.SET("idem:transfer:9f2c-...-a1", result, EX=86400)  # lưu kết quả
    return result
else:
    return REDIS.GET("idem:transfer:9f2c-...-a1")  # trùng → trả kết quả cũ

Cạm bẫy. (1) Redis idempotency là lớp chặn nhanh, không thay ràng buộc DB — quyết định đúng đắn cuối cùng vẫn nên có unique constraint trên bảng giao dịch (theo idempotency key) trong cùng transaction, để dù Redis miss vẫn không trùng. (2) TTL của key phải dài hơn cửa sổ retry hợp lý (ví dụ 24h) — hết hạn quá sớm, retry muộn lại lọt qua. (3) Xử lý trạng thái "đang chạy": nếu request đầu chưa xong mà request trùng tới, trả về "đang xử lý" thay vì chạy song song.

Use case thực tế

Bối cảnh. API POST /transfer của mobile banking NCB phục vụ ~300 request/giây giờ cao điểm. Ba yêu cầu phi chức năng đặt lên Redis: (a) cache số dư & hạn mức để màn hình xác nhận hiển thị tức thì mà không đập vào core banking; (b) rate limit 10 lệnh chuyển/phút/khách để chống lạm dụng; (c) chống double-submit khi khách nhấn hai lần hoặc client retry.

Luồng một request chuyển tiền kết hợp bốn mẫu ở trên:

Trình tự lệnh rút gọn phía server:

INCR   rl:transfer:10023:2026-07-03T09:41           # (1) rate limit; n==1 thì EXPIRE 60
SET    idem:transfer:9f2c-a1  processing  NX EX 86400 # (2) chốt idempotency
GET    balance:55021                                  # (3) cache-aside đọc số dư/hạn mức
# ... transaction ACID ở Postgres là nguồn sự thật ...
DEL    balance:55021                                  # (4) invalidate cache sau khi ghi
PUBLISH notify:cust:10023  '{"type":"debit","amount":5000000}'  # (5) thông báo

Ranh giới trách nhiệm rõ ràng: Redis lo tốc độ và chặn lạm dụng/trùng lặp (rate limit, idempotency nhanh, cache); còn tính đúng đắn tiền bạc — kiểm tra số dư, ghi bút toán, chống trừ hai lần — nằm ở transaction ACID của Postgres với ràng buộc unique. Nếu Redis chết, hệ thống suy giảm (chậm hơn, ít lớp chặn hơn) chứ không cho phép chuyển sai tiền.

Đối chiếu với Postgres — cùng dữ liệu "số dư theo currency" mà cache-aside phục vụ, khi phải tính từ DB gốc là một truy vấn tổng hợp; Redis giữ sẵn kết quả nên đọc O(1):

-- ▶ Chạy được
SELECT currency, COUNT(*) AS so_tk, SUM(balance) AS tong_so_du
FROM accounts
GROUP BY currency
ORDER BY tong_so_du DESC;

Câu trên quét/tổng hợp toàn bộ accounts mỗi lần chạy; với cache-aside, kết quả này được lưu trong Redis kèm TTL và chỉ tính lại khi miss — đó chính là giá trị của lớp cache.

Ghi nhớ

• Caching là mẫu quan trọng nhất. Cache-aside (lazy) phổ biến nhất: đọc cache → miss → đọc DB → tự nạp. Phân biệt read-through/write-through (đồng bộ) và write-behind (async, nhanh nhất nhưng rủi ro mất — không dùng cho dữ liệu giao dịch).
• Bốn cạm bẫy cache: invalidation (TTL ngắn + chủ động DEL), stampede (lock + TTL jitter + recompute sớm), penetration (cache kết quả rỗng / Bloom filter), avalanche (jitter + replica).
• Session store: khoá bằng session id + TTL (đăng xuất tự động), chia sẻ giữa nhiều server → app stateless. Tách instance/volatile-lru để session không bị evict như cache.
• Rate limiting: fixed window (INCR+EXPIRE, có hiệu ứng biên), sliding window (Sorted Set theo timestamp, chính xác hơn), token bucket (mượt, cho burst). Phải nguyên tử.
• Distributed lock: SET NX PX + token ngẫu nhiên + nhả khoá bằng Lua. Redlock có giới hạn — đừng dựa vào lock Redis làm bảo đảm đúng-đắn cuối cùng; ràng buộc ACID/unique ở DB mới là chốt chặn.
• Leaderboard/counter real-time: INCR/ZINCRBY cộng dồn tăng dần O(log N); nhúng thời gian vào key + TTL. Là thống kê phái sinh, có thể rebuild từ DB — không phải sổ cái.
• Queue (List + BRPOP, lấy-là-mất), Pub/Sub (fire-and-forget, không replay), Streams (bền + consumer group + XACK, tin cậy nhất). Chọn theo yêu cầu độ bền.
• Idempotency key (SET NX + TTL dài) chống double-submit/retry; vẫn cần unique constraint ở DB làm chốt cuối. Redis là lớp chặn nhanh, không thay ACID.