Bài 5: Caching — Cache-Aside, TTL & Vô Hiệu Hoá

Bài 4 dựng xong tầng vào. Từ bài này trở đi ta đi vào phía sau nó, và thứ đầu tiên gặp là tầng có tỉ lệ lợi ích trên công sức cao nhất trong toàn bộ series: cache. Lab của bài này đo được 26,5 lần throughput và p99 giảm 20 lần chỉ bằng cách bật cache cho một key nóng.

Nhưng phần đáng học không nằm ở con số đó — nó quá dễ đoán. Ba điều bất ngờ hơn: hạ hit ratio từ 99,45% xuống 95,47% (chỉ bốn điểm phần trăm) làm p99 nhảy từ 4,46 ms lên 42,11 ms trong khi p50 gần như không đổi; single-flight — cách chống thundering herd kinh điển — làm p50 và p99 tệ hơn một chút chứ không tốt hơn; và jitter cho TTL không giảm một truy vấn database nào nhưng vẫn tăng 31% throughput.

5.1 Vì sao cache thắng, và thắng bao nhiêu

Bài 1 đã dựng bảng bậc độ lớn latency. Chỗ cache khai thác chính là khoảng cách giữa hai dòng trong bảng đó: đọc từ RAM tính bằng trăm nanosecond, còn một truy vấn database qua mạng tính bằng millisecond — chênh nhau khoảng 10.000 lần. Cache không làm database nhanh hơn; nó làm cho phần lớn request không phải hỏi database.

Độ trễ trung bình của một tầng có cache:

$$T = h \cdot T_{cache} + (1-h) \cdot T_{db}$$

với $h$ là hit ratio. Thay số của lab ($T_{cache} \approx 1{,}4$ ms, $T_{db} \approx 43$ ms) thì $h = 0{,}9$ cho $T \approx 5{,}6$ ms, còn $h = 0{,}99$ cho $T \approx 1{,}8$ ms. Nhưng công thức này che mất phần quan trọng hơn. Số truy vấn database mà hệ thống tạo ra là:

$$Q = (1-h) \cdot N$$

Nghĩa là tải database phụ thuộc vào $(1-h)$ — phần chưa hit. Đi từ $h = 90\%$ lên $h = 99\%$ nghe như "cải thiện 9 điểm", nhưng $(1-h)$ đi từ $0{,}1$ xuống $0{,}01$: tải database giảm 10 lần. Thêm một số 9 nữa, lên $99{,}9\%$, lại chia 10 lần nữa. Mỗi số 9 thêm vào là một lần chia 10 tải database.

Đây không phải suy luận trên giấy. Mình sweep kích thước tập dữ liệu làm việc (số key khác nhau mà tải chạm tới) và đo hit ratio cùng số truy vấn database thật:

Cột thứ ba khớp với công thức đến từng chữ số: $1 - 0{,}9992 = 0{,}0008$, $1 - 0{,}9547 = 0{,}0453$, $1 - 0{,}2380 = 0{,}7620$. Công thức $Q = (1-h) \cdot N$ không phải xấp xỉ — nó là định nghĩa của hit ratio viết theo cách khác.

Nhưng dòng gây bất ngờ là dòng thứ ba. Từ 99,45% xuống 95,47% chỉ là bốn điểm phần trăm, và p50 thậm chí không đổi (1,54 → 1,48 ms). Trong khi đó p99 nhảy từ 4,46 ms lên 42,11 ms — gấp 9,4 lần. Đúng bài học của Bài 1: giá trị trung bình che mất đuôi, và đuôi là chỗ người dùng cảm nhận.

5.2 Các mẫu cache: ai ghi vào đâu, theo thứ tự nào

Mọi mẫu cache đều trả lời hai câu hỏi: ai chịu trách nhiệm nạp cache khi miss, và khi ghi dữ liệu thì ghi vào cache hay database trước. Khác biệt giữa các mẫu chỉ nằm ở đó.

Cache-aside trong lab, đúng như mã đang chạy:

const cacheKey = `demo:${key}`;

let hit = null;
try {
  hit = await redis.cmd('GET', cacheKey);
} catch {
  // IMPORTANT: if Redis is down, the app must still serve the request. The cache is
  // a SPEED-UP, not a hard dependency. Catching the error here is exactly the
  // difference between "the system got slower" and "the system fell over" (Lesson 17).
  hit = null;
}
if (hit !== null) {
  cacheHits++;
  return json(res, 200, { ...JSON.parse(hit), from: 'cache' });
}

cacheMisses++;
const fresh = await readFromDb(key);
try {
  // SET ... EX: always set a TTL. A key with no TTL lives forever, and by the time
  // the underlying data changes nobody remembers where to delete it from.
  await redis.cmd('SET', cacheKey, JSON.stringify(fresh), 'EX', String(ttl));
} catch {
  // Couldn't write the cache — ignore it, don't fail the request over that.
}
return json(res, 200, fresh);

5.3 Vô hiệu hoá cache — phần khó nhất

Nạp cache thì dễ. Câu hỏi khó là: khi dữ liệu gốc đổi, làm sao bản trong cache biết mà bỏ đi? Ba cách, theo thứ tự từ đơn giản tới sạch nhất:

Key có version thường là lời giải sạch nhất, vì nó biến một bài toán đồng bộ (xoá đúng lúc, đúng chỗ) thành bài toán đặt tên:

// EXPLICIT DELETE: you have to remember every related key. Miss one line and you get
// the bug "I fixed it but the page still shows the old number" — a bug that's very
// hard to reproduce.
async function updateProductOld(id, data) {
  await db.update(id, data);
  await redis.del(`product:${id}`);
  await redis.del(`product:${id}:reviews`);
  await redis.del(`category:${data.categoryId}:products`);   // easy to forget this line...
  await redis.del(`search:featured`);                        // ...and this one
}

// VERSIONED KEY: delete nothing. Bump the version, and EVERY derived key changes with
// it. Old keys turn into garbage nobody reads, and vanish on their own once their TTL
// expires or they get evicted.
async function updateProductNew(id, data) {
  await db.update(id, data);
  // INCR is atomic in Redis => safe even when multiple replicas write at once.
  await redis.cmd('INCR', `ver:product:${id}`);
}

async function readProduct(id) {
  const v = (await redis.cmd('GET', `ver:product:${id}`)) || '0';
  return cacheAside(`product:${id}:v${v}`, () => db.read(id));
}

TTL đồng loạt và tác dụng của jitter

Nếu nhiều key được nạp gần như cùng lúc — chuyện xảy ra mỗi lần deploy, mỗi lần cache bị flush, mỗi lần scale thêm replica — và tất cả dùng cùng một TTL, chúng sẽ hết hạn thành từng đợt. Cách chữa là cộng thêm một lượng ngẫu nhiên vào TTL:

// TTL 5s with jitter 0.6 => every key gets a random TTL somewhere in [2s, 8s].
// The expected value is still 5s, but the expiry moments get SPREAD OUT instead of
// piling up at one point.
function ttlWithJitter(baseSec, ratio) {
  if (!(ratio > 0)) return baseSec;
  const delta = baseSec * ratio * (Math.random() * 2 - 1);
  return Math.max(1, Math.round(baseSec + delta));
}

Đo thật: 300 key, TTL cơ sở 5 giây, 32 kết nối, 30 giây, pool database 2 kết nối mỗi replica, single-flight đã bật ở cả hai cấu hình, ba lần lặp mỗi cấu hình:

Throughput tăng 31% và thời gian chờ hàng đợi database giảm gần một nửa. Nhưng hãy để ý dòng cuối: số truy vấn database trên mỗi request gần như y hệt (0,0105 so với 0,0102). Jitter không hề giảm khối lượng công việc — nó chỉ rải công việc đó ra theo thời gian. Hàng đợi ngắn hơn không phải vì có ít việc hơn, mà vì việc không còn đến cùng một lúc.

5.4 Thundering herd — và một số đo phản trực giác

Một key nóng hết hạn. Ngay lúc đó có $N$ request đang cùng hỏi nó. Cả $N$ đều thấy miss, cả $N$ đều gọi database. Database nhận cùng lúc $N$ truy vấn giống nhau cho đúng một dữ liệu — đó là thundering herd (hay cache stampede).

Trường hợp tệ nhất là vòng lặp tự đóng: herd làm database quá tải, quá tải làm request chậm, chậm nên không ai kịp ghi lại cache, cache trống nên đợt request tiếp theo lại thành một herd nữa. Hệ thống không tự hồi phục được dù nguyên nhân ban đầu chỉ là một key hết hạn.

Lần đo đầu không thấy gì cả

Mình dựng thí nghiệm: một key nóng, TTL 1 giây, 100 kết nối, 15 giây. Không bật single-flight thì có 1.600 truy vấn database; bật lên thì còn 54 — ít hơn 30 lần. Nhưng latency không đổi gì cả: p50, p95, p99 của hai cấu hình trùng nhau trong khoảng biến động.

Lý do: "database" của lab lúc đó có pool 10 kết nối mỗi replica, tức 30 truy vấn đồng thời, mỗi truy vấn 40 ms — sức chứa khoảng 750 truy vấn/giây. Herd tạo ra chừng 89 truy vấn mỗi lần hết hạn. Nó chưa hề đụng tới giới hạn. Herd có thật, đo được bằng số truy vấn, nhưng chưa gây hậu quả.

Nên mình thu pool xuống 2 kết nối mỗi replica — một database đang căng, chuyện rất bình thường lúc có sự cố. Cùng thí nghiệm, ba lần lặp:

Một điều cần giải thích trước khi đọc tiếp: số truy vấn database ở cột "Không single-flight" (1.100) thấp hơn con số 1.600 đo được ở thí nghiệm pool=10 phía trên, dù cùng một kịch bản herd. Đây không phải vì herd nhỏ đi — bộ đo tải chạy kiểu đóng (đã học ở Bài 2): mỗi kết nối chỉ gửi request kế tiếp sau khi nhận phản hồi, nên khi pool hẹp làm mỗi request chờ lâu hơn, cùng 15 giây đó có ít request hoàn tất hơn, kéo theo ít lần miss và ít truy vấn database hơn. Hai con số 1.600 và 1.100 đến từ hai thí nghiệm khác pool, không phải cùng một phép đo.

Đọc kỹ bảng này. Single-flight giảm truy vấn database 20 lần, xoá sạch hàng đợi (sâu 33 xuống 0, chờ 312 ms xuống 0), và cắt độ trễ lớn nhất từ ~730 ms xuống ~66 ms — 11 lần.

Nhưng p50 và p99 lại tệ hơn một chút: p50 từ 5,00 lên 5,57 ms, p99 từ 13,17 lên 14,02 ms. Nếu mình chỉ đo p50 và p99 — đúng hai số liệu mà hầu hết dashboard hiển thị — thì kết luận sẽ là "single-flight không giúp gì, thậm chí hơi hại", và mình đã bỏ nó đi.

Bản cài đặt single-flight, chính là mã đang chạy trong lab:

const inFlightLoads = new Map();

function singleFlight(key, loader) {
  const pending = inFlightLoads.get(key);
  if (pending) return pending;              // join the load that's already in flight

  // MUST delete from the map inside `finally`. Otherwise one failure leaves the key
  // stuck forever with a rejected promise, and EVERY later request gets that same error.
  const promise = loader().finally(() => inFlightLoads.delete(key));
  inFlightLoads.set(key, promise);
  return promise;
}

// Used on the read path:
const fresh = useSingleFlight
  ? await singleFlight(cacheKey, load)
  : await load();

Ba cơ chế chống herd, và điều kiện dùng của từng cái:

Hai cơ chế đầu chống hai vấn đề khác nhau và không thay thế được nhau — đó là lý do lab bật cả hai cùng lúc trong phép đo jitter ở mục 5.3.

5.5 Eviction và thiết kế cache key

Cache luôn nhỏ hơn dữ liệu gốc, nên luôn có lúc phải bỏ bớt. Redis quyết định bỏ cái nào bằng maxmemory-policy, và lựa chọn này thay đổi hành vi hệ thống nhiều hơn vẻ ngoài của nó:

Redis trong lab cố tình đặt maxmemory 64mb với allkeys-lru để bạn tự gây ra eviction và quan sát. Khi hết bộ nhớ, INFO stats cho biết bao nhiêu key đã bị bỏ:

docker compose --profile cache up -d

# Push a very large key space to blow past 64mb, then see how many keys Redis dropped
docker compose run --rm loadgen loadgen.js \
  --url "http://lb:8080/cached?ttl=300" -c 32 -d 20 --key-space 200000

docker compose exec redis redis-cli INFO stats | grep evicted_keys
docker compose exec redis redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human'

# Key count and hit ratio as seen by Redis itself (different from the app-side hit ratio)
docker compose exec redis redis-cli DBSIZE
docker compose exec redis redis-cli INFO stats | grep keyspace

Key thiết kế sai làm cache vô dụng

Cạm bẫy tốn kém nhất trong bài này không phải chọn sai chính sách eviction mà là đặt key sai. Nếu key chứa thứ thay đổi theo từng request, mỗi request tạo ra một key mới: cache ghi liên tục, không bao giờ đọc lại được gì, hit ratio gần 0 — và nó vẫn "hoạt động", không báo lỗi gì cả.

// ===== BAD: a new key on every request, hit ratio ~ 0 =====
`page:${req.url}`                     // includes ?utm_source=... => each share creates a new key
`user:${id}:${Date.now()}`            // timestamp => never matches
`search:${JSON.stringify(filters)}`   // property order varies => key differs for the same filters
`cart:${sessionId}`                   // one key per session => the cache serves exactly one person

// ===== GOOD: keep only what ACTUALLY decides the result =====
const CACHE_PARAMS = ['page', 'sort', 'category'];   // allowlist, not a blocklist

function cacheKeyFor(url) {
  const u = new URL(url, 'http://x');
  const parts = CACHE_PARAMS
    .filter((k) => u.searchParams.has(k))
    .sort()                                    // SORT: ?a=1&b=2 and ?b=2&a=1 must map to the same key
    .map((k) => `${k}=${u.searchParams.get(k)}`);
  return `page:${u.pathname}|${parts.join('&')}`;
}

// cacheKeyFor('/products?utm_source=fb&sort=price&page=2')
//   -> 'page:/products|page=2&sort=price'      utm_* dropped, order normalized

Hai vấn đề còn lại đáng biết tên. Hot key: một key được truy cập quá nhiều làm lệch tải một shard Redis — mọi shard khác rảnh, một shard quá tải; cách chữa là nhân bản key đó thành vài bản (hot:v1#0…hot:v1#7) rồi chọn ngẫu nhiên khi đọc. Cache pollution: một tác vụ quét dữ liệu lạnh (báo cáo, backup, con bot) đẩy hết dữ liệu nóng ra khỏi cache — LFU chịu đựng chuyện này tốt hơn LRU, hoặc tách hẳn tác vụ quét sang đường không đi qua cache.

Tự làm lại các phép đo

cd blog/sysdesign/sysdesign-lab
docker compose --profile cache up -d

# --- Section 5.1: no cache vs. a hot cache ---
docker compose exec redis redis-cli flushall && ./tools/cache-stats.sh reset
docker compose run --rm loadgen loadgen.js --url "http://lb:8080/uncached?key=hot" -c 32 -d 10 -w 3 --json
./tools/cache-stats.sh

docker compose exec redis redis-cli flushall && ./tools/cache-stats.sh reset
docker compose run --rm loadgen loadgen.js --url "http://lb:8080/cached?key=hot&ttl=300" -c 32 -d 10 -w 3 --json
./tools/cache-stats.sh

# --- Section 5.4: thundering herd. MUST shrink the DB pool to 2 first, otherwise you
# --- will see exactly the surprise I ran into: 30x more queries with latency unchanged.
# Change DB_MAX_CONCURRENCY to '2' in docker-compose.yml, then:
docker compose --profile cache up -d --force-recreate app1 app2 app3

docker compose exec redis redis-cli flushall && ./tools/cache-stats.sh reset
docker compose run --rm loadgen loadgen.js --url "http://lb:8080/cached?key=hot&ttl=1" -c 100 -d 15 -w 3 --json
./tools/cache-stats.sh                    # check dbQueries + queue depth

docker compose exec redis redis-cli flushall && ./tools/cache-stats.sh reset
docker compose run --rm loadgen loadgen.js --url "http://lb:8080/cached?key=hot&ttl=1&flight=single" -c 100 -d 15 -w 3 --json
./tools/cache-stats.sh                    # compare: dbQueries, qDepth, and the MAX latency

Tóm lại

Tải database tỉ lệ với $(1-h)$, nên mỗi số 9 thêm vào hit ratio là một lần chia 10 tải — và toàn bộ giá trị nằm ở những số 9 cuối cùng, không phải ở việc đi từ 0% lên 90%. Cache-aside là mặc định vì nó là mẫu duy nhất mà cache sập thì hệ thống chỉ chậm đi. Vô hiệu hoá cache là phần khó nhất, và key có version thường là lời giải sạch nhất vì nó làm cuộc đua ghi trở nên vô hại thay vì cố ngăn cuộc đua.

Nhưng bài học lớn nhất của bài này là về cách đo. Ba lần trong quá trình viết, số liệu nói ngược điều mình chờ đợi, và cả ba lần nguyên nhân là phép đo chứ không phải cơ chế: jitter "không có tác dụng" vì hệ thống nghẽn suốt nên không có đợt nào để làm phẳng; thundering herd "không gây hại" vì pool database rộng gấp nhiều lần herd; single-flight "làm chậm hơn" vì p50 và p99 không chứa nhóm 0,39% bị hại. Trong cả ba, số liệu đúng — câu hỏi mới là cái sai.

Bài 6 mang đúng ý tưởng này ra xa hơn nữa — tới tầng edge, cạnh người dùng — nơi giới hạn không còn là CPU hay bộ nhớ mà là tốc độ ánh sáng, và nơi một lỗi cấu hình cache key làm tải origin tăng 251 lần mà không một số liệu nào phía client thay đổi.