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ì

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

- 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?

Sau khi nắm phần cốt lõi, bạn nên tự xây một dự án nhỏ, ghi lại giả định, tiêu chí đánh giá và giới hạn của giải pháp. Các sách liên quan được Wavi Books gợi ý trong bài giúp bạn đào sâu kiến thức theo lộ trình có hệ thống thay vì chỉ ghép các hướng dẫn rời rạc.

## 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.