Hiểu về caching: cách hoạt động và khi nào nên sử dụng

I. Mở đầu

• Khi phát triển một dự án phần mềm, chúng ta không chỉ quan tâm đến tính năng, mà còn phải cân nhắc đến hiệu suất và khả năng mở rộng lâu dài.

• Một hệ thống có thể chạy mượt mà khi mới ra mắt. Nhưng liệu nó có đủ khả năng đáp ứng khi lượng người dùng tăng dần theo thời gian?

• Nếu không tối ưu ngay từ đầu, việc xử lý các vấn đề về hiệu suất sau này có thể trở nên khó khăn và tốn kém.

Một số vấn đề dễ nhận ra bao gồm:

1. Dữ liệu sử dụng nhiều: dữ liệu có lượng request lớn từ client hoặc nội bộ hệ thống, gây tải cao nếu truy vấn nhiều lần như:

• Static resources: Cache ảnh sản phẩm, CSS, JS trên CDN để giảm tải server.

• Product status: Cache trạng thái sản phẩm trong e-commerce để tránh truy vấn DB liên tục.

• Customer data: Cache thông tin user profile để hạn chế đọc từ database.

• Session: Lưu session vào Redis thay vì database để tăng tốc xử lý request.

2. Dữ liệu tốn thời gian để hình thành: Dữ liệu yêu cầu truy vấn phức tạp hoặc tính toán tốn tài nguyên, có thể cache để tái sử dụng như

• Data aggregation: Cache báo cáo tài chính thay vì tính toán real-time.

• AI inference: Cache kết quả dự đoán AI model để tránh chạy lại cùng một request.

• Report generation: Cache báo cáo xuất file Excel/PDF để không phải tạo lại từ đầu.

Cache chính là một trong những giải pháp hiệu quả giúp giải quyết những vấn đề này.

II. Caching Hoạt Động Như Thế Nào?

1. Cache Hit

• Khi dữ liệu đã có trong cache và vẫn hợp lệ, hệ thống sẽ sử dụng ngay mà không cần truy vấn resource.

Quy trình:

1. Client gửi yêu cầu lấy dữ liệu.

2. Hệ thống kiểm tra cache và tìm thấy dữ liệu hợp lệ.

3. Trả về dữ liệu ngay lập tức từ cache.

Ví dụ:

• Người dùng yêu cầu báo cáo thống kê doanh thu → Cache đã có dữ liệu → Trả về ngay mà không truy vấn database.

• Danh sách bài viết ít thay đổi được lưu cache trong 24 giờ → Khi client yêu cầu, hệ thống trả về từ cache.

2. Cache Miss

• Khi dữ liệu không có trong cache hoặc đã hết hạn, hệ thống phải truy vấn database để lấy dữ liệu mới.

Quy trình:

1. Client gửi yêu cầu lấy dữ liệu.

2. Hệ thống kiểm tra cache nhưng không tìm thấy dữ liệu hoặc dữ liệu đã hết hạn.

3. Hệ thống truy vấn database hoặc gọi API để lấy dữ liệu mới.

4. Lưu dữ liệu mới vào cache để sử dụng cho lần sau.

5. Trả về dữ liệu cho client.

Ví dụ:

• Người dùng yêu cầu thông tin sản phẩm chưa nằm trong cache → Truy vấn database → Lưu cache → Trả về dữ liệu.

• Một người dùng mới đăng nhập lần đầu → Dữ liệu profile chưa có trong cache → Truy vấn database → Lưu cache.

3. Data Reference Cache Update (Cập nhật Cache khi Dữ liệu thay đổi)

• Khi dữ liệu trong database thay đổi, cache cần được cập nhật hoặc xóa để đảm bảo dữ liệu không bị lỗi thời.

Quy trình:

1. Một sự kiện xảy ra làm thay đổi dữ liệu trong database (VD: khách đặt lịch, nhân viên cập nhật dịch vụ).

2. Hệ thống xóa cache cũ hoặc cập nhật cache với dữ liệu mới.

3. Yêu cầu tiếp theo từ client sẽ nhận được dữ liệu mới từ cache hoặc database.

1. Xóa cache (Cache Invalidation)

• Cách hoạt động: Khi dữ liệu thay đổi trong database, cache cũ bị xóa đi để đảm bảo lần truy vấn tiếp theo lấy dữ liệu mới từ database.

• Mục đích: Đảm bảo dữ liệu không lỗi thời, nhưng lần truy vấn tiếp theo có thể gây cache miss (truy vấn trực tiếp vào database).

Ví dụ: Admin thay đổi giá sản phẩm → Xóa cache danh sách sản phẩm → Lần truy vấn tiếp theo lấy dữ liệu mới từ database & cập nhật lại cache.

2. Cập nhật cache (Cache Update)

• Cách hoạt động: Khi dữ liệu thay đổi trong database, cache cũng được cập nhật ngay lập tức thay vì xóa.

• Mục đích: Tránh cache miss, giúp hệ thống không cần phải truy vấn lại database trong lần request tiếp theo.

Ví dụ: Khách hàng đặt hàng thành công → Hệ thống cập nhật số lượng tồn kho trong cache ngay lập tức → Lần truy vấn tiếp theo lấy dữ liệu mới từ cache, không cần đọc database.

3. Write-Through Cache

• Cách hoạt động: Mọi thay đổi trong database sẽ được ghi ngay vào cache cùng lúc, tức là dữ liệu trong database và cache luôn đồng nhất.

• Mục đích: Đảm bảo cache luôn có dữ liệu mới, tránh tình trạng cache lỗi thời hoặc bị mất.

Ví dụ: Người dùng thay đổi địa chỉ giao hàng → Hệ thống ghi dữ liệu mới vào cả cache & database đồng thời → Lần truy vấn tiếp theo lấy dữ liệu mới từ cache mà không cần đọc database.

III. Dữ Liệu Nào Nên Được Cache?

1. Dữ liệu tĩnh (Static Data) – Cache dài hạn

Đây là những dữ liệu ít thay đổi, có thể được cache trong thời gian dài để giảm tải truy vấn database.

Ví dụ:

• Danh mục sản phẩm trong một trang thương mại điện tử (VD: Điện thoại, Laptop, Phụ kiện).

• Thẻ bài viết trên blog (VD: Công nghệ, Sức khỏe, Giải trí).

• Tệp tĩnh (VD: image, html, css)

Gợi ý triển khai cache:

• Cache lâu dài (TTL dài hoặc cache vô thời hạn)

• Sử dụng Redis hoặc CDN nếu cần phục vụ nhiều request

2. Dữ liệu bán tĩnh (Semi-Dynamic Data) – Cache ngắn hạn hoặc theo sự kiện

Đây là các dữ liệu thay đổi nhưng không liên tục, có thể cache với thời gian ngắn để giảm truy vấn database mà vẫn đảm bảo độ chính xác.

Ví dụ:

• Danh sách sản phẩm trên trang thương mại điện tử.

• Số lượt xem bài viết/blog (cập nhật sau mỗi vài phút).

• Danh sách bạn bè online.

Gợi ý triển khai cache:

• Cache theo TTL ngắn (5-15 phút)

• Cache theo event: Xóa cache khi có cập nhật

• Ví dụ: Khách đặt lịch mới → Xóa cache lịch hẹn

3. Dữ liệu động (Highly Dynamic Data) – Cache thời gian cực ngắn hoặc theo user session

Dữ liệu thay đổi liên tục, nhưng vẫn có thể tối ưu bằng cache theo từng user hoặc session để giảm tải hệ thống.

Ví dụ:

• Trạng thái đăng nhập (session, token).

• Giỏ hàng của từng user.

Gợi ý triển khai cache:

• Cache rất ngắn hạn (dưới 1 phút).

• Cache theo session hoặc sử dụng WebSocket + cache.

IV. Khi Nào Không Nên Dùng Caching?

Có những loại dữ liệu cần luôn lấy trực tiếp từ database để đảm bảo tính chính xác tuyệt đối.

Không nên cache trong các trường hợp sau

• Thanh toán & hóa đơn – Dữ liệu tài chính cần đảm bảo tính chính xác tuyệt đối.

• Trạng thái đơn hàng/đặt lịch tại thời điểm request – Người dùng cần xem dữ liệu mới nhất, không phải dữ liệu cũ trong cache.

• Dữ liệu bảo mật (thông tin user nhạy cảm) – Tránh cache để đảm bảo an toàn và quyền riêng tư.

Giải pháp nếu không dùng caching

• Không cache hoặc chỉ cache tạm thời theo session của user.

• sử dụng database query tối ưu để đảm bảo hiệu suất mà không cần caching.

IV. Tổng kết

Caching là một hướng giải quyết rất tốt để tối ưu hiệu suất ứng dụng, nhưng Trước khi quyết định sử dụng cache, hãy cân nhắc hệ thống của mình có thực sự cần đến cache bằng các câu hỏi như:

• Dữ liệu có cần được truy cập thường xuyên không?

• Dữ liệu có thay đổi liên tục không?

• Có thể chấp nhận dữ liệu cũ trong một khoảng thời gian ngắn không?

Mình mong bài viết này sẽ giúp bạn có một cách nhìn khả quan và hiểu hơn về cache và đưa ra lựa chọn tối ưu khi nghĩ đến cache cho dự án.