Как масштабировать MySQL, когда трафик растёт в 100 раз?

Question

IT Interview Practice · Accepted Answer

Масштабируйте поэтапно: **сначала read-реплики + кэширование для чтений, затем шардинг (Vitess) для записей** — и добавьте пул соединений раньше всего остального, потому что это самый дешёвый 10-кратный выигрыш. Чтения и записи масштабируются по-разному, поэтому не тянитесь к шардингу в первый же день.

```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: пул соединений

Каждое соединение с MySQL стоит памяти и потока. При 100-кратном трафике вы исчерпаете `max_connections` задолго до CPU. Пулер вроде **ProxySQL** или **PgBouncer** мультиплексирует тысячи соединений приложения на несколько сотен соединений БД. Это изменение конфига, а не переархитектура — делайте первым.

## Шаг 1: кэшируйте чтения

Большинство нагрузок read-heavy (часто 90%+). Поставьте **Redis** впереди для горячих строк — профили пользователей, страницы товаров. Cache hit никогда не касается MySQL. Используйте cache-aside: читаем кэш → miss → читаем БД → заполняем кэш. Одно это может поглотить большую часть 100-кратного роста.

## Шаг 2: read-реплики

Добавьте **асинхронные read-реплики** и направляйте SELECT-ы на них, записи — на primary. Это масштабирует чтения горизонтально: N реплик ≈ N× ёмкости чтения. Загвоздка — **отставание репликации (replication lag)**: реплика может отставать на миллисекунды-секунды, поэтому read-your-own-writes требует аккуратности (направляйте чтения этого пользователя на primary или читайте из кэша).

## Шаг 3: шардируйте записи

Реплики не помогают записям — каждая запись всё равно попадает на единственный primary. Когда throughput записи насыщает одну машину, **шардируйте**. **Vitess** (создан в YouTube) стоит перед MySQL и делает шардинг, маршрутизацию запросов и online-ре-шардинг без переписывания приложения. Шардируйте по `user_id`, чтобы большинство запросов оставались single-shard.

## Взгляд с точки зрения интервью

Интервьюеры следят за **порядком**: кандидаты, сразу шардирующие, выдают, что не знают, что реплики/кэширование решают масштабирование чтений куда дешевле. Хорошо: «добавить реплики и кэш». Отлично: вы разделяете ветку чтения и ветку записи, называете replication lag ценой реплик и вводите шардинг только когда узкое место — *записи*, а не чтения.

**Частая ловушка:** «просто добавить read-реплик», когда реальное узкое место — throughput записи. Реплики делают это *хуже* (больше нагрузки репликации на primary).

## Компромиссы и режимы отказа

- **Replication lag:** устаревшие чтения; закрепляйте критичные чтения на primary или используйте semi-sync репликацию.
- **Cache stampede:** множество miss бьют в БД одновременно при истечении — используйте блокировки или разнесённые TTL.
- **Сложность шардинга:** теряете кросс-шардовые join и транзакции; платите за это, только когда записи вынуждают.
- **Failover:** смерть primary требует автоматического повышения (Orchestrator); устаревшая повышенная реплика может потерять недавние записи.

Шаг 0: пул соединений

Шаг 1: кэшируйте чтения

Шаг 2: read-реплики

Шаг 3: шардируйте записи

Взгляд с точки зрения интервью

Компромиссы и режимы отказа

Похожие вопросы