Как справиться с горячим ключом или горячей строкой при сильной конкуренции?

Question

IT Interview Practice · Accepted Answer

**Перестаньте направлять весь трафик на один ключ: разбейте горячий ключ на N под-ключей (шардированные счётчики), объединяйте дублирующие чтения, отдавайте из локального кэша и батчите записи, чтобы одна строка не обновлялась на каждый запрос.** Единственный счётчик «лайков» на вирусном посте может держать 50k записей/с — одна строка становится узким местом сериализации, так как каждая транзакция дерётся за одну и ту же блокировку.

## Fan-out вместо одной контендящей строки

```text
                 50k inc/sec on post:123
                          │
             hash(request) % N   (split the key)
        ┌────────┬────────┬────────┬────────┐
        ▼        ▼        ▼        ▼        ▼
   likes:123:0  :123:1  :123:2  :123:3  :123:4   ← sharded counters
        └────────┴───┬────┴────────┴────────┘
                     ▼
             SUM on read = total     (read fans in)
```

## Техники

- **Шардированный счётчик / разбиение ключа.** Пишите в `likes:123:{0..N}`, выбранный случайно; истинный счёт — это `SUM`. Это превращает одну горячую строку в N более прохладных, срезая конкуренцию блокировок примерно в N раз. Чтения платят небольшую стоимость fan-in.
- **Объединение запросов (single-flight).** Если 10k запросов хотят один ключ разом, дайте **одному** попасть в БД, а остальные пусть ждут этот in-flight результат. Предотвращает crush строки от cache-miss stampede.
- **Локальный (in-process) кэш.** Кэшируйте горячее значение в каждом узле приложения на короткий TTL (например, 1 с). Для read-hot ключа это сворачивает тысячи чтений/с в одно обновление — принимая лёгкое устаревание.
- **Батчинг записей.** Буферизуйте инкременты в памяти и сбрасывайте `+= 500` раз в секунду вместо 500 одиночных обновлений. Одно обновление строки в секунду вместо 500 полностью убирает конкуренцию.

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

Интервьюер хочет увидеть, что вы диагностируете, **где конкуренция**, и подбираете фикс под read-hot против write-hot. Read-hot → кэш + объединение; write-hot → шардированные счётчики + батчинг. Хороший ответ перечисляет техники; отличный отмечает, что шардинг обменивает **стоимость чтения на масштабируемость записи**, а батчинг/кэширование обменивают **свежесть на throughput**.

**Компромиссы и ловушки:** шардированные счётчики усложняют точные real-time итоги (вы суммируете шарды) и логику «декремент ниже нуля». Локальные кэши расходятся между узлами — нормально для счётчика лайков, неверно для банковского баланса. Батчинг рискует потерять буферизованные записи, если узел падает до сброса, поэтому он подходит идемпотентным/приблизительным счётчикам, а не деньгам. Выбирайте смягчение, которое позволяют требования консистентности данных.

Fan-out вместо одной контендящей строки

Техники

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

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