Sau khi tớ dùng Redis một thời gian, có vài điều rất đáng rút kinh nghiệm. Redis nhanh thật đấy, nhưng nếu mình dùng sai thì nó đấm lại cả mình lẫn "người khác" (là ai thì bí mật nhé, tớ sẽ không kể là có cả anh leader đâu =))).

1) Luôn set TTL cho cache

Nếu không set TTL:

• Memory tăng dần
• Không kiểm soát được lifecycle dữ liệu
• Key sống dai hơn cả deadline project

Tớ nhớ hồi mới dùng Redis, tớ cache user profile mà… quên set TTL.
Ban đầu thấy mọi thứ rất ổn:

• Response nhanh
• DB đỡ tải

Một thời gian sau:

• Memory Redis tăng đều đều
• DevOps hỏi “em có biết Redis đang ngốn bao nhiêu RAM không?”

Lúc đó mới phát hiện key không bao giờ chết. User đổi thông tin cũng không refresh cache.

→ Kết quả là:

• Data stale
• Memory tăng
• Và tớ thì cũng "toang"=))

→ Bài học:

• Cache sinh ra là để tạm thời.
• Đã là “tạm” thì phải có TTL. Đừng để nó sống bất tử.

2) Quan tâm eviction policy (cơ chế xóa dữ liệu)

Một số policy phổ biến:

• allkeys-lru
• volatile-lru

2.1) allkeys-lru

• Redis sẽ xóa bất kỳ key nào (có TTL hay không)
• Dựa theo nguyên tắc LRU – Least Recently Used (key nào lâu không được dùng thì bay trước)

Hiểu đơn giản:

“Full RAM rồi à? Ok, key nào ít được đụng tới nhất thì tiễn.”

Phù hợp khi:

• Redis dùng thuần làm cache
• Không có key “quan trọng sống chết phải giữ”

Rủi ro:

• Có thể xóa cả key không TTL
• Nếu bạn lưu config hoặc data quan trọng trong Redis → dễ toang

2.2) volatile-lru

• Redis chỉ xóa các key có TTL
• Và cũng theo nguyên tắc LRU

Hiểu đơn giản:

“Chỉ những key đã có hạn sử dụng mới được đem ra cân nhắc xóa.”

Phù hợp khi:

• Redis vừa chứa cache (có TTL)
• Vừa chứa một số key không TTL mà bạn muốn giữ

Rủi ro: Nếu quá nhiều key không TTL → Redis không còn gì để xóa → có thể bị lỗi ghi thêm dữ liệu

Nghe thì có vẻ nhỏ nhặt, nhưng không hiểu cái này là dễ “bay màu” dữ liệu lắm.

Có lần team tớ:

• Cache cả config quan trọng (không TTL)
• Cache cả data API (có TTL)
• Redis dùng allkeys-lru

Khi memory gần full, Redis bắt đầu xóa theo LRU.
Và… nó xóa luôn config quan trọng.

Hệ thống không sập, nhưng chạy sai logic. Mất gần nửa ngày chỉ để debug tại sao config “tự nhiên biến mất”.

→Bài học: Nếu có key quan trọng:

• Hoặc đừng để Redis chịu trách nhiệm
• Hoặc dùng policy phù hợp
• Hoặc tách Redis instance

Đừng nghĩ Redis chỉ là cache vô hại. Nó xóa dữ liệu không báo trước đâu =)).

3) Theo dõi metrics

Nên monitor:

• Memory usage
• Hit ratio
• Evicted keys
• Slow log

Một sai lầm tớ từng dính

Tớ từng rất tự tin:

“Redis nhanh mà, có gì đâu mà monitor.”

Cho đến khi:

• Hit ratio chỉ ~30%
• Nghĩa là 70% request vẫn đập vào DB
• Redis gần như… làm màu cho vui=))

Lý do?
Cache key thiết kế không hợp lý, mỗi request tạo một biến thể khác nhau.

Nghe quen không? =))

À mà nói đến chuyện này…

Tớ từng cache cho API get detail với chục cái filters khác nhau. Mỗi combination filter là một key riêng.

Tech lead nhìn xong chỉ hỏi:

“Em tính dùng Redis làm data warehouse à?”

Thiếu mỗi gõ vào đầu tớ =)))).

Vấn đề như tớ đề cập lần trước:

• Quá nhiều biến thể
• Key tăng theo cấp số nhân
• RAM bay màu cực nhanh

Giải pháp sau đó: Cache theo layer, không cache full response nữa.

==> Kết luận:

• Không phải cái gì cũng cache được.
• Cache sai còn tốn tài nguyên hơn cả không cache.