Đáp án Quiz Redis — 75 câu hỏi có giải thích

Đáp án: B

Key-value, nhưng value có kiểu: string, list, hash, set, sorted set, stream. Chính điều này khác biệt với một cache thuần chuỗi — bạn tăng một số, đẩy vào cuối danh sách hay lấy top N của sorted set mà không cần đọc cả value về ứng dụng.

Đáp án: A

Mất TTL. SET ghi đè cả giá trị lẫn metadata thời gian sống, nên key thành vĩnh viễn. Đây là nguyên nhân rất hay gặp của việc cache phình ra mãi không co lại: code refresh cache bằng SET thuần và vô tình bỏ hạn.

Đáp án: B

Dùng INCR. Mọi lệnh Redis đều nguyên tử vì chạy trên một luồng, nên INCR không có khoảng trống đọc-sửa-ghi. Đọc rồi cộng ở ứng dụng là kiểu mất cập nhật kinh điển.

Đáp án: D

Toàn quyền: đọc mọi dữ liệu, FLUSHALL, đổi cấu hình bằng CONFIG SET. Cache thường chứa token phiên nên mất luôn cả khả năng mạo danh người dùng. Tối thiểu phải có: bind vào mạng nội bộ, đặt mật khẩu, và tắt/rename các lệnh nguy hiểm.

Đáp án: A

SLOWLOG GET cho biết lệnh nào vượt ngưỡng thời gian, INFO cho biết bộ nhớ đã dùng, tỉ lệ hit, số kết nối, tình trạng persistence và replication. Hai lệnh này thường chỉ ra ngay nguyên nhân.

Đáp án: D

Session tách khỏi tiến trình ứng dụng: mọi instance đọc cùng một chỗ nên không cần sticky session, deploy hay scale không làm người dùng bị đăng xuất. TTL của Redis cũng chính là thời gian sống của phiên.

Đáp án: A

GETDEL (Redis 6.2+). Dùng cho các giá trị chỉ được tiêu thụ một lần: mã OTP, token đặt lại mật khẩu, khoá idempotency. Một lệnh nên không ai đọc trùng được.

Đáp án: D

keyspace_hits và keyspace_misses trong phần stats: hit rate = hits / (hits + misses). Con số này tích luỹ từ lúc khởi động nên muốn theo dõi theo thời gian thì phải lấy hiệu giữa hai lần đo.

Đáp án: B

Redis thực thi lệnh đơn luồng trên một vòng lặp sự kiện. Nhờ đó mỗi lệnh là atomic mà không cần khoá, và không có tranh chấp dữ liệu. Từ Redis 6, phần đọc ghi mạng có thể chạy đa luồng, nhưng việc thực thi lệnh vẫn tuần tự.

Đáp án: B

Dùng Hash: HSET session:abc user_id 42 last_seen 1700000000. Cập nhật từng trường bằng một lệnh, không phải đọc và ghi lại toàn bộ object, nên tránh được tình huống hai request ghi đè lẫn nhau.

Đáp án: B

Redis dùng hai cơ chế: xoá lười (khi khoá được truy cập mới kiểm tra và xoá) và quét lấy mẫu (định kỳ lấy ngẫu nhiên một số khoá có TTL, xoá cái đã hết hạn). Vì vậy khoá hết hạn vẫn có thể chiếm bộ nhớ một khoảng thời gian.

Đáp án: B

KEYS duyệt toàn bộ không gian khoá trong một lần thực thi. Vì Redis đơn luồng, mọi client khác bị chặn cho tới khi lệnh xong — trên vài triệu khoá là hàng trăm mili giây tới vài giây. Dùng SCAN để duyệt theo con trỏ, mỗi lần một phần nhỏ.

Đáp án: C

Hai lệnh cho kết quả giống nhau. SET hiện đại hơn vì gộp được nhiều hành vi trong một lệnh: EX/PX cho thời hạn, NX/XX cho điều kiện tồn tại, KEEPTTL để giữ nguyên thời hạn cũ. Nên dùng SET với tuỳ chọn thay vì các lệnh chuyên biệt cũ.

Đáp án: A

Redis mạnh hơn về khả năng: nhiều kiểu dữ liệu, persistence, sao chép, Pub/Sub, Streams, script Lua. Memcached đơn giản hơn, đa luồng và tiết kiệm bộ nhớ hơn cho cache chuỗi thuần. Với hệ thống mới, Redis thường được chọn vì bao trùm được nhiều nhu cầu hơn.

Đáp án: A

HyperLogLog: PFADD visitors:2026-08-17 user:42 và PFCOUNT để lấy số lượng. Dung lượng cố định khoảng 12KB cho mỗi bộ đếm dù có bao nhiêu phần tử, sai số khoảng 0,81%. Còn hợp nhất được nhiều ngày bằng PFMERGE.

Đáp án: C

Không có rollback. Nếu một lệnh lỗi lúc chạy (ví dụ gọi INCR trên khoá kiểu chuỗi), các lệnh còn lại vẫn thực thi và các lệnh trước đó vẫn giữ nguyên tác dụng. Chỉ lỗi cú pháp phát hiện được lúc xếp hàng mới khiến cả khối bị từ chối.

Đáp án: A

-1 nghĩa là khoá tồn tại nhưng không đặt thời hạn; -2 nghĩa là khoá không tồn tại. Phân biệt hai giá trị này quan trọng khi rà soát các khoá cache bị quên đặt TTL.

Đáp án: B

Có, mặc định 16 database đánh số từ 0, chuyển bằng SELECT n. Nhưng chúng chia sẻ cùng tiến trình, bộ nhớ và luồng thực thi — nên đây không phải cách cách ly tải. Chế độ cluster chỉ hỗ trợ database 0.

Đáp án: D

EXISTS key trả về 1 nếu khoá tồn tại, 0 nếu không. Nhận nhiều khoá cùng lúc và trả về số lượng khoá tìm thấy, nên EXISTS a b c trả về 2 nghĩa là có hai trong ba khoá tồn tại.

Đáp án: B

Vì dữ liệu ở RAM và mỗi lệnh chỉ tốn vài micro giây, nên một luồng vẫn phục vụ được hàng trăm nghìn lệnh mỗi giây. Đơn luồng còn là một tính năng: mọi lệnh là nguyên tử, không cần lock, độ trễ ổn định.

Đáp án: B

Vì nó quét toàn bộ keyspace trong một lệnh, mà Redis chỉ có một luồng thực thi — mọi client khác phải chờ. Trên vài triệu key, thời gian chặn đủ để gây timeout hàng loạt. Dùng SCAN với cursor để chia nhỏ.

Đáp án: C

RDB là ảnh chụp toàn bộ dữ liệu theo chu kỳ; AOF là nhật ký các lệnh ghi. RDB cho file gọn và khởi động lại nhanh nhưng mất dữ liệu từ lần chụp cuối; AOF mất ít nhất (thường ≤1 giây với everysec) nhưng file lớn hơn và nạp lại chậm hơn.

Đáp án: B

Lệnh ghi bị lỗi (OOM), lệnh đọc vẫn chạy. Nếu Redis đóng vai cache thì noeviction là cấu hình sai — nên đặt allkeys-lru để nó tự nhường chỗ. Nếu Redis giữ dữ liệu không được phép mất (queue, session bắt buộc) thì noeviction mới đúng.

Đáp án: B

Đọc cache → miss thì đọc DB → ghi vào cache (kèm TTL) → trả kết quả. Ứng dụng chủ động quản lý cache, nên khi cache chết hệ thống vẫn chạy được, chỉ chậm hơn.

Đáp án: C

Gửi liên tiếp nhiều lệnh mà không chờ phản hồi từng cái, rồi đọc toàn bộ phản hồi. Chi phí chi phối trong Redis thường là độ trễ mạng, nên gộp 1000 lệnh vào một pipeline nhanh hơn cả trăm lần so với gửi lẻ.

Đáp án: D

Các lệnh còn lại vẫn chạy — Redis không rollback. Phản hồi của EXEC là một mảng, phần tử tương ứng chứa lỗi. Đây là điểm khiến "transaction" của Redis không giống transaction của SQL.

Đáp án: D

Sorted set. Mỗi phần tử có một điểm và Redis giữ chúng theo điểm, nên ZREVRANGE key 0 9 WITHSCORES cho top 10 ngay, ZINCRBY cộng điểm nguyên tử, ZREVRANK cho biết hạng của một người.

Đáp án: A

Bất đồng bộ. Bản chính trả OK cho client rồi mới đẩy lệnh sang bản sao, nên bản sao có thể trễ và một số lệnh ghi cuối cùng có thể mất nếu bản chính chết đúng lúc đó.

Đáp án: C

Pub/Sub là fire-and-forget: ai không đang nghe thì mất tin. Stream lưu lại tin nhắn kèm id tăng dần, có consumer group, có xác nhận xử lý, nên đọc lại được và biết tin nào chưa xong.

Đáp án: B

Đây là big key: HGETALL hay DEL trên nó chặn luồng đơn hàng chục đến hàng trăm ms, và trong cluster cả key buộc nằm trên một node nên node đó thành điểm nóng. Chia thành nhiều key theo nhóm là cách xử lý.

Đáp án: D

Khi một key nóng hết hạn, hàng loạt request đồng thời đều miss và cùng đi xuống DB. Nặng hơn nữa là nhiều key hết hạn cùng thời điểm vì được nạp cùng lúc với TTL bằng nhau.

Đáp án: C

Hai cách kết hợp: lazy — key hết hạn bị xoá khi có ai truy cập nó; và active — Redis lấy mẫu ngẫu nhiên các key có TTL rồi xoá cái đã hết hạn. Nên bộ nhớ không giảm ngay đúng giây key hết hạn.

Đáp án: A

BRPOP — nó chặn tới khi có phần tử hoặc hết thời gian chờ, nên consumer không phải polling. Ghi việc vào bằng LPUSH, lấy ra bằng BRPOP là mẫu hàng đợi FIFO cơ bản.

Đáp án: D

Cửa sổ cố định: key kiểu rl:<user>:<phút>, INCR mỗi request, nếu trả về 1 thì EXPIRE 60. Key tự hết hạn nên không cần dọn. Gói hai lệnh vào Lua nếu muốn tuyệt đối chắc chắn TTL luôn được đặt.

Đáp án: B

HyperLogLog: PFADD thêm phần tử, PFCOUNT cho số phần tử duy nhất với sai số khoảng 0,81%. Mỗi key chỉ tốn ~12KB dù đếm một tỉ id — đổi độ chính xác tuyệt đối lấy bộ nhớ gần như cố định.

Đáp án: A

Giám sát và failover tự động: nhiều tiến trình Sentinel cùng theo dõi, khi đủ số phiếu đồng ý rằng bản chính đã chết thì chọn một bản sao lên làm chính và thông báo cho client. Nó không chia dữ liệu — đó là việc của Cluster.

Đáp án: A

Xoá key (cache invalidation). Ghi thẳng giá trị mới vào cache nghe hiệu quả hơn nhưng dễ để lại dữ liệu cũ: hai cập nhật đồng thời có thể ghi cache theo thứ tự ngược với thứ tự ghi DB.

Đáp án: B

Bitmap: SETBIT notif:42:read <userId> 1. 10 triệu bit ≈ 1,2MB, BITCOUNT cho số người đã đọc, BITOP kết hợp nhiều bitmap. Điều kiện là id user phải là số nguyên liên tục hoặc map được sang số.

Đáp án: C

Mỗi kết nối tốn thời gian bắt tay (TCP, xác thực) và một bộ đệm riêng; số kết nối còn bị chặn bởi maxclients. Dưới tải cao, ứng dụng sẽ vừa chậm vừa bị từ chối kết nối. Dùng connection pool.

Đáp án: D

Redis có kiểu dữ liệu (list, hash, sorted set, stream), persistence, replication, script. Memcached là key-value phẳng, đa luồng, cực gọn — vẫn tốt nếu bạn chỉ cần cache chuỗi và muốn tận dụng nhiều core.

Đáp án: A

Redis gọi fsync mỗi giây một lần, nên mất điện làm mất tối đa khoảng một giây lệnh ghi cuối. Đây là mặc định vì always (fsync mỗi lệnh) chậm hơn nhiều, còn no thì phụ thuộc hoàn toàn vào hệ điều hành.

Đáp án: D

Khoá idempotency: SET webhook:<event-id> 1 NX EX 86400. Lệnh trả OK nghĩa là lần đầu — xử lý; trả nil nghĩa là đã có — bỏ qua. Một lệnh nên hai retry song song không thể cùng thắng.

Đáp án: D

Sorted set với điểm là timestamp cần chạy: ZADD delayed <runAt> <jobId>. Worker gọi ZRANGEBYSCORE lấy phần tử có điểm ≤ hiện tại, rồi ZREM để nhận việc.

Đáp án: B

Vì ba key băm ra ba slot khác nhau, có thể nằm trên ba node — một lệnh không chạy trên nhiều node được. Giải pháp: hash tag user:{1} không giúp gì ở đây, nên hoặc gọi ba lệnh riêng (pipeline), hoặc thiết kế key để nhóm cần đọc chung có cùng tag.

Đáp án: A

Cache cả giá trị rỗng nhưng TTL ngắn (vài chục giây tới vài phút). Không làm vậy thì ai gọi liên tục các id không tồn tại sẽ đẩy toàn bộ tải xuống DB — gọi là cache penetration.

Đáp án: C

Ứng dụng đọc cache trước; nếu trượt thì truy vấn database, ghi kết quả vào cache kèm TTL rồi trả về. Khi dữ liệu thay đổi, ứng dụng xoá khoá cache thay vì ghi đè. Đây là mẫu phổ biến nhất vì đơn giản và chịu được sự cố của cache.

Đáp án: D

Chuỗi GET rồi SET có khe hở: hai client cùng đọc giá trị 10, cùng ghi 11, và một lần tăng bị mất. INCR thực hiện cả hai bước trong một lệnh atomic, nên hai client cùng gọi sẽ cho kết quả 12.

Đáp án: C

Cả hai loại bỏ khoá ít được dùng gần đây nhất, nhưng volatile-lru chỉ xét các khoá có TTL. Nếu dùng Redis vừa làm cache vừa lưu dữ liệu cần giữ thì volatile-lru an toàn hơn; dùng thuần làm cache thì allkeys-lru phù hợp hơn.

Đáp án: C

RDB lưu ảnh chụp theo chu kỳ: khởi động lại nhanh, file gọn, nhưng mất toàn bộ thay đổi kể từ ảnh chụp cuối. AOF ghi lại từng lệnh thay đổi: mất ít dữ liệu hơn nhiều, đổi lại file lớn hơn và khởi động lại chậm hơn. Hệ thống cần độ bền cao thường bật cả hai.

Đáp án: A

Sorted Set: ZADD leaderboard 1500 user:42 để ghi điểm, ZREVRANGE leaderboard 0 9 WITHSCORES lấy top 10, ZREVRANK leaderboard user:42 tra thứ hạng. Cả hai thao tác đều có chi phí logarit nên phù hợp với bảng hàng triệu người.

Đáp án: C

Pipelining gửi nhiều lệnh trong một lượt truyền thay vì chờ phản hồi từng lệnh. Với độ trễ mạng 1ms, 100 lệnh tuần tự mất khoảng 100ms còn pipeline chỉ mất vài mili giây. Lưu ý: nó không làm nhóm lệnh trở thành atomic.

Đáp án: A

Dùng SET lock:resource <token-ngẫu-nhiên> NX PX 30000: một lệnh atomic vừa giành khoá vừa đặt thời hạn. Giải phóng phải bằng script Lua kiểm tra token khớp rồi mới xoá, tránh việc xoá nhầm khoá do tiến trình khác đang giữ.

Đáp án: C

Pub/Sub là fire-and-forget: subscriber không kết nối lúc phát thì mất thông điệp. Streams lưu lại thông điệp theo thứ tự, có consumer group, cơ chế xác nhận đã xử lý, và đọc lại được — nên dùng được làm hàng đợi tin cậy.

Đáp án: A

Nghi ngờ đầu tiên là khoá không có TTL: cache được ghi bằng SET mà quên EX, hoặc một tiền tố khoá nào đó sinh ra liên tục và không bao giờ hết hạn. Kiểm tra bằng INFO memory, --bigkeys và MEMORY USAGE trên các khoá nghi ngờ.

Đáp án: D

Sai lầm phổ biến nhất là INCR rồi mới EXPIRE ở lệnh riêng: nếu tiến trình chết giữa hai lệnh, bộ đếm tồn tại vĩnh viễn và người dùng bị chặn mãi mãi. Dùng script Lua thực hiện cả hai atomic, hoặc SET key 0 EX ttl NX trước rồi mới INCR.

Đáp án: C

WATCH key đánh dấu khoá cần theo dõi. Nếu khoá đó bị client khác thay đổi trước khi EXEC chạy, cả khối bị huỷ và trả về giá trị rỗng — ứng dụng phải phát hiện điều này và thử lại. Đây là kiểm soát đồng thời lạc quan, không dùng khoá.

Đáp án: D

Mỗi khoá mang theo chi phí cố định khoảng vài chục tới hơn một trăm byte: cấu trúc object, con trỏ, mục trong bảng băm, và TTL nếu có. Với giá trị chỉ vài byte, phần phụ trội lớn hơn cả dữ liệu — nên gộp nhiều giá trị nhỏ vào một hash thường tiết kiệm hơn nhiều.

Đáp án: D

BLMOVE queue processing LEFT RIGHT 5 lấy việc và đưa sang danh sách đang xử lý trong một thao tác atomic. Worker chết giữa chừng thì công việc vẫn nằm ở processing, và một tiến trình giám sát có thể đưa nó trở lại hàng đợi.

Đáp án: A

Keyspace notification phát sự kiện qua Pub/Sub khi khoá bị ghi, xoá hoặc hết hạn. Hữu ích cho việc dọn dữ liệu liên quan hoặc phản ứng khi phiên hết hạn. Hạn chế lớn: fire-and-forget — client mất kết nối sẽ không bao giờ nhận lại được sự kiện đã bỏ lỡ.

Đáp án: D

Quan trọng nhất là tách cấu hình phiên khỏi cấu hình cache: nếu dùng chung một instance với allkeys-lru, phiên đang hoạt động có thể bị loại bỏ khi bộ nhớ đầy và người dùng bị đăng xuất. Nên tách instance, hoặc dùng volatile-lru với TTL đặt cho mọi khoá cache.

Đáp án: A

Dùng nhóm lệnh GEO: GEOADD shops 106.7 10.77 shop:1 để thêm, GEOSEARCH shops FROMLONLAT 106.7 10.77 BYRADIUS 5 km ASC để tìm theo bán kính. Bên dưới là Sorted Set với điểm số là mã geohash 52 bit.

Đáp án: D

Sentinel là hệ thống giám sát và chuyển đổi dự phòng: theo dõi bản chính và bản sao, xác nhận sự cố qua đồng thuận giữa nhiều Sentinel, thăng cấp một bản sao và cập nhật cấu hình cho các bản còn lại. Client hỏi Sentinel để biết địa chỉ bản chính hiện tại.

Đáp án: A

Nên xoá (invalidate) thay vì cập nhật. Với cập nhật, hai request đồng thời có thể ghi cache theo thứ tự ngược với thứ tự ghi database, khiến cache giữ giá trị cũ cho tới khi hết hạn. Xoá thì lần đọc kế tiếp luôn nạp lại giá trị đúng.

Đáp án: A

Tỷ lệ trúng cache, tính từ keyspace_hits và keyspace_misses trong INFO stats. Tỷ lệ thấp nghĩa là cache không giảm được tải cho database — có thể do TTL quá ngắn, khoá bị loại bỏ quá sớm, hoặc mẫu truy cập vốn không lặp lại.

Đáp án: B

Client giữ bản sao cục bộ của các khoá đã đọc; server theo dõi và gửi thông báo vô hiệu hoá khi khoá đó thay đổi. Nhờ vậy các khoá nóng được đọc thẳng từ bộ nhớ tiến trình, bỏ hẳn độ trễ mạng — mô hình cache hai tầng.

Đáp án: A

Dùng SET idem:<key> <trạng-thái> NX EX 86400: chỉ request đầu tiên ghi thành công và được phép xử lý; các request trùng nhận về giá trị đã lưu. Sau khi xử lý xong, ghi đè khoá bằng kết quả để lần gọi lặp trả về đúng phản hồi cũ.

Đáp án: B

SLOWLOG lưu các lệnh có thời gian thực thi vượt slowlog-log-slower-than (mặc định 10.000 micro giây). Nó không tính thời gian truyền qua mạng hay thời gian chờ trong hàng đợi, nên chỉ đúng những lệnh thực sự chiếm luồng thực thi.

Đáp án: D

ACL giới hạn theo ba chiều: lệnh (+get +set -flushall hoặc theo nhóm như +@read), mẫu khoá (~cache:*), và kênh Pub/Sub (&events:*). Nhờ đó mỗi dịch vụ có một tài khoản riêng với đúng quyền nó cần.

Đáp án: C

RESP3 bổ sung kiểu dữ liệu phản hồi phong phú hơn (map, set, số thực, big number, verbatim string) và push message — server chủ động gửi thông báo trên cùng kết nối. Đây là nền cho client-side caching và cho việc nhận Pub/Sub mà không cần kết nối riêng.

Đáp án: D

Mỗi instance hàm mở kết nối riêng, và số instance tăng theo lưu lượng nên tổng số kết nối vượt maxconnections rất nhanh. Cách xử lý: khai báo client ở phạm vi module để tái sử dụng giữa các lần gọi, và dùng proxy hoặc endpoint HTTP không giữ kết nối.

Đáp án: B

Dùng bitmap cho mỗi cờ: SETBIT flag:new_ui 12345 1 bật cho người dùng số 12345, GETBIT để kiểm tra. Một triệu người chỉ tốn khoảng 125KB cho mỗi cờ, và BITCOUNT cho số người đang bật mà không phải duyệt.

Đáp án: A

Consumer group cho phép nhiều consumer chia nhau xử lý một stream: mỗi thông điệp chỉ giao cho một thành viên, phần đã giao mà chưa xác nhận nằm trong danh sách chờ, và XAUTOCLAIM chuyển chúng sang consumer khác khi một consumer chết.

Đáp án: C

Mô hình hai tầng: cache cục bộ giữ dữ liệu ít thay đổi với TTL rất ngắn (vài giây), Redis giữ phần dùng chung giữa mọi instance. Tầng cục bộ bỏ được độ trễ mạng cho dữ liệu nóng, tầng Redis bảo đảm mọi instance nhìn thấy cùng một nguồn.

Đáp án: B

Đặt thấp hơn RAM để chừa chỗ cho: bộ đệm phản hồi của client, bộ đệm sao chép, và đặc biệt là bản sao bộ nhớ phát sinh khi fork để lưu snapshot. Có bật persistence thì khoảng 50–60% RAM là mức thường dùng; không bật thì có thể cao hơn.

Đáp án: B

LPUSH activity:user:42 <item> rồi LTRIM activity:user:42 0 99 ngay sau đó. Danh sách luôn giữ đúng 100 phần tử mới nhất, và LTRIM trên danh sách ngắn có chi phí rất thấp. Gộp hai lệnh trong một pipeline hoặc transaction để giảm lượt đi về mạng.