Kiến thức Redis cơ bản cho Test Engineer | Commands và phương pháp verify thực tế

"Sao trang sản phẩm không hiển thị vậy?"

Ngay sau khi release, anh senior gọi tôi trong lúc test. Team dev tụ tập lại để tìm nguyên nhân. Ai đó nói "Kiểm tra Redis cache xem sao?"

Lúc đó tôi có nghe qua từ Redis, nhưng thực sự nó làm gì, kiểm tra thế nào thì hoàn toàn không biết. Cuối cùng chỉ đứng nhìn mà không làm được gì.

Sau đó mới biết nguyên nhân là lỗi cấu hình Redis cache. Nếu có kiến thức cơ bản, chắc đã góp phần tìm ra nguyên nhân nhanh hơn.

Từ hôm đó, tôi nhận ra Redis là công nghệ không thể bỏ qua. Lần này tôi sẽ chia sẻ về Redis mà mình đang dùng thực tế trong công việc.

Redis là gì?

Redis là in-memory Key-Value store. Nói đơn giản, nó đóng vai trò "lớp cache tốc độ cao" nằm giữa database và application.

Ví dụ có một API lấy thông tin sản phẩm trên trang thương mại điện tử.

Không có Redis:

1. User gửi request
2. Mỗi lần đều truy cập database
3. Response chậm

Có Redis:

1. Request đầu tiên → Lấy từ database → Lưu vào Redis
2. Từ lần thứ 2 → Lấy nhanh từ Redis
3. Response nhanh hơn rõ rệt

Tức là lưu data hay dùng vào memory để tăng performance toàn bộ hệ thống.

Cơ chế TTL (Time To Live)

Data lưu trong Redis có thể set TTL (Time To Live).

# Cache thông tin sản phẩm trong 60 giây
SET product:1001 "{\"name\":\"Laptop\",\"price\":89800}" EX 60

Sau 60 giây, key này sẽ tự động bị xóa. Đây là cơ chế để data cũ không tồn tại mãi.

Tại sao QA Engineer cần hiểu Redis?

Thành thật mà nói, lúc đầu tôi nghĩ "Đây là thứ developer dùng mà?". Nhưng thực tế ở hiện trường thì khác.

1. Bắt buộc trong performance testing

Khi làm load test, nếu không check được trạng thái Redis thì không ổn.

"Tại sao response lại chậm?" "Hit rate của Redis là bao nhiêu?" "Cache có hoạt động không?"

Không trả lời được những câu hỏi này thì không thể xác định được performance bottleneck.

2. Verify data không hiển thị trên màn hình

User session, số lượng tồn kho, trạng thái login — những thứ này không hiển thị trực tiếp trên UI nhưng được lưu trong Redis.

Chỉ nhìn màn hình thì không biết data có được giữ đúng bên trong hay không. Phải check trực tiếp Redis.

3. Phân tích nguyên nhân sự cố nhanh hơn

Khi gặp bug "Sản phẩm không hiển thị",

• Vấn đề database?
• Vấn đề Redis cache?
• Bug application?

Nếu check được Redis thì việc phân tích nguyên nhân sẽ nhanh hơn rất nhiều.

4. Giao tiếp với developer mượt mà hơn

"Đã có biện pháp cho hot key expire chưa?" "Rủi ro Cache Avalanche thế nào?"

Tham gia được những cuộc trò chuyện này thì độ tin cậy từ team dev cũng tăng lên.

Kiến thức cơ bản về Redis cần nắm

Cấu trúc Key-Value store

Tất cả data đều truy cập qua Key (khóa).

# Ví dụ key thông tin user
user:123:profile
user:123:cart
session:abc123

Thường dùng dấu hai chấm (:) để phân tách, giúp dễ đọc hơn.

In-memory nên nhanh, nhưng dễ mất

Redis lưu data trên memory nên đọc/ghi cực nhanh.

Tuy nhiên, khi server restart thì data sẽ mất (nếu không cấu hình persistence).

Đây vừa là đặc điểm vừa là hạn chế của Redis.

Chỉ cần nắm 5 kiểu data type là OK

Redis không chỉ hỗ trợ string đơn thuần mà còn nhiều data type khác.

Data Type	Đặc điểm	Ví dụ sử dụng	Điểm cần test
String	Key-Value đơn giản	Counter, HTML fragment, distributed lock	Giá trị chính xác, tăng/giảm số
Hash	Dictionary nhiều field	User info, config info	Giá trị field cụ thể
List	List có thứ tự	Queue, timeline	Thứ tự, số lượng phần tử
Set	Tập hợp không trùng	Tag, lottery, deduplication	Kiểm tra tồn tại phần tử
Sorted Set	Tập hợp có score	Ranking, priority queue	Thứ tự sắp xếp và score

Redis commands dùng trong thực tế

Trong môi trường test, dùng redis-cli hoặc GUI tool (AnotherRedisDesktopManager v.v.).

Commands cơ bản

# Kiểm tra key có tồn tại không
EXISTS user:123

# Kiểm tra type của key
TYPE user:123

# Kiểm tra TTL (-1: không expire, -2: không tồn tại)
TTL session:abc123

# Xóa key
DEL test:user:999

# Tìm key theo pattern (cẩn thận trong production)
KEYS user:*

Commands theo data type

String type

# Lấy giá trị
GET product:1001

Hash type

# Lấy tất cả field
HGETALL user:123:profile

# Lấy field cụ thể
HGET user:123:profile email

List type

# Lấy tất cả phần tử
LRANGE queue:orders 0 -1

Set type

# Lấy tất cả phần tử
SMEMBERS tags:article:1001

Sorted Set type

# Lấy theo score giảm dần (kiểm tra ranking)
ZREVRANGE ranking:daily 0 9 WITHSCORES

Test cases thực tế

Case 1: Verify product cache

Sau khi gọi API chi tiết sản phẩm, kiểm tra xem đã cache vào Redis đúng chưa.

# Sau khi request API
GET product:detail:1001

# Kết quả mong đợi: JSON thông tin sản phẩm

Nếu không có cache thì khả năng cao là logic cache có vấn đề.

Case 2: Kiểm tra số lượng tồn kho

Nếu quản lý tồn kho sản phẩm sale bằng Redis, kiểm tra xem số có giảm đúng sau khi mua không.

# Trước khi mua
GET seckill:stock:1001
# Kết quả: 100

# Sau khi mua
GET seckill:stock:1001
# Kết quả: 99

Case 3: Verify session info

Sau khi login, kiểm tra xem session info đã được lưu vào Redis chưa.

HGETALL session:abc123

# Kết quả mong đợi
# user_id: 123
# login_time: 2025-12-02 10:00:00
# role: admin

Case 4: Cleanup test data

Sau khi test xong thì xóa test data.

DEL test:user:999
DEL test:order:*

Lưu ý: FLUSHDB sẽ xóa toàn bộ data nên tuyệt đối không dùng trong production.

4 vấn đề hay gặp trong thực tế

Cache Penetration (Xuyên thủng cache)

Vấn đề: Khi có nhiều request đến data không tồn tại, Redis bị bỏ qua và truy cập trực tiếp vào database.

Cách test: Gửi liên tục request với ID không tồn tại và kiểm tra load database.

# Request liên tục với product ID không tồn tại
for i in {9999..10099}; do
  curl "https://api.example.com/product/$i"
done

Giải pháp:

• Lưu data không tồn tại vào Redis với giá trị "null"
• Dùng Bloom Filter để check trước

Cache Breakdown (Hot key expire)

Vấn đề: Ngay khi cache của sản phẩm hot expire, lượng request lớn đổ vào database.

Cách test: Tạo concurrent request vào thời điểm TTL hết hạn.

# Kiểm tra TTL
TTL product:hot:1001

# Load test ngay trước khi expire
ab -n 1000 -c 100 https://api.example.com/product/1001

Giải pháp:

• Dùng distributed lock để giới hạn reload về 1 request
• Randomize TTL

Cache Avalanche (Tuyết lở cache)

Vấn đề: Nhiều key expire cùng lúc khiến toàn bộ hệ thống down.

Cách test: Tạo nhiều key có cùng TTL và kiểm tra hành vi khi expire.

Giải pháp:

• Thêm giá trị random vào TTL (ví dụ: 300 giây + random 0~60 giây)
• Phân tán load bằng Redis Cluster

Data inconsistency (Không đồng bộ data)

Vấn đề: Database đã update nhưng cache Redis vẫn giữ giá trị cũ.

Cách test:

1. Update trực tiếp database
2. Kiểm tra giá trị lấy từ API
3. Kiểm tra giá trị trong Redis

# Sau khi update database
GET product:1001

# Nếu trả về giá trị cũ thì có inconsistency

Giải pháp:

• Write-Through (update cache khi ghi)
• Cache-Aside (xóa cache khi update)

Tự động hóa verify Redis với Apidog

Kiểm tra Redis thủ công thì mệt và dễ sai sót.

Dùng Apidog có thể tự động hóa API testing và Redis verification trong một workflow.

Cách dùng thực tế:

1. Thực thi API request
2. Verify response
3. Kiểm tra giá trị Redis (implement bằng custom script)
4. So sánh kết quả

Như vậy có thể phát hiện sớm vấn đề kiểu "API bình thường nhưng không lưu vào Redis".

Ưu điểm lớn là reproducibility cao hơn CLI thủ công và có thể share cho cả team.

Apidog Official Site

Kết luận: Hiểu Redis thì chất lượng test tăng lên

Redis giờ đã là kỹ năng bắt buộc với test engineer.

Điều tối thiểu cần nắm:

1. Có thể kết nối Redis trong môi trường test
2. Có thể check thông tin cơ bản bằng KEYS, TYPE, TTL
3. Có thể dùng commands phù hợp với data type (GET, HGETALL, SMEMBERS v.v.)
4. Hiểu khái niệm Cache Penetration, Breakdown, Avalanche

Làm được những điều này thì performance test cũng như phân tích sự cố sẽ mượt mà hơn nhiều.

Giao tiếp với developer cũng thông suốt hơn, và sẽ được đánh giá "QA engineer này hiểu biết đấy".

Hiểu Redis thì chất lượng test lên một tầm cao mới. Hãy thử áp dụng vào thực tế nhé.