Kaip skalinti MySQL, kai srautas išauga 100 kartų?

Question

IT Interview Practice · Accepted Answer

Skalinkite etapais: **read replicas + kešavimas skaitymams pirma, tada sharding (Vitess) įrašymams** — ir pridėkite connection pooling prieš viską, nes tai pigiausias 10x. Skaitymai ir įrašymai skalinasi skirtingai, tad negriebkite sharding pirmą dieną.

```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
```

## 0 žingsnis: connection pooling

Kiekvienas MySQL ryšys kainuoja atmintį ir giją. Esant 100x srautui išsemsite `max_connections` gerokai anksčiau nei CPU. Pooler kaip **ProxySQL** ar **PgBouncer** multipleksuoja tūkstančius aplikacijos ryšių į kelis šimtus DB ryšių. Tai konfigūracijos pakeitimas, o ne perprojektavimas — darykite tai pirma.

## 1 žingsnis: kešuokite skaitymus

Dauguma darbo krūvių yra skaitymui imlūs (dažnai 90%+). Priekyje pastatykite **Redis** karštoms eilutėms — naudotojų profiliams, produktų puslapiams. Kešo hit niekada nepaliečia MySQL. Naudokite cache-aside: skaityti kešą → miss → skaityti DB → užpildyti kešą. Vien tai gali sugerti daugumą to 100x.

## 2 žingsnis: read replicas

Pridėkite **async read replicas** ir nukreipkite SELECTus į jas, įrašymus į primary. Tai skalina skaitymus horizontaliai: N replikų ≈ N× skaitymo talpa. Kliūtis yra **replication lag** — replika gali atsilikti milisekundėmis-iki-sekundžių, tad read-your-own-writes reikalauja atidumo (nukreipkite to naudotojo skaitymus į primary arba skaitykite iš kešo).

## 3 žingsnis: skaidykite (shard) įrašymus

Replikos nepadeda įrašymams — kiekvienas įrašymas vis tiek paliečia vieną primary. Kai įrašymo throughput prisotina vieną mašiną, **skaidykite**. **Vitess** (sukurtas YouTube) sėdi priešais MySQL ir atlieka sharding, užklausų nukreipimą ir online resharding neperrašant aplikacijos. Skaidykite pagal `user_id`, kad dauguma užklausų liktų viename shard.

## Interviu perspektyva

Interviuotojai stebi **eiliškumą**: kandidatai, kurie iškart skaido, atskleidžia, kad nežino, jog replikos/kešavimas išsprendžia skaitymo skalavimą kur kas pigiau. Gerai: „pridėkite replikas ir kešą." Puikiai: atskiriate skaitymo kelią nuo įrašymo kelio, įvardijate replication lag kaip replikų kainą ir įvedate sharding tik tada, kai *įrašymai* — ne skaitymai — yra kliūtis.

**Dažni spąstai:** „tiesiog pridėkite read replicas", kai tikroji kliūtis yra įrašymo throughput. Replikos tai *pablogina* (daugiau replikacijos apkrovos primary).

## Kompromisai ir gedimų būdai

- **Replication lag:** pasenę skaitymai; pririškite kritinius skaitymus prie primary arba naudokite semi-sync replikaciją.
- **Cache stampede:** daug miss vienu metu paliečia DB pasibaigus galiojimui — naudokite užraktus arba pakopinius TTL.
- **Sharding sudėtingumas:** prarandate cross-shard join ir transakcijas; mokėkite tai tik tada, kai įrašymai priverčia.
- **Failover:** primary mirtis reikalauja automatinio paaukštinimo (Orchestrator); pasenusi paaukštinta replika gali prarasti naujausius įrašymus.

0 žingsnis: connection pooling

1 žingsnis: kešuokite skaitymus

2 žingsnis: read replicas

3 žingsnis: skaidykite (shard) įrašymus

Interviu perspektyva

Kompromisai ir gedimų būdai

Susiję klausimai