Пулы соединений и блокировки

соединение с БД — дорогой ресурс, а блокировки — главная причина непредсказуемых тормозов.

Почему это важно: Без понимания пулов и локов backend под нагрузкой ведёт себя загадочно: то быстрый, то висящий.

Главная идея

Пул переиспользует соединения, а блокировки защищают данные от одновременных конфликтных изменений.

Как это выглядит на практике

Приложение открывает соединение к БД на каждый запрос — упирается в лимит.
Подключаем пул (PgBouncer / встроенный) — соединения переиспользуются.
Под нагрузкой видим, что транзакции висят на блокировках.
Сокращаем длину транзакций и порядок изменений — блокировки уходят.

Что происходит под капотом

Connection — TCP + аутентификация + сессионное состояние, дорого открывать.
Pool — фиксированный набор соединений, которые отдаются по запросу.
Row-level lock — блокировка отдельной строки при UPDATE.
Deadlock — две транзакции ждут друг друга, БД убивает одну из них.
Long-running transaction блокирует VACUUM и raises bloat.

Типичные ошибки и заблуждения

Ошибка: 'давайте увеличим пул в 10 раз'. БД физически не вытянет столько активных соединений.
Ошибка: SELECT не блокирует. SELECT FOR UPDATE — блокирует.
Ошибка: блокировки безопасны, потому что 'БД сама разберётся'. Дедлоки нужно ловить и ретраить.
Ошибка: транзакции бесплатны. Длинная транзакция = риск для всей БД.

Ключевые выводы

Размер пула = компромисс между параллельностью и нагрузкой на БД.
Транзакции должны быть короткими.
Изменяй данные в одном порядке, чтобы избежать дедлоков.
Лучше поймать и повторить транзакцию, чем терять данные.

Термины урока

Connection pool — переиспользуемый набор соединений к БД.

PgBouncer — внешний пуллер для PostgreSQL.

MVCC — Multi-Version Concurrency Control, способ изоляции без блокировок чтений.

Bloat — раздувание таблицы из-за устаревших версий строк.

Связь с работой backend-разработчика

Пулы и блокировки — это про надёжность под нагрузкой, а не про чистый код. Без них приложение просто упадёт в пиковые часы.

Мини-разбор реальной ситуации

В Black Friday API упал не из-за нагрузки на CPU, а из-за исчерпания пула соединений: одна аналитическая транзакция держала connection 40 минут. Перенесли её в реплику — инцидент закрыт.

Что запомнить

Соединения — дорогой ресурс.
Транзакции — короткие.
Дедлоки — норма, нужны ретраи.

Итог

Производительность БД — это не только индексы, но и аккуратная работа с соединениями и блокировками.