Khi bắt đầu triển khai cache vào hệ thống thực tế, một câu hỏi mới xuất hiện:
Nếu dữ liệu đã nằm trong cache, ứng dụng sẽ đọc và ghi dữ liệu như thế nào?
Nghe có vẻ đơn giản, nhưng đây chính là nơi xuất hiện hàng loạt chiến lược caching khác nhau.
Mỗi chiến lược đều cố gắng cân bằng giữa ba yếu tố:
Hiệu năng
Tính nhất quán dữ liệu
Độ phức tạp khi triển khai
Không có chiến lược nào tốt nhất cho mọi hệ thống. Điều quan trọng là hiểu cách chúng hoạt động để lựa chọn phù hợp với bài toán của mình.
Application Managed Cache
Đặc điểm:
Application chịu trách nhiệm quản lý việc đọc và ghi giữa Cache và Database.
Đây là mô hình phổ biến nhất trong các hệ thống hiện nay vì đơn giản và dễ triển khai.
Cache Aside + Cache Invalidation
Đây là cặp chiến lược thường được sử dụng cùng nhau.
Cache Aside
Khi cache hit:
Trả thẳng dữ liệu có từ cache
Khi cache miss:
Ứng dụng đọc từ Database
Đưa dữ liệu vào Cache
Trả kết quả về cho người dùng
Cache Invalidation
Khi nào cần ghi mới dữ liệu vào cache
Những thành phần phần cấu hình nên dữ liệu này đã được thay đổi
Khi phần dữ liệu được cache không còn do đã bị xoá hoặc đã hết hạn
Khi ghi đạt vào trong 2 điều kiện trên :
Cache không được cập nhật ngay.
Dữ liệu chỉ được đưa vào Cache khi có nhu cầu đọc sau đó.
Ví dụ
User cập nhật hồ sơ:
Cập nhập profile customer ở disk database
Xóa cache liên quan đến hồ sơ vừa được cập nhật
Lần request profile tiếp theo phát hiện cache Miss
Query dữ liệu từ disk và load lại vào cache.
Ưu điểm
Đơn giản, dễ triển khai ở bất kỳ đâu trong toàn bộ logic của dự án
Chỉ cache dữ liệu thực sự được sử dụng ở những chỗ cần thiết
Giảm dung lượng cache sử dụng vì chỉ những dữ liệu thực sự được truy cập mới được đưa vào cache.
Nhược điểm
Cache miss đầu tiên luôn phải truy cập Database
Read đầu tiên sau cache Miss sẽ take time nếu là api cần xử lý lâu
Dễ gặp Cache Stampede (Nhiều request cùng lúc gặp Cache Miss và đồng thời truy vấn Database)
Khó quản lý các luồng đọc/ghi cache khi triển khai rải rác khắp source
Phù hợp
Product Catalog
User Profile
CMS
Hầu hết hệ thống CRUD
Dữ liệu ghi nhiều nhưng không phải lúc nào cũng được đọc
Cache Layer Managed Cache
Cache Loader / Data Source Adapter sẽ được Cache layer được cấu hình trước.
Toàn bộ trách nhiệm đọc và ghi được giao cho Cache Layer.
Cách tiếp cận này thường xuất hiện trong các hệ thống lớn hoặc nền tảng có nhiều service dùng chung dữ liệu.
Luồng đọc (Read Through)
Khi cache miss:
Cache Layer tự động lấy dữ liệu từ Database
Tự cập nhật Cache
Trả kết quả cho Application
Application không cần biết dữ liệu đến từ đâu.
Luồng ghi (Write Through)
Khi ghi dữ liệu:
Application
|
v
Cache Layer
|
+--> Cache
|
+--> Database
Sau khi ghi:
Cache = New Value
DB = New Value
Ví dụ
Application cập nhật giá sản phẩm:
Update Product Price
|
v
Cache Layer
|
+----+----+
| |
Cache Database
Kết quả:
Cache = 100$
DB = 100$
Lần đọc tiếp theo:
Read Product Price
|
v
Cache Hit
Ưu điểm
Logic cache được tập trung vào một chỗ
Application đơn giản hơn
Cache và Database được cập nhật trong cùng luồng ghi nên độ nhất quán rất cao.
Read sau Write thường là Cache Hit
Dễ quản lý khi có nhiều service
Nhược điểm
Cần Cache Provider hoặc Cache Loader
Triển khai phức tạp hơn
Mỗi lần ghi phải cập nhật cả Cache và Database, làm tăng độ trễ ghi và số lượng thao tác I/O.
Phù hợp
Hệ thống lớn
Microservices
Pricing Service
Product Information
Metadata Service
Nhiều service cùng truy cập dữ liệu
Tối ưu hiệu năng khi write
Hai nhóm phía trên tập trung vào tính nhất quán dữ liệu.
Một số hệ thống chấp nhận đánh đổi tính nhất quán để đổi lấy tốc độ ghi.
Write Behind (Write Back)
Ghi vào Cache trước, Database cập nhật sau.
Ưu điểm
Tốc độ ghi cực nhanh
Giảm tải Database
Hỗ trợ batch write hiệu quả
Nhược điểm
Eventual Consistency
Nguy cơ mất dữ liệu khi hệ thống gặp sự cố
Khó xử lý rollback
Phù hợp
Like Counter
View Counter
Analytics
Logging
Telemetry
Không phù hợp
Thanh toán
Số dư tài khoản
Giao dịch tài chính
Inventory thời gian thực
Định kỳ làm mới dữ liệu
Refresh Ahead : Làm sao giảm Cache Miss?
Thường chỉ áp dụng cho các dữ liệu được truy cập thường xuyên hoặc có giá trị cao.
Thông thường:
TTL = 10 phút
10:00 Cache Expired
10:01 User Request
10:01 Database Query
Người dùng đầu tiên sau khi cache hết hạn sẽ phải chờ Database.
Refresh Ahead chủ động làm mới dữ liệu trước khi cache hết hạn.
TTL còn 10%
|
v
Background Job
|
v
Refresh Cache
Kết quả:
Cache luôn nóng
Giảm Cache Miss
Latency ổn định hơn
Phù hợp
Homepage
Trending Products
Dashboard
Configuration Data
Frequently Accessed Data