Chiến lược invalidate cache trong ứng dụng

Invalidate cache là một trong những vấn đề khá phức tạp khi phát triển ứng dụng, nếu sai lầm có thể dẫn tới các vấn đề nghiêm trọng liên quan tới hiệu năng của ứng dụng, vì vậy đây là một bài toán khá hóc búa để làm sao hiệu năng vẫn giữ ổn định mà dữ liệu vẫn luôn mới nhất. Trong bài viết này tôi sẽ khai thác một số vấn đề cũng như cách thức để invalidate cache hiệu quả mà vẫn giữ được performance của ứng dụng.

1. Invalidate cache là gì?

Vô hiệu hóa cache (cache invalidation) là quá trình xóa bỏ hoặc cập nhật lại dữ liệu cũ trong bộ nhớ đệm khi dữ liệu gốc đã thay đổi. Mục tiêu là đảm bảo cache chỉ lưu trữ thông tin mới nhất, chính xác, tránh tình trạng người dùng nhận được dữ liệu lỗi thời (stale data).

Vai trò quan trọng của việc vô hiệu hóa cache:

• Giữ cho dữ liệu luôn mới nhất, tránh hiển thị thông tin cũ.
• Đảm bảo tính nhất quán giữa các lớp cache và nguồn dữ liệu gốc.
• Cân bằng giữa hiệu suất cao (tốc độ truy xuất nhanh) và độ chính xác.
• Giảm thiểu lỗi hệ thống hoặc trải nghiệm người dùng bị ảnh hưởng do dữ liệu không đồng bộ.

2. Các cách vô hiệu hóa cache cơ bản

2.1. Xóa ngay lập tức (Purge)

Phương pháp này xóa sạch dữ liệu cache tương ứng với một key, URL hoặc nhóm URL ngay khi dữ liệu mới nhất được cập nhật. Lần truy cập tiếp theo sẽ lấy dữ liệu trực tiếp từ database. Cách này sẽ đảm bảo dữ liệu luôn là mới nhất, tuy nhiên nó sẽ khá nguy hiểm nếu lượt truy cập vào ứng dụng bị tăng đột ngột.

Ví dụ: Một trang tin tức xóa cache của bài viết sau khi chỉnh sửa nội dung quan trọng để người đọc thấy phiên bản mới nhất.

2.2. Làm mới (Refresh)

Không xóa cache cũ mà chủ động lấy dữ liệu mới từ nguồn gốc và cập nhật lại cache. Dữ liệu cũ vẫn tồn tại cho đến khi bị thay thế.

Ví dụ: Website bán hàng làm mới cache trang sản phẩm ngay khi giá khuyến mãi thay đổi.

2.3. Cấm theo quy tắc (Ban)

Xóa cache dựa trên mẫu (pattern) như URL chứa chuỗi nhất định, header, hoặc tag. Tất cả mục khớp quy tắc sẽ bị vô hiệu hóa ngay lập tức.

Ví dụ: Hệ thống quản lý nội dung xóa toàn bộ cache liên quan đến một tag khi tag đó được chỉnh sửa.

3. Các chiến lược vô hiệu hóa cache phổ biến

3.1. Dựa trên thời gian (TTL – Time To Live)

Mỗi mục cache được gán thời hạn sống (TTL), sau khoảng thời gian đó sẽ tự động hết hạn.

Cách hoạt động: Đặt TTL ví dụ 300 giây → sau 5 phút dữ liệu tự hết hạn và lần truy cập sau sẽ tải lại.

Các loại TTL:

• Tuyệt đối: Hết hạn vào thời điểm cố định (ví dụ: 10h sáng ngày mai).
• Tương đối: Đếm ngược từ lúc lưu vào cache.

Lời khuyên:

• Nội dung tĩnh (ảnh, CSS, JS): TTL dài (vài tháng đến 1 năm).
• Nội dung động (tin tức, bài blog): TTL ngắn (vài phút đến vài giờ).
• Thêm yếu tố ngẫu nhiên (jitter) vào TTL để tránh nhiều mục hết hạn cùng lúc gây quá tải nguồn gốc (cache stampede).

3.2. Dựa trên sự kiện (Event-Driven)

Cache được vô hiệu hóa ngay lập tức khi có sự thay đổi dữ liệu (thông qua trigger, message queue, hoặc CDC – Change Data Capture).

Ví dụ: Hệ thống tài chính thời gian thực, mạng xã hội, ứng dụng cộng tác.

3.3. Write-Through (Ghi đồng bộ)

Khi ghi dữ liệu, cập nhật đồng thời cả cache và cơ sở dữ liệu. Đảm bảo tính nhất quán cao.

Ưu điểm: Dữ liệu luôn đồng bộ, đọc nhanh từ cache. Nhược điểm: Ghi chậm hơn do phải chờ cả hai nơi.

Phù hợp: Hệ thống ngân hàng, giao dịch cần tính nhất quán mạnh.

3.4. Write-Around

Chỉ ghi trực tiếp vào cơ sở dữ liệu, bỏ qua cache. Tránh làm cache bị “ô nhiễm” bởi dữ liệu ít được đọc lại.

Ưu điểm: Tiết kiệm bộ nhớ cache. Nhược điểm: Lần đọc đầu tiên sau khi ghi sẽ chậm (cache miss).

3.5. Write-Behind / Write-Back (Ghi không đồng bộ)

Ghi vào cache trước, sau đó cập nhật cơ sở dữ liệu sau (asynchronous). Tốc độ ghi nhanh nhất.

Ưu điểm: Hiệu suất ghi cao, giảm tải database. Nhược điểm: Có rủi ro mất dữ liệu nếu crash, chỉ đảm bảo eventual consistency.

Phù hợp: Hệ thống mạng xã hội có lượng ghi lớn, phân tích dữ liệu.

3.6. Cache-Aside / Lazy Loading (Tải theo nhu cầu)

Ứng dụng tự kiểm tra cache:

1. Có → trả về ngay.
2. Không → lấy từ database → lưu vào cache → trả về.

Ưu điểm: Đơn giản, chỉ cache dữ liệu thực sự được dùng. Nhược điểm: Lần đầu chậm, dễ xảy ra stampede nếu không xử lý tốt.

4. Chính sách loại bỏ dữ liệu khi cache đầy (Eviction Policies)

Khi cache hết chỗ, hệ thống cần quyết định xóa mục nào.

• LRU (Least Recently Used): Xóa mục ít được dùng gần đây nhất. Phù hợp hầu hết ứng dụng web thông thường.
• LFU (Least Frequently Used): Xóa mục ít được truy cập nhất (theo tần suất). Tốt cho hệ thống có nội dung “hot” rõ rệt như CDN, tìm kiếm.
• FIFO (First In First Out): Xóa theo thứ tự cũ nhất trước, đơn giản nhưng không thông minh.
• Random: Chọn ngẫu nhiên, overhead thấp nhưng hiệu quả không ổn định.

5. Một số mẫu nâng cao

• Dựa trên tag: Gắn tag cho nhiều key, xóa hàng loạt theo tag (rất hữu ích cho CMS, e-commerce).
• Dựa trên phụ thuộc: Xây dựng cây phụ thuộc, thay đổi cha → tự động xóa con.
• Dựa trên phiên bản: Mỗi dữ liệu có version/timestamp, nếu không khớp thì làm mới.

6. Chiến lược làm nóng cache (Cache Warming)

• Làm nóng trước khi deploy.
• Làm nóng theo lịch định kỳ.
• Làm nóng dựa trên sự kiện.
• Làm nóng JIT (cache thêm dữ liệu liên quan khi miss).

7. Xử lý tình trạng Cache Stampede (Thundering Herd)

Khi nhiều request cùng lúc thấy cache hết hạn → cùng tải lại từ nguồn → quá tải.

Giải pháp:

• Khóa (mutex/lock) → chỉ 1 request tải, các request khác chờ.
• Stale-while-revalidate: Trả dữ liệu cũ trong khi làm mới nền.
• Thêm jitter vào TTL.
• Làm mới chủ động trước khi hết hạn.

8. Vô hiệu hóa ở nhiều lớp cache

• CDN: Purge theo path, tag, khu vực.
• Database cache: Dùng transaction, change stream.
• Microservices: Event bus, API invalidate, cache chung.

Theo dõi: Hit rate (mục tiêu 85–95%), miss rate, latency, invalidation frequency.

9. Lời khuyên thực tế & lỗi thường gặp

Nên làm:

• Luôn đặt TTL an toàn.
• Cho phép trả dữ liệu cũ khi backend lỗi (graceful degradation).
• Theo dõi hit rate thường xuyên.
• Chọn mức độ chi tiết invalidate phù hợp.

Tránh:

• Xóa quá nhiều → lãng phí hiệu suất.
• Xóa không đủ → dữ liệu cũ gây hại.
• Bỏ qua hệ thống phân tán.
• Không xử lý stampede.
• Bỏ sót trigger invalidate ở một số code path.

10. Ví dụ thực tế

• Thương mại điện tử: Tag-based cho catalog, write-through cho giá, TTL cho gợi ý sản phẩm.
• Mạng xã hội: Write-behind cho feed, event-driven cho update realtime, LRU/LFU kết hợp.
• Tài chính: Write-through + dependency cho số dư, order book.
• Quản lý nội dung: Tag + scheduled warming cho bài hot, event cho tin nóng.

Hy vọng phiên bản này hữu ích cho bạn!