⛶ bấm để phóng to
Các tầng cache
Cache là bản sao dữ liệu đặt gần nơi cần, để khỏi tính hay lấy lại từ nguồn chậm. Trên đường từ người dùng tới database, có nhiều tầng cache nối tiếp nhau.
Trình duyệt cache file tĩnh. CDN cache nội dung ở rìa mạng gần người dùng. Tầng ứng dụng cache trong bộ nhớ hoặc trong Redis. Bản thân database cũng cache truy vấn hay dùng. Mỗi tầng chặn bớt request, nên nguồn phía sau nhẹ tải. Càng gần người dùng, cache càng nhanh nhưng càng dễ lệch với dữ liệu gốc.
A cache is a copy of data kept near where it is needed, so you avoid recomputing it or fetching it from a slow source. On the path from user to database, several caching layers sit in a row.
The browser caches static files. A CDN caches content at the network edge near the user. The application layer caches in memory or in Redis. The database itself caches frequent queries. Each layer absorbs some requests, so the source behind it stays light. The closer to the user, the faster the cache, but the easier it drifts from the source data.
⛶ bấm để phóng to
Cache-aside và read-through
Cache-aside là cách phổ biến nhất. Ứng dụng hỏi cache trước. Trúng thì trả ngay. Trật thì ứng dụng tự đọc database, ghi vào cache, rồi trả về. Ứng dụng tự quản lý cache, nên rất linh hoạt.
Read-through đẩy việc đó vào lớp cache. Ứng dụng chỉ hỏi cache; khi trật, chính cache đi lấy từ database và lưu lại. Code ứng dụng gọn hơn, nhưng phải dùng thư viện cache hỗ trợ. Cả hai đều giải bài toán đọc nặng, khác nhau ở chỗ ai chịu trách nhiệm nạp cache.
Cache-aside is the most common pattern. The app asks the cache first. On a hit, it returns right away. On a miss, the app reads the database itself, writes it into the cache, then returns it. The app manages the cache, so it is very flexible.
Read-through pushes that job into the cache layer. The app only asks the cache; on a miss, the cache itself fetches from the database and stores it. The app code is cleaner, but you need a cache library that supports it. Both solve heavy reads; they differ in who is responsible for loading the cache.
⛶ bấm để phóng to
Write-through và write-back
Khi ghi dữ liệu, write-through ghi vào cache và database cùng lúc. Cache luôn khớp database, an toàn, nhưng mỗi lần ghi chậm hơn vì phải ghi hai nơi.
Write-back chỉ ghi vào cache trước, báo xong ngay, rồi ghi xuống database sau theo lô. Ghi rất nhanh, nhưng nếu cache chết trước khi kịp ghi xuống thì mất dữ liệu. Còn write-around ghi thẳng database, bỏ qua cache, hợp dữ liệu ít đọc lại. Chọn theo việc anh ưu tiên an toàn hay tốc độ ghi.
On a write, write-through writes to the cache and the database at the same time. The cache always matches the database, which is safe, but each write is slower because it hits two places.
Write-back writes only to the cache first, reports done immediately, then writes down to the database later in batches. Writes are very fast, but if the cache dies before flushing, data is lost. Write-around writes straight to the database, skipping the cache, good for data rarely read again. Choose by whether you value safety or write speed.
⛶ bấm để phóng to
Hết chỗ và dữ liệu cũ
Cache có dung lượng hữu hạn. Khi đầy, nó phải bỏ bớt mục cũ, gọi là eviction. Chính sách hay dùng là LRU (bỏ mục lâu nhất không dùng) và LFU (bỏ mục ít dùng nhất). Mỗi mục cũng nên có TTL, thời gian sống, để tự hết hạn.
Vấn đề khó nhất của cache là invalidation: khi dữ liệu gốc đổi, phải bỏ bản cache cũ kẻo phục vụ dữ liệu sai. Một bẫy kinh điển là thundering herd: một key hot hết hạn cùng lúc, hàng loạt request cùng trượt cache và dồn vào database. Cách chống là hết hạn lệch giờ hoặc khóa nạp lại.
A cache has limited space. When full, it must drop old entries, called eviction. Common policies are LRU (drop the least recently used) and LFU (drop the least frequently used). Each entry should also have a TTL, a time to live, so it expires on its own.
The hardest problem in caching is invalidation: when the source data changes, you must drop the stale copy or you serve wrong data. A classic trap is the thundering herd: one hot key expires at once, many requests all miss the cache and pile onto the database. The fix is to stagger expiry times or lock the reload.
⛶ bấm để phóng to
Redis: cache trong bộ nhớ
Redis là kho key-value chạy trong RAM, nên đọc ghi cực nhanh. Nó là lựa chọn mặc định cho tầng cache ứng dụng, và còn dùng làm hàng đợi, bộ đếm, rate limiter, leaderboard.
Dữ liệu trong RAM mất khi tắt máy, nên Redis có hai cách lưu xuống đĩa. RDB chụp ảnh toàn bộ dữ liệu theo chu kỳ, gọn và phục hồi nhanh, nhưng mất phần dữ liệu giữa hai lần chụp. AOF ghi lại từng lệnh ghi, an toàn hơn, nhưng file lớn và phục hồi chậm hơn. Chọn theo mức chấp nhận mất dữ liệu.
Redis is a key-value store that runs in RAM, so reads and writes are extremely fast. It is the default choice for an application cache layer, and is also used as a queue, counter, rate limiter and leaderboard.
Data in RAM is lost on shutdown, so Redis has two ways to persist to disk. RDB takes a periodic snapshot of all data, compact and fast to restore, but it loses data between snapshots. AOF logs every write command, safer, but the file is larger and restore is slower. Choose by how much data loss you can tolerate.