Redis

Redis là gì và mô hình cốt lõi

Redis là một server lưu dữ liệu trong RAM (Redis in Action gọi nó là in-memory database/data structure server), truy cập qua TCP bằng các lệnh ngắn như GET, INCR, ZADD.¹ Mỗi key trỏ tới một giá trị có kiểu riêng: string, list, set, hash, sorted set (năm kiểu cốt lõi trong sách),² cộng bitmap, HyperLogLog (Grokking nhắc tới bitmap và hyper log)³ và stream, GEO (không có trong sách của thư viện).⁴ Điểm mạnh của Redis nằm ở chỗ các lệnh thao tác thẳng trên cấu trúc dữ liệu đó, nên bạn không phải đọc cả object về app rồi ghi lại (Grokking: "we don't have to retrieve data structures from it, manipulate them, and then store them back").³

Ba đặc điểm cần nhớ:

• Dữ liệu trong RAM. Redis in Action §2.3 ghi một lượt đọc Redis mất dưới 1 ms với kết nối cục bộ và dưới 5 ms giữa các máy gần nhau trong cùng data center.⁵ Đổi lại, dung lượng bị giới hạn bởi RAM và giá RAM.
• Xử lý lệnh trên một luồng chính. Grokking ghi Redis chạy như một process dùng một core (khác Memcached đa luồng).³ Mỗi lệnh chạy một lần một, nên từng lệnh là atomic, và bạn có thể ghép nhiều bước thành một bằng MULTI/EXEC hoặc Lua script (Redis in Action ch.11: EVAL được coi như một lệnh rất phức tạp nên không có thao tác nào chen vào).⁶ Mặt trái: một lệnh chậm (ví dụ KEYS * trên 10 triệu key) chặn mọi client khác (suy luận từ mô hình một luồng; sách còn nói SAVE chặn mọi lệnh tới khi snapshot xong).⁷
• Persistence là tùy chọn. Redis có thể ghi snapshot hoặc log xuống đĩa,⁷ nhưng thiết kế mặc định vẫn coi RAM là nơi chứa chính. Nếu dữ liệu không được phép mất, cần cân nhắc kỹ cấu hình hoặc giữ bản gốc ở database khác.

Trong sách, các ứng dụng điển hình là cache trang và dòng dữ liệu (ch.2), bộ đếm và log (ch.5), khóa và hàng đợi (ch.6), timeline mạng xã hội (ch.8).⁸ Trong phỏng vấn, Redis xuất hiện ở gần như mọi bài (nhận định của khoá học): cache trước database, rate limiter, đếm view, leaderboard, khóa phân tán, lưu session, tìm tài xế gần nhất. Hiểu rõ mỗi cấu trúc dữ liệu giải quyết bài toán gì sẽ giúp bạn chọn đúng lệnh thay vì nói chung chung "dùng Redis để cache".

Kiến trúc: từ một node tới Cluster

Có ba cách triển khai chính, tăng dần về độ phức tạp.

Một node + replica. Một primary nhận ghi, một hoặc vài replica nhận bản sao và phục vụ đọc (Redis in Action §4.2 và §10.1 về scale đọc bằng slave).⁹ Grokking ghi rõ Redis không đảm bảo strong consistency vì dùng replication bất đồng bộ, nghĩa là khi primary chết, vài lệnh ghi cuối có thể chưa tới replica và bị mất.³¹⁰

Sentinel. Redis in Action §10.1 mô tả Sentinel là chế độ của server Redis: các tiến trình Sentinel theo dõi master và slave, khi master hỏng thì một Sentinel được chọn để chọn slave mới lên làm master và trỏ các slave còn lại sang đó.¹¹ Sentinel giải quyết high availability, không giải quyết giới hạn dung lượng: toàn bộ dữ liệu vẫn nằm trên một primary (suy luận của khoá học). Con số "thường 3 Sentinel" là khuyến nghị vận hành của khoá học.¹²

Redis Cluster. Grokking mô tả cụm Redis tự động shard, mỗi shard có primary và secondary, có cluster manager phát hiện lỗi và failover.¹³ Phần chi tiết sau đây là kiến thức của khoá học (sách Redis in Action bản đầu viết khi Redis Cluster chưa phát hành, chỉ dùng sharding phía client ở ch.10):¹⁴¹² keyspace được chia thành 16.384 hash slot. Slot của một key là CRC16(key) mod 16384. Mỗi primary giữ một dải slot, mỗi primary có replica riêng. Client biết bản đồ slot và gửi lệnh thẳng tới node đúng. Nếu gửi nhầm, node trả lỗi MOVED kèm địa chỉ đúng. Khi thêm node, bạn di chuyển một số slot sang node mới, dữ liệu đi theo slot.

Ràng buộc quan trọng của Cluster: lệnh đụng nhiều key (MGET, SUNION, Lua script, transaction) chỉ chạy được khi tất cả key nằm cùng slot. Cách xử lý là dùng hash tag: phần trong dấu {} mới được băm. Các key cart:{user42}:items và cart:{user42}:total chắc chắn cùng slot. Đổi lại, nếu một tag quá nóng, toàn bộ tải dồn về một node.

Cấu trúc dữ liệu và bài toán mỗi loại giải quyết

Các kiểu và lệnh trong bảng: string, list, set, hash, sorted set và pub/sub có trong Redis in Action ch.3 (§3.1 tới §3.6);¹⁶ bitmap có trong §9.3 (packing bits);¹⁷ stream, GEO, HyperLogLog chưa có trong sách.⁴ Một vài điểm hay bị hỏi kỹ:

• Sorted set là cấu trúc đáng giá nhất. Mỗi phần tử có một score và Redis giữ thứ tự theo score, nên lấy top 10 rất nhanh (độ phức tạp O(log N) nhờ skip list là kiến thức của khoá học).⁴ Redis in Action ch.1 xây hệ thống vote bài viết bằng chính ZSET, §6.4 dùng ZSET cho delayed task (score = thời điểm chạy), §7.2 dùng ZSET để sắp xếp kết quả tìm kiếm.¹⁸ Leaderboard game và "bài viết hot" là ứng dụng cùng loại.
• Pub/Sub không lưu tin nhắn: sách nói người nghe chỉ nhận tin trong lúc còn kết nối và đang nghe, nên subscriber mất kết nối là mất tin.¹⁹ Nếu cần đọc lại hoặc ack, dùng Stream hoặc Kafka.
• Stream (chưa có nguồn trong thư viện)⁴ giống một Kafka thu nhỏ trong một node: có ID tăng dần, consumer group, danh sách tin đang chờ ack. Phù hợp khi khối lượng vừa phải và bạn đã có Redis sẵn.
• GEO (chưa có nguồn trong thư viện)⁴ thực chất là sorted set với score là geohash 52 bit. Đủ tốt cho "tìm tài xế trong 3 km", xem thêm tìm kiếm gần.

API cơ bản và tính atomic với Lua

Ví dụ cache-aside với TTL trong Node.js (thư viện ioredis):

import Redis from "ioredis";
const redis = new Redis(process.env.REDIS_URL!);

export async function getProduct(id: string) {
  const key = `product:${id}`;
  const hit = await redis.get(key);
  if (hit) return JSON.parse(hit);
  const row = await db.product.findUnique({ where: { id } });
  if (row) await redis.set(key, JSON.stringify(row), "EX", 300 + Math.floor(Math.random() * 60));
  return row;
}

// Leaderboard
await redis.zincrby("lb:2026-11", 50, "user:42");
const top10 = await redis.zrevrange("lb:2026-11", 0, 9, "WITHSCORES");

Mẫu cache-aside này giống cache_request() trong Redis in Action §2.3 (đọc cache, trượt thì sinh nội dung và SETEX 300 giây).⁵ TTL có thêm vài giây ngẫu nhiên để tránh nhiều key hết hạn cùng lúc rồi cùng đập vào database (kỹ thuật của khoá học).²⁰

Khi cần "đọc rồi ghi" mà không bị client khác chen ngang, dùng Lua. Script chạy trọn vẹn trên server như một lệnh duy nhất (Redis in Action ch.11).⁶ Ví dụ rate limiter fixed window:

-- KEYS[1] = rl:{user42}:202611021530, ARGV[1] = limit, ARGV[2] = ttl giây
local n = redis.call("INCR", KEYS[1])
if n == 1 then
  redis.call("EXPIRE", KEYS[1], ARGV[2])
end
if n > tonumber(ARGV[1]) then
  return 0
end
return 1

Nếu viết bằng hai lệnh INCR rồi EXPIRE từ app, app có thể crash giữa chừng và key không bao giờ hết hạn. Lua loại bỏ khoảng hở đó. Lưu ý: vì script được coi như một lệnh duy nhất, script dài sẽ chặn cả node, nên giữ script ngắn và tránh vòng lặp lớn.⁶ Ví dụ rate limiter fixed window ở trên là minh hoạ của khoá học.²⁰

Khóa phân tán đơn giản: SET lock:order:9 <token> NX PX 10000 (Redis in Action §6.2 xây khoá bằng Redis, gồm khoá có timeout, và §11.2 viết lại khoá bằng Lua).²¹ Khi nhả khóa, dùng Lua kiểm tra token trước khi DEL để không xóa nhầm khóa của tiến trình khác. Khóa này chịu được hầu hết tình huống, nhưng vì replication bất đồng bộ (xem trên) nên khi failover replica chưa nhận khóa thì hai client có thể cùng giữ. Với tiền bạc, kết hợp thêm fencing token hoặc ràng buộc ở database (xem tranh chấp tài nguyên).

Persistence và eviction

RDB và AOF

Cấu hình phổ biến: bật cả hai, AOF everysec (khuyến nghị thực hành của khoá học).²⁰ Khi BGSAVE fork, sách giải thích bộ nhớ ban đầu được chia sẻ giữa process cha và con, và trang nào bị ghi sẽ không còn chia sẻ nữa; vì vậy node ghi nhiều cần RAM dư tạm thời (mức cụ thể phải đo).⁷ Đây là lý do không nên để Redis dùng hết RAM của máy.

Eviction policy

Grokking ch.16 nêu các chiến lược evict chung (LRU, MRU, LFU, MFU, FIFO) và nói lựa chọn tuỳ hệ thống.²² Các tên policy cụ thể của Redis dưới đây là kiến thức sản phẩm, chưa có trong sách của thư viện.²⁰ Khi chạm maxmemory, Redis xử lý theo maxmemory-policy:

LRU của Redis là xấp xỉ: nó lấy mẫu vài key rồi xóa key cũ nhất trong mẫu, đủ tốt và rẻ.

Capacity và sizing

Các con số dưới đây là ước lượng để tính nhanh, cần benchmark trên tải thật; thông lượng và độ trễ lấy theo Grokking ch.5 và Redis in Action §2.3, hệ số RAM theo quy tắc ước lượng của khoá học.²³⁵²⁴

Ví dụ: cache 20 triệu sản phẩm, key ~30 B, value JSON ~1 KB.

20.000.000 × (30 + 1.024 + 100) B ≈ 23 GB
23 GB × 1,3 (fragmentation, buffer) ≈ 30 GB

Một primary 32 GB chạy được nhưng sát. Hợp lý hơn: Cluster 3 primary × ~16 GB, mỗi primary 1 replica, tổng 6 node. Về QPS: nếu peak 150.000 lệnh/s, 3 primary chia đều mỗi node ~50.000 ops/s, còn dư.

Nếu phải nhắc tới con số của Grokking (ch.5, bảng Important Rates): một cache server phục vụ khoảng 100k–1M request/s, sách nói các con số này xấp xỉ và phụ thuộc loại query, cấu hình máy và thiết kế.²³ Đó là trần lý thuyết, khi trình bày nên dùng ~100k để an toàn.

Khi nào dùng và khi nào không

Bảng dưới là nhận định của khoá học;²⁰ riêng so sánh Memcached với Redis dựa trên Grokking ch.16.³

Vận hành ở quy mô nhỏ và lớn

Quy mô nhỏ (startup, dưới vài GB). Dùng dịch vụ managed: AWS ElastiCache, GCP Memorystore, Upstash, Redis Cloud (không có trong sách của thư viện; giá tuỳ nhà cung cấp). Bạn không phải lo failover và patch. Bật TLS và AUTH, đặt Redis trong private network.

Quy mô vừa (10–100 GB). Chuyển sang Cluster mode (hoặc sharding như Redis in Action ch.10, nơi sách cảnh báo các thao tác nhiều key cần nằm trên cùng shard).¹⁴ Thiết kế key có hash tag ngay từ đầu cho các nhóm key cần lệnh multi-key. Theo dõi used_memory, evicted_keys, keyspace_hits/misses, instantaneous_ops_per_sec, độ trễ p99, và slowlog.

Quy mô lớn (hàng trăm GB, triệu ops/s). Hàng chục primary (giả định của khoá học²⁰). Tự host trên Kubernetes hoặc VM tiết kiệm chi phí nhưng đòi đội vận hành giỏi: resharding, nâng version, xử lý fork trên máy nhiều RAM. Nhiều công ty tách cụm theo mục đích (cache, rate limit, session) để một cụm gặp sự cố không kéo theo tất cả.

Những lỗi vận hành phổ biến: chạy KEYS * trên production (dùng SCAN), lưu value vài MB trong một key, không đặt maxmemory khiến OS kill tiến trình, và để TTL trống trên cache khiến bộ nhớ tăng mãi.²⁰

Điểm nói trong phỏng vấn

• Nói rõ Redis đóng vai trò gì: cache (chấp nhận mất), hay kho dữ liệu chính (cần AOF, replica, và giải thích rủi ro).
• Chọn đúng cấu trúc: ZSET cho leaderboard (Top-K), INCR + TTL hoặc ZSET cho rate limiter, GEO cho gọi xe và Yelp, SET NX PX cho giữ chỗ tạm trong đặt vé.
• Nhắc tính atomic: một lệnh là atomic, nhiều bước thì dùng Lua hoặc MULTI/EXEC (Redis in Action ch.3 và ch.11).⁶
• Khi tính quy mô: đưa công thức RAM, số node, và nói về hot key.
• Khi bị hỏi failover (Grokking): replication bất đồng bộ nên có thể mất ghi cuối; Sentinel cho HA một shard, Cluster cho cả HA và chia dữ liệu qua 16.384 slot.
• Liên hệ caching cho chiến lược invalidate và distributed cache nếu đề bài yêu cầu tự thiết kế một hệ như Redis.

Nguồn trích dẫn

1. Redis in Action · ch.1 Getting to know Redis · §1.1 What is Redis? (tr. 4–7). ↩

2. Redis in Action · ch.1 · §1.2 What Redis data structures look like (tr. 7–15: strings, lists, sets, hashes, sorted sets). ↩

3. Grokking Modern System Design · ch.16 Distributed Cache · bài "Memcached versus Redis" · mục "Redis" và "Memcached versus Redis" (data structure store, một core, replication bất đồng bộ, persistence AOF/RDB, kiểu dữ liệu). ↩ ↩² ↩³ ↩⁴ ↩⁵

4. Chưa có nguồn trong thư viện: Redis Stream, GEO, HyperLogLog (chi tiết) và độ phức tạp sorted set không được mô tả trong Redis in Action bản trong thư viện; chỉ nêu khái niệm cơ bản. ↩ ↩² ↩³ ↩⁴ ↩⁵

5. Redis in Action · ch.2 · §2.3 Web page caching (tr. 30–31: cache_request, độ trễ dưới 1 ms cục bộ, dưới 5 ms cùng data center). ↩ ↩² ↩³

6. Redis in Action · ch.11 Scripting Redis with Lua · §11.1 Adding functionality without writing C (ghi chú "Lua scripts as atomic as single commands or MULTI/EXEC", tr. 252–253). ↩ ↩² ↩³ ↩⁴

7. Redis in Action · ch.4 Keeping data safe and ensuring performance · §4.1 Persistence options (tr. 64–70: snapshot BGSAVE/SAVE, fork, append-only file, appendfsync). ↩ ↩² ↩³ ↩⁴

8. Redis in Action · ch.2 (cache), ch.5 Using Redis for application support (counters, logging), ch.6 Application components in Redis (locks, task queues), ch.8 Building a simple social network. ↩

9. Redis in Action · ch.4 · §4.2 Replication (tr. 70–75) và ch.10 · §10.1 Scaling reads (tr. 228–232). ↩

10. Grokking Modern System Design · ch.9 Databases · bài "Data Replication" · mục "Synchronous versus asynchronous replication". ↩

11. Redis in Action · ch.10 Scaling Redis · §10.1 Scaling reads · phần "Redis Sentinel" (tr. 231). ↩

12. Chưa có nguồn trong thư viện: Redis Cluster (16.384 slot, MOVED, hash tag) và số lượng Sentinel không có trong sách của thư viện (Redis in Action viết trước khi Cluster phát hành); phần này chỉ nêu khái niệm cơ bản. ↩ ↩²

13. Grokking Modern System Design · ch.16 Distributed Cache · bài "Memcached versus Redis" · mục "Redis cluster". ↩

14. Redis in Action · ch.10 · §10.2 Scaling writes and memory capacity (tr. 232–236) và ch.11 · §11.1 (keys phải cùng server khi chạy script). ↩ ↩²

15. Grokking Modern System Design · ch.9 Databases · bài "Data Partitioning" · mục "Consistent hashing" và "Rebalance the partitions". ↩

16. Redis in Action · ch.3 Commands in Redis · §3.1 Strings tới §3.6 Publish/subscribe (tr. 39–57). ↩

17. Redis in Action · ch.9 Reducing memory use · §9.3 Packing bits and bytes (tr. 222–227). ↩

18. Redis in Action · ch.1 §1.3 Hello Redis (voting on articles), ch.6 §6.4 Task queues (delayed tasks) và ch.7 §7.2 Sorted indexes. ↩

19. Redis in Action · ch.3 · §3.6 Publish/subscribe (tr. 54–57). ↩

20. Chưa có nguồn trong thư viện: jitter TTL, ví dụ rate limiter, khuyến nghị cấu hình RDB+AOF, tên các eviction policy, lỗi vận hành và quy mô cụm là thực hành của khoá học. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

21. Redis in Action · ch.6 · §6.2 Distributed locking (tr. 116–126) và ch.11 · §11.2 Rewriting locks and semaphores with Lua (tr. 255–258). ↩

22. Grokking Modern System Design · ch.16 Distributed Cache · bài "Background of Distributed Cache" · mục "Eviction policies". ↩

23. Grokking Modern System Design · ch.5 Back-of-the-envelope Calculations · mục "Standard numbers to remember" (bảng "Important Rates"). ↩ ↩²

24. Quy tắc ước lượng của khoá học · /hoc/chon-server (RAM Redis ×1,3). ↩

25. Grokking Modern System Design · ch.16 Distributed Cache · bài "Evaluation of a Distributed Cache Design" · mục "Scalability" (hot key). ↩