Posted inDatabase

Chọn Chiến Lược Caching Redis Phù Hợp: Hướng Dẫn Thực Tế

Database tutorial - IT technology blog
Database tutorial - IT technology blog

Khi Cơ Sở Dữ Liệu Chạm Ngưỡng Giới Hạn

Mọi cơ sở dữ liệu đều có giới hạn. Một instance MySQL tiêu chuẩn trên một VPS cấu hình vừa phải có thể xử lý ổn định khoảng 500–1.000 kết nối đồng thời. Tuy nhiên, khi bạn mở rộng quy mô lên hơn 5.000 request mỗi giây, I/O ổ đĩa sẽ trở thành nút thắt cổ chai nghiêm trọng. Bạn sẽ thấy thời gian phản hồi tăng vọt từ 50ms lên 2 giây hoặc hơn. Độ trễ này không chỉ gây khó chịu cho người dùng mà còn có thể kích hoạt một chuỗi lỗi làm sập toàn bộ hạ tầng của bạn.

Redis giải quyết vấn đề này bằng cách đóng vai trò như một lớp bộ nhớ tốc độ cao. Nó phục vụ dữ liệu trong vài micro giây thay vì mili giây. Tuy nhiên, coi Redis như một “xô chứa dữ liệu” đơn thuần là một sai lầm. Nếu không có chiến lược rõ ràng, sớm muộn gì bạn cũng sẽ gặp phải tình trạng dữ liệu “stale” (cũ) — những thông tin không còn khớp với cơ sở dữ liệu. Tôi đã từng chứng kiến các hệ thống production bị sập vì thiếu kế hoạch xóa cache (invalidation) hợp lý, dẫn đến sự giận dữ của khách hàng và hàng giờ đồng hồ để debug.

Tiêu Chuẩn Ngành: Cache-Aside

Cache-Aside là mô hình phổ biến nhất vì một lý do: nó cực kỳ linh hoạt. Trong mô hình này, ứng dụng sẽ đóng vai trò điều phối chính. Nó kiểm tra cache trước. Nếu không thấy dữ liệu (cache miss), ứng dụng sẽ lấy dữ liệu từ cơ sở dữ liệu và cập nhật vào Redis cho lần truy cập tiếp theo.

Dưới đây là một bản triển khai thực tế bằng Python:

import redis
import json
import time

# Kết nối Redis tiêu chuẩn
r = redis.Redis(host='localhost', port=6379, db=0, decode_responses=True)

def get_user_profile(user_id):
    cache_key = f"user:profile:{user_id}"
    
    # 1. Kiểm tra Redis trước
    cached_data = r.get(cache_key)
    if cached_data:
        return json.loads(cached_data)

    # 2. Cache Miss: Lấy dữ liệu từ MySQL/PostgreSQL
    # Mô phỏng một truy vấn cơ sở dữ liệu chậm mất 300ms
    db_data = {"id": user_id, "name": "Jane Doe", "tier": "premium"}
    time.sleep(0.3) 

    # 3. Cập nhật lại cache với TTL 1 giờ (3600 giây)
    r.setex(cache_key, 3600, json.dumps(db_data))

    return db_data

Cách tiếp cận này rất an toàn. Nếu cụm Redis của bạn ngoại tuyến, ứng dụng chỉ đơn giản là quay lại sử dụng cơ sở dữ liệu. Nó sẽ hơi chậm một chút ở request đầu tiên, nhưng đảm bảo bạn chỉ lưu trữ những dữ liệu mà người dùng thực sự yêu cầu.

So Sánh Ba “Ông Lớn” Trong Chiến Lược Caching

Việc lựa chọn chiến lược nào phụ thuộc vào việc bạn ưu tiên tốc độ đọc, tốc độ ghi hay tính nhất quán dữ liệu nghiêm ngặt.

1. Cache-Aside (Lazy Loading)

Ứng dụng quản lý mọi thứ. Đây là lựa chọn tốt nhất cho các ứng dụng web thông thường, nơi lượng truy cập đọc vượt xa lượng truy cập ghi.

  • Ưu điểm: Khả năng phục hồi cao khi cache gặp lỗi; giữ mức sử dụng bộ nhớ thấp bằng cách chỉ lưu trữ dữ liệu được yêu cầu.
  • Nhược điểm: Vấn đề “Cold Start” — request đầu tiên cho bất kỳ mẩu dữ liệu nào cũng sẽ luôn chậm.

2. Write-Through

Trong mô hình này, ứng dụng coi cache là giao diện dữ liệu chính. Khi bạn cập nhật một bản ghi, bạn cập nhật đồng thời cả cache và cơ sở dữ liệu. Việc ghi chỉ được xác nhận thành công khi cả hai hệ thống đều hoàn tất.

def update_user_email(user_id, new_email):
    # Cập nhật nguồn dữ liệu gốc (database) trước
    db.execute("UPDATE users SET email = %s WHERE id = %s", (new_email, user_id))
    
    # Đồng bộ cache ngay lập tức
    r.set(f"user:profile:{user_id}", json.dumps(new_user_data))

Điều này đảm bảo cache của bạn không bao giờ bị lệch dữ liệu. Hãy sử dụng mô hình này cho các dữ liệu quan trọng như cài đặt người dùng hoặc số dư tài khoản, nơi tính nhất quán là yếu tố không thể thỏa hiệp.

3. Write-Behind (Write-Back)

Đây là chế độ “hiệu năng cao”. Ứng dụng ghi vào Redis và trả về kết quả thành công ngay lập tức. Một tiến trình chạy ngầm sau đó sẽ gom các thay đổi này và đẩy chúng vào cơ sở dữ liệu theo lô (batch).

  • Ưu điểm: Thông lượng ghi (write throughput) cực lớn. Hoàn hảo cho các tính năng như lượt “like” trên mạng xã hội hoặc bảng xếp hạng game thời gian thực.
  • Nhược điểm: Nguy cơ mất dữ liệu. Nếu Redis gặp sự cố trước khi tiến trình chạy ngầm hoàn tất việc đồng bộ, dữ liệu của vài giây cuối cùng sẽ bị mất.

Giải Quyết Cơn Ác Mộng “Dữ Liệu Cũ” (Stale Data)

Tính nhất quán dữ liệu là phần khó nhất trong caching. Nếu người dùng cập nhật hồ sơ nhưng cache vẫn hiển thị tên cũ, ứng dụng của bạn sẽ trông như bị lỗi. Để làm chủ Redis, bạn cần hai công cụ: TTL và Invalidation.

Sức Mạnh Của TTL (Time To Live)

Đừng bao giờ lưu trữ một key mãi mãi. Hãy luôn thiết lập thời gian hết hạn bằng r.setex(). Ngay cả khi logic xóa cache của bạn bị lỗi, dữ liệu cũ cuối cùng cũng sẽ biến mất, cho phép hệ thống tự phục hồi. Đối với hầu hết các ứng dụng, TTL trong khoảng từ 5 phút đến 24 giờ là con số lý tưởng.

Xóa Cache (Invalidation) so với Cập Nhật Cache

Khi dữ liệu thay đổi trong cơ sở dữ liệu, bạn có thể chọn cập nhật cache hoặc xóa key đó đi. Tôi khuyên bạn nên xóa key. Cách này đơn giản hơn và ngăn chặn được tình trạng race condition. Nếu hai tiến trình cùng cố gắng cập nhật một key cache cùng lúc, bạn có thể nhận được dữ liệu bị sai lệch. Việc xóa key sẽ buộc request tiếp theo phải lấy dữ liệu chuẩn từ cơ sở dữ liệu.

Vấn Đề Thundering Herd (Đám Đông Ào Ạt)

Hãy tưởng tượng một tweet viral hoặc một banner trên trang chủ. Nếu key cache đó hết hạn, 10.000 người dùng có thể truy cập vào cơ sở dữ liệu của bạn tại cùng một mili giây. Điều này có thể khiến cơ sở dữ liệu bị sập. Để ngăn chặn điều này, hãy thêm “jitter” (độ nhiễu) vào TTL của bạn. Thay vì đặt mọi key hết hạn sau đúng 3.600 giây, hãy sử dụng một giá trị ngẫu nhiên trong khoảng từ 3.300 đến 3.900.

Checklist Cho Môi Trường Production

Trước khi triển khai, hãy ghi nhớ những bài học đắt giá sau:

  • Theo dõi bộ nhớ: Redis hoạt động trên RAM. Nếu bạn dùng hết 100% dung lượng, Redis sẽ bắt đầu xóa các key dựa trên chính sách loại bỏ (thường là LRU). Hãy cố gắng giữ mức sử dụng bộ nhớ dưới 75% công suất.
  • Tránh dùng KEYS *: Đừng bao giờ chạy lệnh KEYS trên môi trường production. Với một cơ sở dữ liệu có 10 triệu key, nó sẽ làm treo instance Redis của bạn trong vài giây. Hãy sử dụng SCAN để thay thế.
  • Đặt Namespace cho Key: Sử dụng cấu trúc phân cấp rõ ràng như v1:user:profile:101. Điều này giúp bạn dễ dàng xóa các nhóm dữ liệu cụ thể mà không làm ảnh hưởng đến toàn bộ cache.
  • Đừng lạm dụng Caching: Nếu một truy vấn SQL chỉ mất 5ms, việc thêm Redis thậm chí có thể làm nó chậm hơn do độ trễ mạng. Chỉ nên cache những truy vấn tốn kém hoặc được truy cập thường xuyên.

Caching hiệu quả là sự cân bằng giữa tốc độ và tính chính xác. Hãy bắt đầu với Cache-Aside vì tính an toàn của nó. Chỉ chuyển sang Write-Behind nếu cơ sở dữ liệu của bạn thực sự không thể theo kịp khối lượng ghi. Việc tìm ra sự cân bằng này chính là điểm khác biệt giữa một kiến trúc sư hệ thống dày dạn kinh nghiệm và những người còn lại. Chỉ nên cache những truy vấn SQL tốn kém hoặc được truy cập thường xuyên.

Share:
Tags: