Bagaimana anda menskala MySQL apabila trafik tumbuh 100x?

Question

IT Interview Practice · Accepted Answer

Skala dalam peringkat: **read replica + caching untuk bacaan dahulu, kemudian sharding (Vitess) untuk penulisan** — dan tambah connection pooling sebelum apa-apa lain, kerana ia 10x yang paling murah. Bacaan dan penulisan menskala secara berbeza, jadi jangan menggapai sharding pada hari pertama.

```text
        ┌─▶ Cache (Redis) ── hit ──▶ return
App ─▶ Pool(PgBouncer/ProxySQL)      miss ▼
        │                    ┌─▶ Read replica 1 ┐
        ├──── reads ─────────┼─▶ Read replica 2 ┼─ (async replication)
        │                    └─▶ Read replica N ┘
        └──── writes ──▶ Primary ──▶ (later) Vitess shards ─▶ Primary A / Primary B
```

## Langkah 0: connection pooling

Setiap MySQL connection memakan memori dan satu thread. Pada trafik 100x anda akan menghabiskan `max_connections` jauh sebelum CPU. Sebuah pooler seperti **ProxySQL** atau **PgBouncer** melakukan multiplex beribu connection app ke atas beberapa ratus connection DB. Ia perubahan config, bukan reka bentuk semula — lakukan dahulu.

## Langkah 1: cache bacaan

Kebanyakan beban kerja berat-bacaan (selalunya 90%+). Letak **Redis** di hadapan untuk baris panas — profil pengguna, halaman produk. Sebuah cache hit tidak pernah menyentuh MySQL. Guna cache-aside: baca cache → miss → baca DB → isi cache. Ini sahaja boleh menyerap majoriti 100x itu.

## Langkah 2: read replica

Tambah **async read replica** dan halakan SELECT kepadanya, penulisan ke primary. Ini menskala bacaan secara mendatar: N replica ≈ N× kapasiti bacaan. Halangannya ialah **replication lag** — sebuah replica mungkin ketinggalan milisaat-ke-saat, jadi read-your-own-writes memerlukan berhati-hati (halakan bacaan pengguna itu ke primary, atau baca dari cache).

## Langkah 3: shard penulisan

Replica tidak membantu penulisan — setiap penulisan masih mengenai satu primary tunggal. Apabila throughput penulisan menepu satu kotak, **shard**. **Vitess** (dibina di YouTube) duduk di hadapan MySQL dan melakukan sharding, penghalaan query, dan resharding dalam talian tanpa menulis semula app. Shard mengikut `user_id` supaya kebanyakan query kekal single-shard.

## Perspektif temu duga

Penemu duga memerhatikan **urutan**: calon yang segera men-shard mendedahkan mereka tidak tahu replica/caching menyelesaikan penskalaan bacaan dengan jauh lebih murah. Baik: "tambah replica dan cache." Hebat: anda memisahkan laluan bacaan daripada laluan penulisan, menyebut replication lag sebagai kos replica, dan hanya memperkenalkan sharding apabila *penulisan* — bukan bacaan — ialah kesesakan.

**Perangkap biasa:** "tambah sahaja read replica" apabila kesesakan sebenar ialah throughput penulisan. Replica menjadikannya *lebih teruk* (lebih banyak beban replication pada primary).

## Pertukaran & mod kegagalan

- **Replication lag:** bacaan basi; pin bacaan kritikal ke primary atau guna semi-sync replication.
- **Cache stampede:** banyak miss mengenai DB serentak pada tamat tempoh — guna lock atau TTL berperingkat.
- **Kerumitan sharding:** hilang join dan transaction rentas shard; hanya bayar ini apabila penulisan memaksanya.
- **Failover:** kematian primary memerlukan promosi automatik (Orchestrator); sebuah replica yang dinaikkan tetapi basi boleh kehilangan penulisan terkini.

Langkah 0: connection pooling

Langkah 1: cache bacaan

Langkah 2: read replica

Langkah 3: shard penulisan

Perspektif temu duga

Pertukaran & mod kegagalan

Soalan berkaitan