Senior Go Interview Prep - Core Go: https://go.vbloher.org/docs/01-core-go/ - Механика defer в Go: https://go.vbloher.org/docs/01-core-go/defer/ - Встраивание структур и интерфейсов (Embedding): https://go.vbloher.org/docs/01-core-go/embedding/ - Ошибки в Go: error, wrapping, errors.Is/As/Join: https://go.vbloher.org/docs/01-core-go/errors/ - Дженерики в Go (1.18+): https://go.vbloher.org/docs/01-core-go/generics/ - Интерфейсы в Go: https://go.vbloher.org/docs/01-core-go/interfaces/ - Устройство map в Go: https://go.vbloher.org/docs/01-core-go/maps/ - panic / recover: механика, раскрутка стека и runtime-паники: https://go.vbloher.org/docs/01-core-go/panic-recover/ - Указатели в Go: https://go.vbloher.org/docs/01-core-go/pointers/ - Рефлексия в Go (reflect): https://go.vbloher.org/docs/01-core-go/reflection/ - Внутреннее устройство слайсов в Go: https://go.vbloher.org/docs/01-core-go/slices/ - Строки, руны и байты в Go: https://go.vbloher.org/docs/01-core-go/strings-runes-bytes/ - Система типов Go: defined types, alignment, memory layout: https://go.vbloher.org/docs/01-core-go/type-system/ - Concurrency: https://go.vbloher.org/docs/02-concurrency/ - sync/atomic: https://go.vbloher.org/docs/02-concurrency/atomic/ - Буферизованные vs небуферизованные каналы: https://go.vbloher.org/docs/02-concurrency/buffered-unbuffered/ - Канал vs Mutex: когда что выбрать: https://go.vbloher.org/docs/02-concurrency/channel-vs-mutex/ - Каналы: устройство hchan: https://go.vbloher.org/docs/02-concurrency/channels/ - Утечки горутин, дедлоки, livelock, starvation: https://go.vbloher.org/docs/02-concurrency/common-leaks-deadlocks/ - sync.Cond: https://go.vbloher.org/docs/02-concurrency/cond/ - context: https://go.vbloher.org/docs/02-concurrency/context/ - Горутины: жизненный цикл, стоимость, стек: https://go.vbloher.org/docs/02-concurrency/goroutines-lifecycle/ - sync.Mutex и sync.RWMutex: https://go.vbloher.org/docs/02-concurrency/mutex-rwmutex/ - sync.Once: https://go.vbloher.org/docs/02-concurrency/once/ - Паттерны конкурентности: https://go.vbloher.org/docs/02-concurrency/patterns/ - Race Detector (гонки данных и -race): https://go.vbloher.org/docs/02-concurrency/race-detector/ - Планировщик GMP: https://go.vbloher.org/docs/02-concurrency/scheduler-gmp/ - select: https://go.vbloher.org/docs/02-concurrency/select/ - sync.WaitGroup: https://go.vbloher.org/docs/02-concurrency/waitgroup/ - Runtime и память: https://go.vbloher.org/docs/03-runtime-memory/ - Паттерны аллокаций и снижение давления на GC: https://go.vbloher.org/docs/03-runtime-memory/allocation-patterns/ - Escape Analysis: когда переменная убегает в кучу: https://go.vbloher.org/docs/03-runtime-memory/escape-analysis/ - Сборщик мусора Go: concurrent tri-color mark-sweep: https://go.vbloher.org/docs/03-runtime-memory/gc/ - Тюнинг GC: GOGC и GOMEMLIMIT: https://go.vbloher.org/docs/03-runtime-memory/gogc-gomemlimit/ - GOMAXPROCS: параллелизм планировщика и проблема контейнеров: https://go.vbloher.org/docs/03-runtime-memory/gomaxprocs/ - Утечки горутин (goroutine leaks): https://go.vbloher.org/docs/03-runtime-memory/goroutine-leaks/ - Утечки памяти в Go (несмотря на GC): https://go.vbloher.org/docs/03-runtime-memory/memory-leaks/ - Модель памяти Go (Go Memory Model): happens-before и синхронизация: https://go.vbloher.org/docs/03-runtime-memory/memory-model/ - pprof: профилирование CPU, памяти и блокировок в Go: https://go.vbloher.org/docs/03-runtime-memory/pprof/ - Execution Tracer и runtime/trace: тайминги вместо агрегатов: https://go.vbloher.org/docs/03-runtime-memory/runtime-tracing/ - Стек vs Куча: где живут данные в Go: https://go.vbloher.org/docs/03-runtime-memory/stack-vs-heap/ - Тестирование: https://go.vbloher.org/docs/04-testing/ - testify, assert/require и golden files: https://go.vbloher.org/docs/04-testing/assertions-testify/ - Бенчмарки в Go: https://go.vbloher.org/docs/04-testing/benchmarks/ - Покрытие, -race и флаки-тесты: https://go.vbloher.org/docs/04-testing/coverage-race/ - Нативный fuzzing в Go (1.18+): https://go.vbloher.org/docs/04-testing/fuzzing/ - Интеграционные тесты, testcontainers-go, TestMain: https://go.vbloher.org/docs/04-testing/integration-testcontainers/ - Моки, стабы и тестируемость: https://go.vbloher.org/docs/04-testing/mocks/ - Table-driven тесты, subtests и параллельность: https://go.vbloher.org/docs/04-testing/table-driven/ - Backend: https://go.vbloher.org/docs/05-backend/ - Аутентификация и авторизация: AuthN/AuthZ, сессии vs токены, RBAC/ABAC, API keys, mTLS, секреты: https://go.vbloher.org/docs/05-backend/auth-authz/ - Graceful Shutdown HTTP/gRPC сервера в Go: https://go.vbloher.org/docs/05-backend/graceful-shutdown/ - gRPC: типы RPC, интерсепторы, контекст, метаданные, error model: https://go.vbloher.org/docs/05-backend/grpc/ - JWT (JSON Web Token): https://go.vbloher.org/docs/05-backend/jwt/ - Middleware-паттерн в Go: https://go.vbloher.org/docs/05-backend/middleware/ - net/http: Server, Handler, ServeMux, таймауты, Client и контекст: https://go.vbloher.org/docs/05-backend/net-http/ - OAuth2: роли, grant types, OIDC, токены и типовые ошибки: https://go.vbloher.org/docs/05-backend/oauth2/ - OpenAPI/Swagger, code generation, contract-first vs code-first, валидация: https://go.vbloher.org/docs/05-backend/openapi/ - Protocol Buffers: схемы, wire format, эволюция и совместимость: https://go.vbloher.org/docs/05-backend/protobuf/ - REST: принципы, версионирование, идемпотентность, статусы, пагинация, ошибки: https://go.vbloher.org/docs/05-backend/rest/ - Сети и протоколы: https://go.vbloher.org/docs/06-networking/ - Пулы соединений: http.Transport, БД, утечки: https://go.vbloher.org/docs/06-networking/connection-pooling/ - DNS: записи, резолвинг, кэширование, DNS в Go: https://go.vbloher.org/docs/06-networking/dns/ - Версии HTTP: 1.1, 2, 3: https://go.vbloher.org/docs/06-networking/http-versions/ - TCP/IP: модель, транспорт и что важно бэкендеру: https://go.vbloher.org/docs/06-networking/tcp-ip/ - TLS: handshake, сертификаты, mTLS, производительность: https://go.vbloher.org/docs/06-networking/tls/ - UDP и надёжность поверх UDP: https://go.vbloher.org/docs/06-networking/udp/ - WebSocket: upgrade, фреймы, масштабирование: https://go.vbloher.org/docs/06-networking/websocket/ - Базы данных: https://go.vbloher.org/docs/07-databases/ - Пул соединений к PostgreSQL в Go: database/sql, pgx, pgxpool, PgBouncer: https://go.vbloher.org/docs/07-databases/connection-pooling-pgx/ - Взаимоблокировки (Deadlocks) в PostgreSQL: https://go.vbloher.org/docs/07-databases/deadlocks/ - Индексы в PostgreSQL: https://go.vbloher.org/docs/07-databases/indexes/ - Уровни изоляции транзакций в PostgreSQL: https://go.vbloher.org/docs/07-databases/isolation-levels/ - MVCC в PostgreSQL: версии строк, видимость, VACUUM и bloat: https://go.vbloher.org/docs/07-databases/mvcc/ - Обзор NoSQL и Redis: https://go.vbloher.org/docs/07-databases/nosql-redis/ - Партиционирование таблиц в PostgreSQL: https://go.vbloher.org/docs/07-databases/partitioning/ - Архитектура PostgreSQL: https://go.vbloher.org/docs/07-databases/postgresql-architecture/ - Планирование и оптимизация запросов в PostgreSQL: https://go.vbloher.org/docs/07-databases/query-planning/ - Репликация в PostgreSQL: https://go.vbloher.org/docs/07-databases/replication/ - Шардирование (горизонтальное масштабирование): https://go.vbloher.org/docs/07-databases/sharding/ - Транзакции в PostgreSQL и Go (database/sql, pgx): https://go.vbloher.org/docs/07-databases/transactions/ - Распределённые системы: https://go.vbloher.org/docs/08-distributed-systems/ - CAP теорема: https://go.vbloher.org/docs/08-distributed-systems/cap-theorem/ - Circuit Breaker: https://go.vbloher.org/docs/08-distributed-systems/circuit-breaker/ - Консенсус и Raft: репликация состояния в присутствии отказов: https://go.vbloher.org/docs/08-distributed-systems/consensus-raft/ - Модели согласованности: https://go.vbloher.org/docs/08-distributed-systems/consistency/ - Гарантии доставки сообщений: at-most-once / at-least-once / exactly-once: https://go.vbloher.org/docs/08-distributed-systems/delivery-guarantees/ - Eventual Consistency: https://go.vbloher.org/docs/08-distributed-systems/eventual-consistency/ - Идемпотентность в распределённых системах: https://go.vbloher.org/docs/08-distributed-systems/idempotency/ - Apache Kafka: https://go.vbloher.org/docs/08-distributed-systems/kafka/ - Transactional Outbox: https://go.vbloher.org/docs/08-distributed-systems/outbox/ - RabbitMQ: AMQP 0-9-1, маршрутизация, надёжность доставки и сравнение с Kafka: https://go.vbloher.org/docs/08-distributed-systems/rabbitmq/ - Ретраи: backoff, jitter, budgets и идемпотентность: https://go.vbloher.org/docs/08-distributed-systems/retries/ - Saga Pattern: https://go.vbloher.org/docs/08-distributed-systems/saga/ - Observability: https://go.vbloher.org/docs/09-observability/ - Grafana: https://go.vbloher.org/docs/09-observability/grafana/ - Метрики: RED, USE, Golden Signals: https://go.vbloher.org/docs/09-observability/metrics/ - OpenTelemetry: https://go.vbloher.org/docs/09-observability/opentelemetry/ - Prometheus: https://go.vbloher.org/docs/09-observability/prometheus/ - SLI / SLO / SLA: https://go.vbloher.org/docs/09-observability/slo-sli/ - Структурированное логирование (slog): https://go.vbloher.org/docs/09-observability/structured-logging/ - Distributed Tracing: https://go.vbloher.org/docs/09-observability/tracing/ - System Design: https://go.vbloher.org/docs/10-system-design/ - Analytics Pipeline: https://go.vbloher.org/docs/10-system-design/analytics-pipeline/ - Chat System: https://go.vbloher.org/docs/10-system-design/chat/ - Фреймворк System Design интервью: https://go.vbloher.org/docs/10-system-design/framework/ - Notification Service: https://go.vbloher.org/docs/10-system-design/notification-service/ - Order Service: https://go.vbloher.org/docs/10-system-design/order-service/ - Payment Service: https://go.vbloher.org/docs/10-system-design/payment-service/ - Rate Limiter: https://go.vbloher.org/docs/10-system-design/rate-limiter/ - URL Shortener: https://go.vbloher.org/docs/10-system-design/url-shortener/ - DevOps: https://go.vbloher.org/docs/11-devops/ - CI/CD: пайплайны, стадии, стратегии деплоя: https://go.vbloher.org/docs/11-devops/cicd/ - Облака (AWS / GCP) для бэкендера: https://go.vbloher.org/docs/11-devops/cloud-aws-gcp/ - Docker для Go-разработчика: https://go.vbloher.org/docs/11-devops/docker/ - GitHub Actions и GitLab CI: https://go.vbloher.org/docs/11-devops/github-gitlab-ci/ - Kubernetes для Go-разработчика: https://go.vbloher.org/docs/11-devops/kubernetes/ - Terraform / Infrastructure as Code: https://go.vbloher.org/docs/11-devops/terraform/ - Алгоритмы: https://go.vbloher.org/docs/12-algorithms/ - Типовые алгоритмические задачи и паттерны: https://go.vbloher.org/docs/12-algorithms/common-problems/ - Асимптотическая сложность (Big-O): https://go.vbloher.org/docs/12-algorithms/complexity/ - Структуры данных в Go: https://go.vbloher.org/docs/12-algorithms/data-structures/ - Специфика live-coding на Go: https://go.vbloher.org/docs/12-algorithms/go-specifics/ - Behavioral: https://go.vbloher.org/docs/13-behavioral/ - Конфликты, разногласия и работа со стейкхолдерами: https://go.vbloher.org/docs/13-behavioral/conflicts/ - Как проходит senior-интервью: этапы, оценка, оффер: https://go.vbloher.org/docs/13-behavioral/interview-flow/ - Лидерство и менторство: https://go.vbloher.org/docs/13-behavioral/leadership-mentoring/ - Типовые поведенческие вопросы для Senior: https://go.vbloher.org/docs/13-behavioral/senior-questions/ > Модуль: Сети и протоколы · Уровень: Middle+/Senior ## TL;DR - Пул соединений переиспользует установленные TCP(+TLS) соединения, экономя дорогой handshake (RTT + TLS + slow start) и избегая исчерпания эфемерных портов / TIME_WAIT. - В Go HTTP-пул живёт в `http.Transport`: ключевые ручки — `MaxIdleConns`, `MaxIdleConnsPerHost`, `MaxConnsPerHost`, `IdleConnTimeout`. - **Главный антипаттерн**: создавать новый `http.Client`/`Transport` на каждый запрос — пул не переиспользуется, соединения не шарятся. Клиент должен быть один и переиспользуемый. - **Утечки соединений**: незакрытое `resp.Body` → соединение не возвращается в пул → рост FD, новые коннекты, деградация. То же для БД: незакрытые `*sql.Rows`. - Для БД (`database/sql`): `SetMaxOpenConns`, `SetMaxIdleConns`, `SetConnMaxLifetime`, `SetConnMaxIdleTime`. Lifetime критичен для DNS-failover и балансировки. ## Теория ### Зачем пул Установка соединения дорогая: TCP handshake (1 RTT) + TLS handshake (1-2 RTT) + TCP slow start. На горячем пути это десятки-сотни мс. Пул держит idle-соединения готовыми к переиспользованию (keep-alive), убирая эти затраты и снижая TIME_WAIT/исчерпание портов. ### http.Transport: ключевые параметры ```go tr := &http.Transport{ MaxIdleConns: 100, // всего idle во всём пуле MaxIdleConnsPerHost: 10, // idle на один host (ДЕФОЛТ = 2!) MaxConnsPerHost: 0, // 0 = без лимита активных на host IdleConnTimeout: 90 * time.Second, // когда idle закрывается TLSHandshakeTimeout: 10 * time.Second, ExpectContinueTimeout: 1 * time.Second, // DialContext контролирует TCP-таймаут и keep-alive DialContext: (&net.Dialer{ Timeout: 5 * time.Second, KeepAlive: 30 * time.Second, }).DialContext, ForceAttemptHTTP2: true, } client := &http.Client{Transport: tr, Timeout: 30 * time.Second} ``` | Параметр | Что делает | Дефолт | |---|---|---| | `MaxIdleConns` | макс. idle во всём пуле | 100 | | `MaxIdleConnsPerHost` | макс. idle на хост | **2** (часто мало!) | | `MaxConnsPerHost` | макс. всего (active+idle) на хост, блокирует сверх лимита | 0 (∞) | | `IdleConnTimeout` | время жизни idle-соединения | 90s (у `DefaultTransport`) | - **`MaxIdleConnsPerHost = 2`** — самый частый перформанс-баг: под нагрузкой к одному бэкенду создаётся много соединений, но в пуле кэшируется только 2; остальные после запроса закрываются → постоянные новые handshake + TIME_WAIT. Поднимать под профиль нагрузки. - `MaxConnsPerHost` ограничивает конкурентность (избегает заваливания бэкенда), при достижении лимита запросы ждут. - `http.DefaultTransport` уже пулит — но дефолтный `per-host=2` его ограничивает. ### Правильное использование клиента ```go // ХОРОШО: один клиент на всё приложение (или на интеграцию) var apiClient = &http.Client{Transport: tr, Timeout: 30 * time.Second} // ПЛОХО: новый клиент/транспорт на каждый запрос — пул не работает func bad() { c := &http.Client{} // новый транспорт каждый раз = нет переиспользования c.Get("https://api") } ``` ### Критично: всегда закрывать и дочитывать Body ```go resp, err := client.Get(url) if err != nil { return err } defer resp.Body.Close() // обязательно // дочитать тело, иначе соединение НЕ вернётся в пул io.Copy(io.Discard, resp.Body) // drain ``` - Соединение возвращается в пул **только если тело полностью прочитано И закрыто**. Иначе Go не может переиспользовать соединение (не знает границу ответа) → закрывает его, теряя пул. - Это причина №1 "утечки" соединений и роста числа коннектов в Go HTTP-клиентах. ### Пулы для БД (database/sql) `*sql.DB` — это пул, а не одно соединение. Создавайте один на приложение. ```go db, _ := sql.Open("postgres", dsn) db.SetMaxOpenConns(25) // макс. одновременных соединений к БД db.SetMaxIdleConns(25) // idle в пуле (часто = MaxOpen) db.SetConnMaxLifetime(5 * time.Minute) // макс. время жизни соединения db.SetConnMaxIdleTime(1 * time.Minute) // макс. простоя ``` | Параметр | Зачем | |---|---| | `SetMaxOpenConns` | ограничить нагрузку на БД, избежать "too many connections" | | `SetMaxIdleConns` | сколько держать готовыми; меньше MaxOpen → постоянное пересоздание | | `SetConnMaxLifetime` | принудительно обновлять соединения: подхват DNS-изменений, ребаланс после failover/деплоя БД, обход серверных таймаутов | | `SetConnMaxIdleTime` | закрывать давно неиспользуемые | - **`SetConnMaxLifetime`** критичен за load balancer / при failover: без него пул вечно держит соединения к старому мастеру/инстансу. - `MaxIdleConns < MaxOpenConns` → соединения сверх idle закрываются после возврата и пересоздаются под нагрузкой (churn). Обычно ставят равными. - Незакрытые `rows.Close()` / неосвобождённые `*sql.Conn`/`*sql.Tx` держат соединение занятым → пул исчерпывается → запросы виснут на ожидании свободного соединения. ### Утечки соединений: симптомы и причины - Симптомы: рост числа FD/established-соединений, "cannot assign requested address" (TIME_WAIT), "too many open files", таймауты на получение соединения из пула, рост latency. - Причины: - HTTP: незакрытый/недочитанный `resp.Body`; новый клиент на каждый запрос; слишком низкий per-host idle. - БД: незакрытые `rows`/`tx`/`stmt`; контекст без таймаута; `MaxOpenConns` слишком мал под параллелизм. - Диагностика: `ss -s`, `lsof`, `runtime` метрики, `db.Stats()` (WaitCount, WaitDuration, InUse, Idle), `pprof` на горутины (висящие на пуле). ## Подводные камни / gotchas - **`MaxIdleConnsPerHost` дефолт = 2** — почти всегда мало для сервиса, активно ходящего к одному upstream. Поднимать. - **Новый `http.Client{}` на запрос** = новый Transport = новый пул каждый раз. Шарьте клиент. - **Незакрытое/недочитанное Body** → соединение не возвращается в пул, эффективно "утечка" и потеря keep-alive. - **DNS не подхватывается пулом**: keep-alive соединение живёт со старым IP даже после смены DNS. Лечится `IdleConnTimeout`/`ConnMaxLifetime` или принудительным реконнектом. - **`Client.Timeout` vs контекст**: `Timeout` покрывает весь запрос включая чтение тела; для гранулярности используйте `req.WithContext(ctx)`. Без таймаутов горутины виснут на мёртвых пирах. - **HTTP/2 и пул**: один h2-коннект мультиплексирует много запросов → `MaxConnsPerHost`/idle ведут себя иначе; один коннект может стать узким местом (см. h2 балансировку). - **БД: `MaxOpenConns` × число инстансов** должно влезать в лимит соединений сервера БД (`max_connections` Postgres). Частая авария при масштабировании реплик/подов. - **PgBouncer / внешний пул**: при transaction-pooling нельзя использовать prepared statements/сессионные фичи; настройки Go-пула должны это учитывать. - **`SetConnMaxIdleTime` появился позже** (Go 1.15) — на старых версиях только Lifetime. ## Вопросы на собеседовании **В:** Зачем нужен пул соединений? **О:** Переиспользовать дорогие соединения (TCP+TLS handshake, slow start) вместо создания на каждый запрос; снизить латентность, нагрузку на CPU и сеть, избежать исчерпания эфемерных портов и накопления TIME_WAIT. **В:** Почему важно закрывать и дочитывать resp.Body в Go? **О:** Соединение возвращается в keep-alive пул только если тело полностью прочитано и закрыто — иначе Go не знает границу сообщения и закрывает соединение. Незакрытое Body = потеря переиспользования + утечка FD/горутин. **В:** Что не так с `MaxIdleConnsPerHost = 2` по умолчанию? **О:** Под нагрузкой к одному хосту создаётся много соединений, но кэшируется только 2 idle; остальные после запроса закрываются и пересоздаются → постоянные handshake и TIME_WAIT. Для сервиса с одним upstream это надо поднимать. **В:** Почему нельзя создавать http.Client на каждый запрос? **О:** Каждый новый клиент (без явного общего Transport) создаёт новый Transport со своим пулом → соединения не переиспользуются между запросами. Клиент/транспорт надо шарить на всё приложение. **В:** Зачем `SetConnMaxLifetime` для БД? **О:** Принудительно закрывать и пересоздавать соединения, чтобы подхватывать DNS/топологические изменения (failover, новый мастер), ребалансировать через load balancer и обходить серверные таймауты на простой. Без него пул вечно держит старые соединения. **В:** Что произойдёт, если MaxOpenConns мал, а параллелизм высок? **О:** Горутины блокируются в ожидании свободного соединения (видно в `db.Stats().WaitCount/WaitDuration`), растёт latency, возможны таймауты по контексту. Надо балансировать MaxOpenConns с лимитом сервера БД и реальным параллелизмом. **В:** Как диагностировать утечку соединений? **О:** `db.Stats()` (InUse растёт и не падает), рост established-соединений (`ss`, `lsof`), "too many open files", pprof горутин висящих на получении соединения. Искать незакрытые Body/rows/tx и отсутствие таймаутов. **В:** Соединения в пуле держат старый IP после failover. Почему и как лечить? **О:** Keep-alive соединение переживает смену DNS — пул не перерезолвит, пока соединение живо. Лечится `IdleConnTimeout`/`ConnMaxLifetime`, ограничением времени жизни, либо клиентской балансировкой/health-checks с реконнектом. ## На что копают на senior+ - Взаимодействие пула с DNS-TTL и failover; почему DNS-балансировка не работает поверх keep-alive и как решать (lifetime, клиентский LB). - Расчёт `MaxOpenConns` под `max_connections` БД при N подах/репликах; роль PgBouncer (session/transaction/statement pooling) и ограничения каждого режима. - Поведение пула под HTTP/2: один мультиплексированный коннект, влияние на throughput и балансировку, `ReadIdleTimeout`/h2 health pings. - Тонкости возврата соединения в пул в Go: что считается "успешным" завершением, как `resp.Body.Close()` без drain всё равно может закрыть коннект. - Backpressure через `MaxConnsPerHost` как защита upstream от перегрузки; trade-off с латентностью (запросы ждут). - Метрики и SLO: connection wait time, pool saturation, churn rate как сигналы неправильной конфигурации. - Таймауты на всех уровнях (Dial, TLS handshake, response header, body read, общий) и почему один общий `Client.Timeout` недостаточен для стриминговых/долгих ответов.