Cache & CDN (Content Delivery Network — mạng phân phối nội dung) giúp giảm số request phải quay về origin — máy chủ gốc, rút ngắn thời gian phản hồi và giảm tải hạ tầng. Nhưng cache chỉ hữu ích khi quy tắc cache đúng: cache nhầm nội dung động, cơ chế làm mất hiệu lực cache (invalidation) sai hoặc số lần cache không có bản phù hợp tăng đột biến có thể gây dữ liệu cũ, lỗi session/checkout hoặc làm origin quá tải.
Tóm tắt: Khi audit cache/CDN, đọc cùng HIT/MISS/BYPASS → cache key → TTL/revalidation → purge/invalidation → origin latency → critical journey. HIT nghĩa là có bản cache dùng được; MISS là phải lấy lại từ origin; BYPASS là cố ý bỏ qua cache. Mục tiêu không phải tỷ lệ HIT cao nhất mà là phản hồi đúng, nhanh và có thể phục hồi khi cache thay đổi.
Hiểu HIT, MISS, BYPASS và cách CDN phục vụ nội dung
Cache lưu bản sao để tránh tính toán hoặc tải lại nội dung; CDN phân phối nội dung từ máy chủ biên (edge) gần người dùng hơn và thường tích hợp cache. Request động hoặc không phù hợp để cache vẫn có thể phải quay về origin.
| Trạng thái | Ý nghĩa vận hành | Không nên suy diễn |
|---|---|---|
| HIT | Response được phục vụ từ cache. | HIT cao không chứng minh response đang đúng. |
| MISS | Không có bản phù hợp; origin phải trả response. | Một MISS không chứng minh cache lỗi. |
| BYPASS/DYNAMIC | Request không được cache theo rule hoặc tính chất nội dung. | BYPASS có thể là chủ đích cho nội dung động. |
| REVALIDATED/UPDATING | Cache đang xác minh hoặc làm mới nội dung. | Cần đọc cùng TTL, header và behavior của origin. |
Tỷ lệ cache HIT chỉ có ý nghĩa khi người dùng nhận đúng nội dung. Một trang cá nhân hóa hoặc checkout bị cache nhầm có thể “nhanh” nhưng là lỗi chức năng nghiêm trọng.
Cache key, TTL và phạm vi cache quyết định tính đúng
Cache key là tập thông tin dùng để quyết định hai request có thể dùng chung một bản cache hay không. Key có thể phụ thuộc host, path, query string, cookie/header cần thiết hoặc biến thể ngôn ngữ/thiết bị nếu chúng thực sự làm output khác nhau. Key quá chi tiết làm hit ratio giảm; key quá rộng có thể trộn response không nên dùng chung.
TTL (Time To Live — thời gian một bản cache được giữ trước khi hết hạn) quá dài có thể giữ nội dung cũ; quá ngắn làm origin bị gọi nhiều. Khi dữ liệu thay đổi, purge là chủ động xóa bản cache và revalidation là xác minh lại bản cache với nguồn. Các thao tác này phải khớp phạm vi thay đổi. Không nên purge toàn bộ cache sau mọi chỉnh sửa vì có thể tạo một đợt request đồng thời quay về origin.
| Nhóm URL | Hướng xử lý |
|---|---|
| Static asset/public content | Có thể cache mạnh hơn nếu versioning/invalidation rõ. |
| Login/account | Thận trọng với cookie/session và dữ liệu cá nhân. |
| Cart/checkout | Không áp “cache everything”; xác minh hành vi theo application. |
| Search/filter động | Kiểm tra query, biến thể và yêu cầu freshness trước khi cache. |
| Admin/API cá nhân hóa | Ưu tiên tính đúng, xác thực và privacy trước hit ratio. |
Khi cache gây hoặc che tình trạng suy giảm hiệu năng
Khi MISS/BYPASS tăng sau deploy, rule change hoặc purge, nhiều request quay về application/database. Nếu origin thiếu headroom — phần năng lực dự phòng — CPU, worker, DB connection và latency có thể tăng theo chuỗi. Khi website chậm bất thường, xem Performance Degradation và đối chiếu thời điểm cache thay đổi với tài nguyên và tỷ lệ lỗi.
Ngược lại, HIT cao có thể che một backend vốn chậm. Khi cache cold, purge hoặc traffic chuyển sang URL động, bottleneck mới lộ ra. Nếu CPU/worker/database tiến gần giới hạn, xem Resource Saturation. Nếu query/connection là điểm nghẽn chính, đi sâu tại Database Performance.
Quy trình triage và thay đổi cache/CDN an toàn
- Khóa dòng thời gian: deploy, purge, cache-rule change, traffic spike và thời điểm latency/error bắt đầu.
- Phân nhóm URL: URL nào HIT/MISS/BYPASS và critical journey nào bị ảnh hưởng?
- Kiểm tra tính đúng: response có đúng user/session/version không trước khi tối ưu hit ratio?
- Đối chiếu origin: origin latency, request volume, CPU/worker/database và 5xx có tăng cùng MISS không?
- Thay đổi có phạm vi: ưu tiên purge/rule change nhỏ nhất đủ giải quyết vấn đề.
- Xác minh: kiểm tra response, cache status, critical journey và origin load sau change.
- Rollback: có cách khôi phục rule trước nếu behavior xấu đi.
Monitoring nên theo dõi HIT/MISS/BYPASS theo URL group, thời gian phản hồi/lưu lượng ở origin, sự kiện purge/revalidation, lỗi 5xx ở edge/origin và cache-rule change. Xem thêm Website Monitoring.
Warm cache, cold cache và Capacity Planning
Warm cache là trạng thái phần lớn nội dung thường dùng đã có trong cache; cold cache là khi cache còn trống hoặc vừa bị xóa. Test chỉ ở warm cache có thể đánh giá thấp origin load. Nếu cold/partial-cache, purge event hoặc traffic burst là rủi ro thực tế, capacity test nên có kịch bản tương ứng. Không cần cố “đánh sập” production; mục tiêu là biết origin còn headroom bao nhiêu và điều kiện phải dừng test ở đâu.
Phần này liên quan trực tiếp tới Capacity Planning & Load Testing, đặc biệt trước campaign hoặc thay đổi cache/CDN lớn.
Checklist Cache/CDN
- Biết nội dung nào cache được và không cache được.
- Cache key có lý do rõ và không trộn dữ liệu sai.
- TTL/revalidation phù hợp yêu cầu độ mới.
- Purge/invalidation có phạm vi và quy trình.
- Monitoring cache status cùng origin latency/load.
- Login/account/cart/checkout được kiểm tra tính đúng.
- Có test sau thay rule và rollback cấu hình.
Kết luận
Cache/CDN là một lớp của Website Performance & Reliability. Tối ưu đúng không phải đạt hit ratio cao nhất, mà là giảm origin load và latency trong khi vẫn giữ nội dung, session và critical journey chính xác. Một flow vận hành rõ giúp đội ngũ tránh xử lý HIT, TTL, purge và origin như các vấn đề rời rạc.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.
