2. Connection pool

Введение: Зачем нужен пул соединений

Представьте себе оживленный аэропорт, куда каждую секунду прибывают сотни пассажиров. Если бы диспетчерская служба заставляла каждого пассажира звонить на завод, собирать автомобиль с нуля, регистрировать его в дорожной инспекции и только потом ехать в город — транспортная система сколлапсировала бы в первую же минуту. Разумный город держит на стоянке прогретый таксопарк: машины уже заведены, бензин в баках, водители готовы тронуться немедленно. Пассажир садится, доезжает до места, расплачивается, а автомобиль тут же возвращается на стоянку за следующим клиентом.

Установка прямого сетевого соединения с базой данных — это как раз сборка автомобиля с нуля:

• Тройное рукопожатие TCP (TCP handshake): три сетевых пакета (SYN, SYN-ACK, ACK), добавляющие как минимум один полный круговой путь задержки (RTT).
• Криптографическое рукопожатие TLS (TLS handshake): обмен сертификатами, асимметричная криптография по протоколам Диффи-Хеллмана или RSA, согласование симметричных ключей (еще 2–4 RTT и драгоценные миллисекунды тактов CPU).
• Аутентификация и авторизация: сервер СУБД должен проверить хэши паролей, права доступа в системных каталогах, сверить IP-адрес с pg_hba.conf или таблицами mysql.user.
• Выделение ресурсов на стороне СУБД: в PostgreSQL на каждое входящее соединение ядро форкает отдельный процесс операционной системы (postgres worker process), выделяет сегменты разделяемой памяти, структуры отслеживания транзакций и буферы сортировки (work_mem).

В высоконагруженной системе, обрабатывающей тысячи сетевых запросов в секунду, создание нового физического сокета на каждый HTTP-запрос привело бы к моментальной деградации: база данных задохнулась бы от переключения контекстов процессов ОС, а бэкенд растратил бы все сокетные дескрипторы.

Пул соединений (Connection Pool) — это архитектурный паттерн, при котором клиентское приложение заранее создает и непрерывно поддерживает готовый пул сетевых сокетов, переиспользуя их для миллионов последовательных транзакций. Стандартный пакет database/sql в Go реализует этот паттерн «из коробки», но за кажущейся простотой скрывается сложнейший конкурентный диспетчер.

Архитектура пула в database/sql

Внутренняя структура *sql.DB содержит несколько ключевых полей, отвечающих за управление пулом. Хотя точная реализация может меняться между версиями Go, концептуальная модель остается стабильной.

flowchart LR
    classDef process  fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef success  fill:#064e3b,stroke:#34d399,stroke-width:1px,color:#f8fafc
    classDef error    fill:#7f1d1d,stroke:#f87171,stroke-width:1px,color:#f8fafc
    classDef warning  fill:#78350f,stroke:#fbbf24,stroke-width:1px,color:#f8fafc
    classDef entry    fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef aux      fill:#334155,stroke:#64748b,stroke-width:1px,color:#f8fafc
    classDef system   fill:#312e81,stroke:#a78bfa,stroke-width:1px,color:#f8fafc
    classDef data     fill:#132d29,stroke:#2dd4bf,stroke-width:1px,color:#f8fafc
    classDef network  fill:#881337,stroke:#fb7185,stroke-width:1px,color:#f8fafc
    classDef accent   fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#f8fafc
    subgraph sqlDB ["*sql.DB (Pool State)"]
        mu["sync.Mutex<br>Защита состояния"]:::accent
        freeConn["[]*driverConn<br>Очередь idle соединений"]
        openerCh["chan struct{}<br>Сигнал на создание нового"]
        numOpen["atomic int<br>Счетчик открытых соединений"]:::process
        waitCh["chan struct{}<br>Очередь ожидающих горутин"]
    end

    App["Горутина приложения"] -->|"Request"| sqlDB
    sqlDB -->|"Assign conn"| Driver["driver.Conn"]
    Driver -->|"Network IO"| DBServer["PostgreSQL / MySQL"]
  

Состояния соединений: idle, inUse, closed

Каждое физическое соединение (driverConn) в пуле находится в одном из трех состояний:

Внутренние структуры: db.mu, db.freeConn, db.openerCh

// Упрощенная схема внутренней структуры (из исходников database/sql)
type DB struct {
    mu           sync.Mutex              // Глобальная блокировка пула
    openerCh     chan struct{}           // Сигнал для goroutine-создателя
    closed       bool
    dep          map[finalCloser]depSet

    // Статистика и счетчики
    numOpen      atomic.Int[int]         // Текущее количество открытых соединений
    maxOpen      int                     // Лимит из SetMaxOpenConns

    // Пул idle соединений
    freeConn     []*driverConn           // Слайс доступных соединений
    connRequests map[uint64]*connRequest // Очередь ожидающих запросов

    // Таймауты
    connMaxLifetime time.Duration
    connMaxIdleTime time.Duration
}

Механика выдачи соединений

Алгоритм получения соединения из пула (DB.conn) можно представить следующим образом:

flowchart TD
    classDef process  fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef success  fill:#064e3b,stroke:#34d399,stroke-width:1px,color:#f8fafc
    classDef error    fill:#7f1d1d,stroke:#f87171,stroke-width:1px,color:#f8fafc
    classDef warning  fill:#78350f,stroke:#fbbf24,stroke-width:1px,color:#f8fafc
    classDef entry    fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef aux      fill:#334155,stroke:#64748b,stroke-width:1px,color:#f8fafc
    classDef system   fill:#312e81,stroke:#a78bfa,stroke-width:1px,color:#f8fafc
    classDef data     fill:#132d29,stroke:#2dd4bf,stroke-width:1px,color:#f8fafc
    classDef network  fill:#881337,stroke:#fb7185,stroke-width:1px,color:#f8fafc
    classDef accent   fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#f8fafc
    Start["Вызов: db.QueryContext"]:::data --> Lock["Захват db.mu"]
    Lock --> CheckFree{"freeConn<br>не пуст?"}

    CheckFree -- Да --> PopIdle["Извлечь из freeConn"]
    PopIdle --> MarkInUse["Пометить inUse"]

    CheckFree -- Нет --> CheckOpen{"numOpen < maxOpen?"}
    CheckOpen -- Да --> IncOpen["numOpen++<br>Сигнал в openerCh"]
    IncOpen --> CreateAsync["Создание в background"]

    CheckOpen -- Нет --> WaitReq["Добавить в connRequests<br>Ожидание на waitCh"]

    CreateAsync --> Unlock1["Освободить db.mu"]
    WaitReq --> Unlock2["Освободить db.mu"]
    MarkInUse --> Unlock3["Освободить db.mu"]

    Unlock1 --> ReturnConn["Возврат *driverConn"]
    Unlock2 --> BlockWait["Блокировка горутины"]
    Unlock3 --> ReturnConn
  

Алгоритм getConnection

1. Быстрый путь (Fast Path): Если в freeConn есть соединения, они выдаются по принципу LIFO (Last In, First Out). Это повышает вероятность использования «теплого» соединения, которое еще не успело остыть с точки зрения сетевых таймаутов.
2. Медленный путь (Slow Path): Если freeConn пуст, но лимит не достигнут, увеличивается счетчик numOpen и отправляется сигнал в канал openerCh. Отдельная горутина connectionOpener обрабатывает этот сигнал и асинхронно устанавливает новое соединение.
3. Блокировка: Если лимит maxOpen достигнут, текущая горутина добавляется в очередь connRequests и блокируется. Когда другое соединение возвращается в пул (putConn), оно будит одну из ожидающих горутин.

Блокировка при исчерпании лимита

Когда все соединения inUse и лимит maxOpen достигнут, новые запросы блокируются. Это поведение настраивается через контекст:

// Если контекст имеет таймаут, блокировка не будет бесконечной
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

rows, err := db.QueryContext(ctx, "SELECT ...")
// Если за 5 секунд соединение не освободится:
// err = context deadline exceeded

Создание и закрытие соединений

Ленивая инициализация и db.opener

Соединения не создаются при вызове sql.Open. Они создаются лениво, по мере необходимости. Горутина connectionOpener работает в фоне:

// Псевдокод из runtime database/sql
func (db *DB) connectionOpener(ctx context.Context) {
    for {
        select {
        case <-ctx.Done():
            return
        case <-db.openerCh:
            // Асинхронное создание соединения
            go db.openNewConnection()
        }
    }
}

func (db *DB) openNewConnection() {
    // Вызов driver.Open() -> TCP dial -> Auth
    dc, err := driver.Open(dsn)
    db.mu.Lock()
    if err != nil {
        db.numOpen.Add(-1) // Откат счетчика при ошибке
    } else {
        db.putConn(dc, nil, true) // Возврат в пул или выдача ожидающему
    }
    db.mu.Unlock()
}

Ротация соединений: ConnMaxLifetime

Соединения не живут вечно. Параметр SetConnMaxLifetime контролирует максимальное время жизни соединения с момента его создания.

Настройка пула: практическое руководство

SetMaxOpenConns: баланс между конкурентностью и ресурсами

// ❌ Опасно: безлимит по умолчанию
// db, _ := sql.Open("postgres", dsn) // maxOpen = 0 (unlimited)

// ✅ Правильно: явное ограничение
db.SetMaxOpenConns(50)

Как подобрать значение:

• CPU-bound нагрузка: maxOpen ≈ (CPU cores * 2) + эффективный диск
• IO-bound нагрузка (типичный веб-бэкенд): maxOpen ≈ 50-200, зависит от латентности БД
• Формула Литтла: MaxConns = QPS * AvgQueryLatency (с запасом 20-30%)

SetMaxIdleConns: теплые соединения vs память

// Рекомендуется: держать 20-50% от maxOpen в idle
db.SetMaxIdleConns(25) // при maxOpen=50

• Слишком мало: Частое создание/уничтожение соединений → нагрузка на CPU, TCP handshake, GC.
• Слишком много: Лишнее потребление памяти (буферы сокетов) на стороне приложения и БД, удерживание файловых дескрипторов.

Конфигурация для разных сценариев нагрузки

Мониторинг и метрики пула

Пакет database/sql предоставляет встроенный метод Stats() для наблюдения за состоянием пула.

func monitorDB(db *sql.DB, interval time.Duration) {
    ticker := time.NewTicker(interval)
    defer ticker.Stop()

    for range ticker.C {
        stats := db.Stats()

        // Ключевые метрики для алертинга:
        // 1. WaitCount: сколько раз горутины ждали свободное соединение
        if stats.WaitCount > threshold {
            log.Warn("High connection wait count", "count", stats.WaitCount)
        }

        // 2. WaitDuration: суммарное время ожидания
        // 3. Idle: сколько соединений простаивает
        // 4. InUse: сколько соединений активно (основной индикатор нагрузки)
        // 5. Open: общее количество открытых (должно быть <= MaxOpen)

        prometheus.DBPoolInUse.Set(float64(stats.InUse))
        prometheus.DBPoolIdle.Set(float64(stats.Idle))
        prometheus.DBPoolWaitCount.Set(float64(stats.WaitCount))
    }
}

Интерпретация метрик: waitCount, waitDuration, idle

Проблемы и их диагностика

Connection pool exhausted: причины и решения

Симптом: ошибки sql: connection pool exhausted или бесконечное зависание запросов.

Чеклист диагностики:

1. Утечка rows.Close(): Проверьте, все ли Query имеют defer rows.Close().
2. Заброшенные транзакции: Транзакция без Commit/Rollback удерживает соединение навсегда.
3. Слишком низкий MaxOpen: Увеличьте лимит, если метрики показывают постоянную утилизацию ~100%.
4. Долгие запросы: Используйте EXPLAIN, добавьте индексы, разбейте сложные запросы.
5. Сетевые проблемы: Проверьте dial timeout, read timeout на уровне драйвера.

// Пример правильной обработки с таймаутами
func safeQuery(ctx context.Context, db *sql.DB, query string) error {
    // Таймаут на весь запрос
    ctx, cancel := context.WithTimeout(ctx, 2*time.Second)
    defer cancel()

    rows, err := db.QueryContext(ctx, query)
    if err != nil {
        return fmt.Errorf("query failed: %w", err)
    }
    defer rows.Close() // Гарантированный возврат соединения

    // Обработка...
    return nil
}

Утечки соединений: rows.Close(), tx.Rollback()

Долгие запросы и блокировка пула

Один медленный запрос может «заблокировать» одно соединение из пула на все время выполнения. Если таких запросов много, пул быстро исчерпается.

Стратегии борьбы:

• Query timeout: Всегда используйте context.WithTimeout.
• Statement timeout на стороне БД: Настройте statement_timeout в PostgreSQL для принудительного прерывания долгих запросов.
• Read-only реплики: Направляйте аналитические/тяжелые запросы на реплики, чтобы не блокировать пул для критичных OLTP-операций.

Mechanical Sympathy: влияние на производительность

Syscalls и network I/O при установке соединения

Установка нового TCP-соединения требует как минимум:

• 3 пакета для TCP handshake (SYN, SYN-ACK, ACK)
• 4-7 пакетов для TLS handshake (ClientHello, ServerHello, Certificate, KeyExchange...)
• Системные вызовы socket(), connect(), write(), read()

Влияние на GC и аллокации

Каждое соединение содержит буферы для чтения/записи (обычно 4-8 КБ каждый). При создании сотен соединений вы аллоцируете мегабайты памяти, которые создают давление на Garbage Collector.

// Пример: оценка памяти пула
// 100 соединений * (8KB read buf + 8KB write buf + overhead ~4KB) = ~2MB
// Это не много, но при частой ротации (создание/удаление) нагрузка на GC растет.

TCP keepalive и таймауты на уровне ОС

По умолчанию драйверы включают TCP keepalive (обычно 30-60 секунд). Это важно для обнаружения «мертвых» соединений, которые были закрыты сетевым оборудованием, но приложение об этом не знает.

Сравнение подходов: пул в Go vs другие языки

Чеклист для продакшена

1. [ ] SetMaxOpenConns установлен в значение, соответствующее нагрузке и ресурсам БД.
2. [ ] SetMaxIdleConns составляет 30-50% от MaxOpen для баланса между скоростью и памятью.
3. [ ] SetConnMaxLifetime настроен (15-30 минут) для ротации соединений и предотвращения «протухания».
4. [ ] Все запросы используют context.WithTimeout для защиты от бесконечного ожидания.
5. [ ] defer rows.Close() и defer tx.Rollback() используются повсеместно.
6. [ ] Метрики db.Stats() экспортируются в Prometheus/Grafana для мониторинга.
7. [ ] На стороне БД настроены statement_timeout и idle_in_transaction_session_timeout как последняя линия обороны.
8. [ ] Проведено нагрузочное тестирование для подбора оптимальных параметров пула.

Итог

Пул соединений в database/sql — это мощный механизм, который при правильной настройке обеспечивает высокую производительность и отказоустойчивость вашего приложения. Ключевые принципы:

• Ограничивайте (MaxOpen) — чтобы не перегрузить БД.
• Кэшируйте (MaxIdle) — чтобы избежать накладных расходов на создание.
• Ротируйте (MaxLifetime) — чтобы избегать сетевых артефактов.
• Мониторьте (Stats) — чтобы вовремя реагировать на проблемы.
• Защищайте (Context) — чтобы запросы не висели вечно.

Понимание внутренней механики пула позволяет не просто «настроить по гайду», а осознанно диагностировать и решать проблемы производительности на уровне системного дизайна.

В следующей статье мы сравним два фундаментальных подхода к работе с данными в Go: написание «сырого» SQL через database/sql и использование ORM-библиотек. Разберем компромиссы между контролем, производительностью и скоростью разработки. Читайте далее: 3. ORM vs SQL.