Bagaimana anda cache untuk memotong beban DB pada jutaan permintaan/minit?

Question

IT Interview Practice · Accepted Answer

Letak lapisan **cache-aside** (Redis/Memcached) di hadapan DB supaya bacaan mengenai memori, beri entri satu **TTL** dan **invalidasi pada penulisan**, tambah **perlindungan stampede** supaya key sejuk tidak boleh melepaskan thundering herd ke atas DB, dan sebarkan **hot key** merentas replica supaya satu key popular tidak mencairkan satu node.

```text
                 ┌── hit ──▶ return value
request ──▶ cache│
                 └── miss ─▶ lock ─▶ DB read ─▶ set(TTL) ─▶ return
                              │
                    (only ONE miss populates; others wait)
DB writes ──▶ invalidate/update key
```

## Cache-aside vs read-through

Dalam **cache-aside** app menyemak cache; pada miss ia membaca DB dan mengisi cache sendiri. Dalam **read-through** library cache melakukannya untuk anda. Kedua-dua cara matlamatnya sama: menukar query DB 5ms menjadi carian memori 0.2ms, jadi cache dengan kadar hit 95% memotong trafik bacaan DB **20×**. Pada jutaan permintaan/minit DB sekadar tidak boleh menyajikan setiap bacaan — cache-lah yang menjadikan nombor itu berfungsi.

## TTL + invalidasi

Dua cara untuk mengekalkan cache segar, dan anda biasanya memerlukan kedua-duanya. **TTL** membataskan kebasian — sebuah entri luput selepas N saat jadi data salah sembuh sendiri. **Invalidasi eksplisit** memadam/mengemas kini key pada penulisan untuk ketepatan yang tidak boleh menunggu TTL. Pepijat klasik ialah cache tanpa invalidasi dan menyajikan data basi selama beberapa minit; yang lebih halus ialah invalidasi *dan* set dalam penulisan yang sama, yang berlumba (races).

## Perlindungan stampede & hot key

- **Stampede (thundering herd):** apabila hot key luput, beribu miss serentak semuanya mengenai DB serta-merta dan boleh menumbangkannya. Baiki dengan **lock/single-flight per-key** (hanya satu permintaan mengira semula, yang lain menunggu) atau **refresh awal/kebarangkalian** sebelum tamat tempoh.
- **Hot key:** satu key (profil selebriti) boleh menepu CPU/rangkaian satu node Redis. Sebarkan ia — replikasi key merentas node, atau tambah cache in-process setempat kecil di hadapan Redis untuk item terpanas.

## Perspektif temu duga

Penemu duga mahu melihat anda berfikir melepasi "tambah Redis". Baik: cache-aside dengan TTL. Hebat: anda menyebut **perlindungan stampede, strategi invalidasi, pengendalian hot-key, dan apa yang berlaku pada gangguan cache**. Perangkapnya ialah menganggap cache sentiasa hidup — jika Redis mati dan setiap miss jatuh ke DB, anda mendapat **cache-avalanche** yang menumbangkan DB juga.

## Pertukaran & mod kegagalan

- **Kebasian vs beban:** TTL pendek = segar tetapi lebih banyak miss; TTL panjang = kurang miss tetapi lebih basi. Tala setiap data.
- **Cache avalanche:** banyak key luput bersama (TTL sama) menyebabkan lonjakan beban — **jitter** TTL.
- **Konsistensi:** cache dan DB boleh menyimpang; untuk bacaan kritikal-wang, baca DB atau guna write-through.
- **Pengusiran memori (eviction):** di bawah tekanan Redis mengusir mengikut polisi (LRU/LFU); polisi yang salah secara senyap menggugurkan set panas anda.

Cache-aside vs read-through

TTL + invalidasi

Perlindungan stampede & hot key

Perspektif temu duga

Pertukaran & mod kegagalan

Soalan berkaitan