Как построить счётчик просмотров/лайков в реальном времени для вирусных постов?

Question

IT Interview Practice · Accepted Answer

Никогда не делайте `UPDATE posts SET views = views + 1` на каждое событие для горячего поста — эта единственная строка становится узким местом по блокировкам. **Инкрементируйте в Redis, батчами сбрасывайте в БД** каждые несколько секунд и читайте счётчик из Redis. БД хранит durable-итоги, а не живой трафик.

## Архитектура

```text
Client tap ─▶ API ─▶ Redis INCR views:{post}   (live, source of truth for reads)
                          │            └── dedup: SADD seen:{post} {user/ip}
                          ▼
                 every ~5s / N ops
              Flusher ─▶ UPDATE posts SET views = views + delta   (durable)
                          ▲
                 read path: GET Redis (fallback DB on miss)
```

## Компоненты и поток

- **Redis INCR** поглощает шторм записей. Один `INCR views:{post}` атомарен и держит 100k+ операций/с на одном ключе — на порядки больше строки в Postgres. Этот счётчик — источник истины для *чтений*, поэтому зрители видят, как число меняется мгновенно.
- **Дедупликация лайков/уникальных просмотров**: сырой счётчик задваивает обновления страницы. Используйте `SADD seen:{post} {userId}` и делайте `INCR`, только если добавление новое; для дешёвых приблизительных уникальных значений на огромном масштабе — **HyperLogLog** (`PFADD`/`PFCOUNT`): несколько КБ оценивают миллионы уникальных значений с погрешностью ~2%.
- **Батчевый flusher** периодически сбрасывает дельту в БД: `UPDATE posts SET views = views + delta`. Сброс каждые 5 с или каждые N инкрементов превращает миллион записей в горстку — БД держит durable-итог для холодных постов и аналитики.
- **Ветка чтения** отдаёт из Redis; при cache miss читает итог из БД и заново прогревает Redis. Лайкам нужно per-user состояние (лайкнул ли *я*), поэтому храните множество, а не только число.

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

Интервьюеры проверяют, принимаете ли вы **eventual consistency для счётчиков**. «Хорошо» — «кэшировать счётчик»; «отлично» — буферизовать *записи*, осознавая, что узкое место — конкуренция записей на горячей строке, а не нагрузка чтения. Они прощупывают компромисс: приемлем ли приблизительный счёт? Для просмотров — да, никто не заметит разницу 1 203 428 и 1 203 450. Ловушка — переживать о точном счёте и тянуться к транзакции, снова вводя ту самую блокировку, которой вы избегали.

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

- **Точность против throughput**: точные счётчики требуют множеств для дедупликации (тяжело по памяти); приблизительный HyperLogLog крошечный и быстрый. Выбирайте по фиче — лайки точные, просмотры могут быть приблизительными.
- **Durability**: Redis in-memory. Если он умрёт до сброса, вы потеряете несброшенную дельту. Включите AOF и держите окна сброса короткими (секунды), чтобы ограничить потерю; итог в БД плюс небольшой зазор приемлем для счётчика просмотров.
- **Горячий ключ**: вирусный пост концентрирует весь трафик на одном ключе Redis. Шардируйте его на `views:{post}:{0..9}` и суммируйте при чтении, либо направьте горячие ключи на выделенный узел, чтобы один пост не насытил шард.

Архитектура

Компоненты и поток

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

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

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