Wavi Books · System Design, Backend & Microservices

Redis là gì? Dùng Redis Cache, Session và Queue đúng cách

Nguyễn Minh Trí · Biên tập chuyên môn Wavi Books

Redis là gì, cách dùng Redis cache, session, queue, stream; chiến lược TTL, cache invalidation và lưu ý vận hành cho backend.

## Redis là gì

## Câu trả lời ngắn trước khi đi vào kiến trúc

Redis là gì, cách dùng Redis cache, session, queue, stream; chiến lược TTL, cache invalidation và lưu ý vận hành cho backend. Hãy bắt đầu từ yêu cầu, điểm hỏng và hậu quả nghiệp vụ rồi mới chọn thành phần kỹ thuật.

Một hệ thống có thể chạy rất ổn trong buổi demo nhưng bắt đầu lộ vấn đề khi lưu lượng tăng, mạng chập chờn hoặc một dịch vụ phía sau phản hồi chậm. Lúc đó, câu hỏi đáng giá không phải là thêm công nghệ nào cho sơ đồ đẹp hơn, mà là điểm hỏng thật sự nằm ở đâu và người dùng chịu hậu quả gì.

Redis có thể khiến hệ thống nhanh lên rõ rệt, cũng có thể khiến dữ liệu trở nên khó hiểu nếu dùng như một chiếc hộp thần kỳ. Phần khó nhất không phải lệnh SET hay GET, mà là biết dữ liệu nào được phép cũ.

Redis là kho dữ liệu in-memory hỗ trợ nhiều cấu trúc như string, hash, set, sorted set và stream. Redis thường được dùng cho cache, session, rate limiting, counter và hàng đợi nhẹ.

Tốc độ cao không biến Redis thành database phù hợp cho mọi dữ liệu. Developer phải hiểu tính bền vững, giới hạn bộ nhớ, eviction và cách khôi phục khi node gặp sự cố.

## Những khái niệm cốt lõi cần nắm

## Cache là bản sao có thời hạn, không phải nguồn sự thật

Redis giữ dữ liệu trong bộ nhớ để truy cập nhanh. Bạn có thể dùng cho cache, session, rate limit hoặc hàng đợi nhẹ, nhưng mỗi mục đích cần cách đặt khóa, thời gian sống và xử lý lỗi khác nhau.

## Chuyện gì xảy ra khi đem vào dự án thật?

Một sản phẩm đã đổi giá trong database nhưng cache chưa hết hạn sẽ tạo hai sự thật cùng tồn tại. Nếu không có chiến lược invalidation rõ ràng, tốc độ đạt được có thể phải trả bằng sự tin cậy.

## Nếu bắt đầu hôm nay, tôi sẽ làm thế này

Trước khi cache, hãy đo điểm chậm và xác định mức dữ liệu cũ có thể chấp nhận. Nếu Redis ngừng hoạt động, hệ thống nên chậm đi có kiểm soát thay vì dừng hoàn toàn.

- TTL kiểm soát vòng đời cache.

- Cache-aside tải dữ liệu khi cần.

- Atomic operation hỗ trợ counter và lock.

- Replication và Sentinel tăng khả năng sẵn sàng.

## Lộ trình thực hành từng bước

- Bước 1: Chọn dữ liệu có lợi ích cache rõ ràng.

- Bước 2: Đặt key convention, TTL và metric hit rate.

- Bước 3: Thử kịch bản mất cache, reconnect và dữ liệu cũ.

## Những sai lầm thường gặp

- Không có TTL cho dữ liệu tạm.

- Dùng KEYS trên hệ thống lớn.

- Coi distributed lock là giải pháp tuyệt đối.

## Góc nhìn dành cho người học và developer Việt Nam

Với sản phẩm có lưu lượng biến động tại Việt Nam, Redis có thể giảm tải database đáng kể, nhưng cần giám sát bộ nhớ và thiết kế hệ thống vẫn hoạt động khi cache không sẵn sàng.

## Nên học tiếp như thế nào?

## Redis nằm ở đâu trong kiến trúc Backend?

Redis thường đứng giữa ứng dụng và nguồn dữ liệu chậm hơn, nhưng không phải nguồn sự thật mặc định. Cache giúp giảm latency và tải database; session chia sẻ trạng thái giữa nhiều instance; counter và rate limit tận dụng thao tác atomic; stream hỗ trợ dòng sự kiện nhẹ.

Mỗi use case cần mô hình lỗi riêng. Mất cache có thể chấp nhận nếu ứng dụng đọc lại database. Mất session có thể đăng xuất người dùng. Mất queue có thể mất công việc. Vì vậy không thể dùng cùng cấu hình persistence và replication cho mọi key.

## Cache-aside và bài toán invalidation

```python def get_book(book_id): key = f"book:{book_id}:v1" cached = redis.get(key) if cached: return json.loads(cached) book = database.find_book(book_id) if book: redis.set(key, json.dumps(book), ex=300) return book ```

Cache-aside đơn giản: đọc cache, miss thì đọc database và ghi cache. Khi cập nhật, có thể xóa key để lần đọc sau nạp lại. Khoảng thời gian giữa cập nhật database và xóa cache có thể tạo dữ liệu cũ; thứ tự thao tác, retry và idempotency cần được thiết kế theo mức chấp nhận của nghiệp vụ.

### Cache stampede

Khi một key nóng hết hạn, hàng nghìn request cùng truy cập database. Giải pháp gồm TTL có jitter, mutex/single-flight, refresh trước hạn hoặc stale-while-revalidate. Với dữ liệu cực nóng, nên có khả năng phục vụ bản cũ trong thời gian ngắn thay vì làm sập nguồn dữ liệu.

### Cache penetration và key rỗng

Request liên tục cho ID không tồn tại luôn miss. Có thể cache kết quả rỗng với TTL ngắn, validate input hoặc dùng Bloom filter. Tuy nhiên Bloom filter có false positive và tăng độ phức tạp; chỉ dùng khi lưu lượng xứng đáng.

## Chọn cấu trúc dữ liệu đúng

String dùng cho cache và counter; Hash cho object có trường; Set cho membership; Sorted Set cho ranking và scheduler; Stream cho event log; HyperLogLog cho ước lượng cardinality. Lựa chọn đúng giúp tránh serialize object lớn và giảm số round trip.

Pipeline và Lua script giúp gom nhiều thao tác; transaction Redis không có rollback như database quan hệ. Lua hữu ích cho logic atomic, nhưng script dài làm block event loop nên cần giới hạn.

## Persistence và High Availability

RDB snapshot khôi phục nhanh nhưng có thể mất dữ liệu giữa các snapshot. AOF ghi thao tác chi tiết hơn nhưng tốn I/O và cần rewrite. Nhiều hệ thống cache có thể chấp nhận mất dữ liệu nên ưu tiên tốc độ; session hoặc queue cần đánh giá persistence nghiêm túc hơn.

Replication tạo bản sao nhưng replication bất đồng bộ vẫn có cửa sổ mất dữ liệu. Sentinel tự động failover cho mô hình primary-replica; Cluster chia key theo slot để mở rộng. Cluster không miễn phí: multi-key operation, resharding và vận hành phức tạp hơn.

## Metric phải theo dõi

- Hit rate theo use case, không chỉ toàn cluster.

- Used memory, fragmentation, eviction và expired keys.

- p95/p99 latency, slowlog, blocked clients và connection count.

- Replication lag, failover, persistence error và network bandwidth.

## Failure drill

Tắt Redis trong môi trường thử nghiệm và quan sát ứng dụng. Nếu toàn bộ request chuyển sang database, database có chịu nổi không? Có circuit breaker, timeout và giới hạn concurrency không? Thiết kế tốt phải suy giảm có kiểm soát thay vì chuyển một lỗi cache thành sự cố toàn hệ thống.

## Góc nhìn dành cho developer Việt Nam

Với backend developer và kỹ sư phần mềm tại Việt Nam, kiến thức này đặc biệt hữu ích khi làm sản phẩm có thanh toán, đơn hàng, dữ liệu khách hàng hoặc chuẩn bị phỏng vấn System Design. Nhà tuyển dụng thường quan tâm cách bạn giải thích giả định và đánh đổi hơn là số lượng công nghệ bạn nhớ tên.

## Đọc tiếp trên Wavi Books

Nếu bạn muốn học chủ đề này theo một lộ trình có cấu trúc, có thể xem Designing Data-Intensive Applications, 2nd Edition bản tiếng Việt tại [Wavi Books](/sach/designing-data-intensive-applications-martin-kleppmann-2026). Sách liên quan được đặt sau phần kiến thức để bạn có thể đánh giá nội dung trước khi chọn mua.