Redis thực chiến cho backend

Sê-ri 12 phần về Redis dưới góc nhìn lập trình viên backend: không chỉ GET/SET mà DỰNG REDIS THẬT trong Docker và ĐO THẬT — các kiểu dữ liệu và khi nào dùng, pipeline giảm round-trip, transaction và script Lua nguyên tử, TTL/eviction, pub/sub và streams, cache pattern và chống cache stampede, distributed lock, rate limiting, persistence RDB/AOF, bộ nhớ và big key. Mỗi bài giải thích cơ chế rồi chứng minh bằng số liệu đo được qua redis-cli/benchmark, nêu rõ đánh đổi.

12/12 phần đã đăng Lập trình

1 Redis cho backend từ con số 0: vì sao một kho dữ liệu chạy MỘT luồng lại nhanh hơn 340.000 lệnh/giây Redis nhanh một cách khó tin — hơn 340.000 lệnh mỗi giây, mỗi lệnh dưới một phần mười mili-giây. Điều nghịch lý: nó xử lý lệnh trên đúng MỘT luồng. Bài mở màn sê-ri dựng Redis thật trong Docker, đo throughput bằng redis-benchmark (SET 343.642/giây, GET 346.020/giây), giải thích ba lý do tốc độ (in-memory, single-thread không khoá, I/O đa hợp), và vì sao single-thread cũng chính là lý do mọi lệnh Redis nguyên tử. 22/09/2026 · 6 phút đọc 2 Năm kiểu dữ liệu Redis: chọn đúng kiểu quyết định cả tốc độ lẫn bộ nhớ (leaderboard, bạn chung, và cái giá của sorted set) Redis không phải chỉ là key-value string — nó có năm kiểu dữ liệu, mỗi kiểu giải một lớp bài toán. Bài này demo thật trong redis-lab cả năm: string/hash/list/set/sorted set, với use case thật (leaderboard bằng sorted set, bạn chung bằng SINTER một lệnh). Rồi đo MEMORY USAGE để thấy đánh đổi: hash 88 byte nhỏ hơn JSON 96 byte, nhưng sorted set tốn 87KB so với set 40KB cho cùng 1000 phần tử — cái giá của khả năng xếp hạng. 22/09/2026 · 6 phút đọc 3 Pipeline trong Redis: cắt round-trip để throughput tăng 13 lần, và vì sao nút thắt là mạng chứ không phải Redis Redis xử lý lệnh trong phần trăm mili-giây, nhưng nếu client gửi từng lệnh một và chờ reply, phần lớn thời gian là chờ mạng (round-trip) chứ không phải Redis làm việc. Pipeline gộp nhiều lệnh vào một lần gửi để cắt số round-trip. Bài này đo thật trong redis-lab: cùng một kết nối, SET đạt 333.889 lệnh/giây ở P=1 nhưng 4.444.444 lệnh/giây ở P=50 — nhanh ~13 lần. Và pipeline khác transaction thế nào. 22/09/2026 · 6 phút đọc 4 Transaction và Lua trong Redis: ba cách làm nhiều lệnh nguyên tử, và vì sao Lua mạnh hơn MULTI Khi nhiều client cùng trừ tồn kho hay cùng trừ tiền, race condition làm hỏng dữ liệu. Redis có ba công cụ đảm bảo nguyên tử. Bài này đo thật trong redis-lab: MULTI/EXEC chạy cả khối lệnh liền nhau; WATCH huỷ transaction khi key bị client khác đổi (bal=999 chứ không phải 949, chứng minh DECRBY bị huỷ); và script Lua trừ tồn kho CHỈ KHI đủ — đọc-kiểm-ghi chạy nguyên tử trong một EVAL, thứ MULTI không làm được vì không rẽ nhánh. 22/09/2026 · 6 phút đọc 5 TTL và eviction trong Redis: key tự hết hạn, và vì sao chọn sai chính sách khi đầy bộ nhớ làm hỏng cả hệ thống Redis sống trong RAM có hạn — hai cơ chế quyết định số phận key: TTL (tự hết hạn) và eviction (đẩy key ra khi đầy). Bài này đo thật trong redis-lab: key đặt PX 150ms tự biến mất sau đó (GET trả nil); và với maxmemory 3mb, nạp 100.000 key — chính sách allkeys-lru đẩy 89.992 key để ghi vẫn thành công (bộ nhớ giữ đúng 3.00M), còn noeviction từ chối ghi với lỗi OOM. Chọn chính sách theo vai trò Redis. 22/09/2026 · 6 phút đọc 6 Pub/Sub và Streams trong Redis: hai cách nhắn tin dễ nhầm, khác nhau căn bản ở chỗ giữ hay vứt message Redis có hai cơ chế nhắn tin trông giống nhau nhưng khác nhau một trời một vực. Pub/Sub là loa phát thanh — ai đang nghe thì nghe, phát trước khi ai subscribe là mất luôn. Streams là sổ ghi bền — lưu lại, đọc lại, phát lại, có consumer group chia việc như Kafka thu nhỏ. Bài này đo thật trong redis-lab: PUBLISH khi không subscriber trả về 0 (mất), XADD rồi XRANGE đọc lại được, và consumer group chia entry cho c1/c2 với XACK theo dõi. 22/09/2026 · 6 phút đọc 7 Cache-aside và cache stampede: khi một key nóng hết hạn, 20 request cùng đập database — và cách chặn bằng một lock Cache-aside là pattern cache phổ biến nhất, nhưng nó có một lỗ hổng chết người: khi một key nóng hết hạn, mọi request đến cùng lúc đều miss và cùng đập vào database — cache stampede. Bài này đo thật trong redis-lab: cache HIT 1ms vs MISS 204ms; 20 client đồng thời khi key vắng gây 20 lần query DB; thêm một lock SET NX, số query DB giảm còn đúng 1. Hiểu để một đợt key hết hạn không kéo sập database. 22/09/2026 · 6 phút đọc 8 Distributed lock với Redis: SET NX PX, và vì sao nhả lock bằng DEL là một lỗi nguy hiểm Khoá phân tán để chỉ một tiến trình làm một việc tại một thời điểm trên nhiều máy — nghe đơn giản nhưng viết sai một chút là hỏng dữ liệu. Bài này đo thật trong redis-lab: SET NX PX cho client A giành lock, B thất bại (nil) khi A đang giữ; và quan trọng nhất, nhả lock phải dùng token duy nhất + Lua — demo B nhả với token sai trả 0 (không phá lock của A), A nhả với token đúng trả 1. Hiểu vì sao DEL mù quáng xoá nhầm lock người khác. 22/09/2026 · 6 phút đọc 9 Rate limiting với Redis: fixed window, sliding window và token bucket — ba thuật toán, ba mức mượt Giới hạn số request để chống lạm dụng là bài toán backend kinh điển, và Redis là công cụ lý tưởng nhờ các thao tác nguyên tử. Bài này đo thật trong redis-lab ba thuật toán: fixed window (INCR+EXPIRE, đơn giản nhưng burst ở ranh giới), sliding window (sorted set theo timestamp, mượt hơn, không burst), và token bucket (cho phép burst có kiểm soát). Với limit 5, cả hai đều cho 5 request qua và chặn request 6-7 — nhưng khác nhau ở độ chính xác quanh ranh giới cửa sổ. 22/09/2026 · 6 phút đọc 10 Persistence trong Redis: RDB và AOF — Redis có mất dữ liệu khi chết không, và đánh đổi độ bền vs hiệu năng Redis sống trong RAM, nên câu hỏi sống còn: tắt đi có mất dữ liệu không? Redis có hai cơ chế ghi xuống đĩa với hai triết lý khác nhau. Bài này đo thật trong redis-lab: RDB snapshot (BGSAVE tạo dump.rdb nhỏ gọn, nhưng mất dữ liệu giữa hai lần chụp); AOF ghi mọi lệnh với appendfsync everysec (bền hơn, mất tối đa 1 giây, file lớn hơn). Cùng 1000 key, RDB 16.881 byte vs AOF 21.161 byte. Chọn đúng theo vai trò cache hay store. 22/09/2026 · 5 phút đọc 11 Bộ nhớ và big key trong Redis: một key 34 MB có thể làm nghẽn cả server, và vì sao đừng bao giờ KEYS * Redis chạy một luồng — nên một lệnh O(n) trên key khổng lồ chặn mọi client khác. Bài này đo thật trong redis-lab: một hash 500.000 field chiếm 34,5 MB; HGETALL trên nó mất 224ms (so với 1ms cho hash nhỏ) và suốt thời gian đó cả server khựng; và KEYS * quét toàn bộ keyspace O(n) chặn server, trong khi SCAN duyệt từng lô không block. Hiểu để một key hay một lệnh không kéo sập Redis. 22/09/2026 · 5 phút đọc 12 Tổng kết sê-ri Redis: khi nào dùng Redis khi nào không, và checklist vận hành đúc kết từ 11 bài đo thật Mười một bài, hàng chục phép đo thật — giờ gộp lại thành quyết định dùng được. Bài tổng kết này so Redis với Memcached và database để biết khi nào chọn cái nào, một cây quyết định có nên dùng Redis, và một checklist vận hành ánh xạ về từng bài: kiểu dữ liệu, pipeline, Lua nguyên tử, TTL và eviction, Streams, lock, rate limit, persistence, tránh big key. Redis đi TRƯỚC database, không thay database. 22/09/2026 · 6 phút đọc