Redis làm cache: pattern chuẩn và cấu hình AOF trên NVMe

Trả lời nhanh: Pattern cache chuẩn với Redis là cache-aside: app hỏi Redis trước → trượt thì hỏi database rồi ghi ngược vào Redis kèm TTL (thời gian sống). Ba cấu hình bắt buộc cho máy production: maxmemory + maxmemory-policy allkeys-lru (đầy RAM tự đuổi key cũ, không chết OOM), mật khẩu requirepass, và chọn độ bền: cache thuần thì RDB snapshot là đủ; dữ liệu không được mất (queue, session) thì bật AOF everysec, fsync mỗi giây, gần như miễn phí trên ổ NVMe.

Redis nhanh đến mức người ta quên nó cũng cần cấu hình tử tế, cho đến ngày RAM đầy, OOM killer ghé thăm, hoặc restart xong queue biến mất. Bài này gói phần "dùng Redis làm cache cho đúng": pattern, TTL, chống stampede, và quyết định bền dữ liệu, mỗi thứ vài dòng cấu hình nhưng là ranh giới giữa đồ chơi và hạ tầng.

Cache-aside: pattern một hình vẽ

# doc
value = redis.get(key)
if value is None:                      # truot cache
    value = db.query(...)              # hoi nguon that
    redis.set(key, value, ex=300)      # ghi nguoc, song 5 phut
return value

# ghi: cap nhat db xong thi XOA cache (de lan doc sau tu lam tuoi)
db.update(...)
redis.delete(key)

Vì sao xóa thay vì ghi đè khi update: tránh race condition hai tiến trình ghi chéo làm cache lệch nguồn. Xóa là an toàn mặc định; ghi đè chỉ khi bạn hiểu rõ thứ tự sự kiện của mình. TTL luôn phải có, cache không hạn dùng là rác bất tử chiếm RAM.

Ba dòng cấu hình sống còn

# /etc/redis/redis.conf
maxmemory 1gb
maxmemory-policy allkeys-lru     # day thi duoi key it dung nhat
requirepass mat-khau-manh        # redis khong mat khau + lo port = bi chiem trong vai phut
bind 127.0.0.1                   # chi nghe noi bo (mac dinh dung, dung mo)

maxmemory đặt theo khẩu phần được chia trên máy (ví dụ 1-2 GB trên VPS 8 GB chạy chung app + database). Không đặt = Redis ăn đến khi hệ điều hành ra tay, và OOM killer không có thói quen chọn đúng nạn nhân.

RDB hay AOF: quyết định theo thứ đựng bên trong

• Cache thuần (mất cũng chỉ ấm máy lại): RDB snapshot định kỳ là đủ, nhẹ I/O, restart có sẵn phần lớn cache, phần thiếu tự làm tươi.
• Session, queue, counter (mất là đau): bật AOF: appendonly yes + appendfsync everysec: ghi log mọi lệnh, fsync mỗi giây, tối đa mất 1 giây dữ liệu khi sự cố. Chế độ always (fsync mỗi lệnh) hiếm khi cần và đắt trên mọi loại ổ.

Ghi chú phần cứng: AOF everysec + RDB rewrite là dòng ghi tuần tự đều đặn xuống ổ, trên NVMe enterprise gần như vô hình; trên ổ chậm chung máy với database, các đợt rewrite có thể tạo nhịp khựng chung. Một lý do nữa để cụm dịch vụ đứng trên nền ổ tốt.

Chống stampede: hai chiêu 5 phút

Bệnh: key nóng hết hạn đúng giờ đông, trăm request cùng trượt, cùng đâm vào database dựng lại một thứ. Database gục vì chính cơ chế sinh ra để bảo vệ nó.

• Khóa dựng lại: chỉ request đầu tiên được quyền build (SET NX một khóa phụ), các request sau dùng tạm giá trị cũ hoặc chờ ngắn.
• TTL lệch ngẫu nhiên: thay vì mọi key sống đúng 300s, cho sống 300 ± ngẫu nhiên 30s, giờ hết hạn rải đều, không còn giây tận thế chung.

Ba dòng cấu hình quyết định

# /etc/redis/redis.conf

# 1. Gioi han bo nho, KHONG dat thi Redis an het RAM roi may chet
maxmemory 2gb

# 2. Khi day bo nho thi lam gi: voi cache, xoa khoa it dung nhat
maxmemory-policy allkeys-lru

# 3. Chi cho ket noi tu may noi bo, va dat mat khau
bind 127.0.0.1
requirepass MAT_KHAU_DAI_VA_NGAU_NHIEN

# Kiem sau khi sua
redis-cli CONFIG GET maxmemory
redis-cli INFO memory | grep -E "used_memory_human|maxmemory_human"
redis-cli INFO stats | grep -E "keyspace_hits|keyspace_misses"

Dòng thứ ba đáng nhấn mạnh: Redis không đặt mật khẩu và mở ra internet là một trong những lỗi bị quét và khai thác nhanh nhất. Máy chủ mới dựng thường bị tìm ra trong vòng vài giờ.

Đọc tỷ lệ trúng bộ nhớ đệm

Chọn cách ghi xuống ổ đĩa

• Nếu Redis chỉ làm bộ nhớ đệm: tắt hẳn việc ghi xuống ổ. Mất dữ liệu đệm không sao, và tắt đi thì nhanh hơn hẳn.
• Nếu Redis giữ hàng đợi công việc hoặc phiên đăng nhập: bật ghi nhật ký thao tác, đặt chế độ đồng bộ mỗi giây. Đây là cân bằng hợp lý giữa an toàn và tốc độ.
• Chế độ đồng bộ mọi lệnh an toàn nhất nhưng chậm hẳn, chỉ dùng khi mất một giây dữ liệu là không chấp nhận được.
• Ghi nhật ký thao tác hợp với ổ NVMe, vì nó ghi liên tục các mẩu nhỏ. Trên ổ chậm, đây là thứ làm Redis khựng.

Chống dồn dập khi khóa hết hạn

Tình huống: một khóa nóng hết hạn, và cùng lúc hàng trăm yêu cầu cùng đi hỏi cơ sở dữ liệu. Hai cách xử đơn giản: cộng thêm một khoảng ngẫu nhiên vào thời gian sống của mỗi khóa để chúng không hết hạn cùng lúc; và dùng một cờ khóa ngắn để chỉ một tiến trình được đi lấy dữ liệu mới, các tiến trình khác chờ và dùng lại kết quả đó.

Câu hỏi thường gặp

Nên cache những gì trước tiên?

Thứ đọc nhiều - đổi ít - dựng đắt: trang danh mục, cấu hình site, kết quả tổng hợp, session. Bắt đầu từ 2-3 chỗ nóng nhất theo log, đừng cache mọi thứ ngày đầu.

Redis với Memcached chọn cái nào?

Redis, cùng độ nhanh nhưng thêm cấu trúc dữ liệu, bền hóa, pub/sub, và là mặc định của mọi tooling mới. Memcached giờ chỉ còn lý do lịch sử.

Redis chung máy với app và database có ổn không?

Rất ổn ở quy mô một VPS, độ trễ localhost gần bằng không là điểm cộng lớn. Kỷ luật duy nhất: chia khẩu phần RAM rõ ràng (maxmemory) để ba anh em không giành nhau.

Khi nào cần Redis Cluster/Sentinel?

Khi một máy không đủ RAM cho dữ liệu cache, hoặc cần failover tự động cho dịch vụ tối quan trọng. Trước mốc đó, tức đa số dự án, một Redis + backup máy chủ định kỳ là kiến trúc vừa vặn.

Bài viết liên quan

• Redis trên VPS: đơn luồng nên xung nhịp quyết định
• Cache là gì? 6 tầng cache từ trình duyệt đến ổ
• VPS ổ Enterprise U.2 NVMe RAID 10 tại TND