Ответ
Для защиты приложения от медленных ответов внешних систем, включая базу данных, используется несколько ключевых подходов:
1. Контекст с таймаутом (context.WithTimeout)
Это основной механизм в Go для контроля времени выполнения операций. context.Context передается во все функции, выполняющие I/O операции (например, запросы к БД, HTTP-запросы).
-
Принцип работы: Мы создаем контекст с ограниченным временем жизни. Если операция не завершается за указанное время, контекст отменяется, и функция возвращает ошибку
context.DeadlineExceeded. Это позволяет приложению не ждать бесконечно и освободить ресурсы. -
Пример:
// Устанавливаем таймаут в 3 секунды для запроса к БД ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second) defer cancel() // Важно вызвать cancel, чтобы освободить ресурсы
var user User err := db.QueryRowContext(ctx, "SELECT id, name FROM users WHERE id = ?", userID).Scan(&user.ID, &user.Name)
if err != nil { // Проверяем, была ли ошибка вызвана именно таймаутом if errors.Is(err, context.DeadlineExceeded) { log.Println("Query to database timed out") // Здесь можно вернуть клиенту ошибку 504 Gateway Timeout return } log.Printf("Database query failed: %v", err) return }
**2. Настройка пула соединений (Connection Pool Tuning)**
Пакет `database/sql` управляет пулом соединений. Правильная настройка помогает избежать исчерпания ресурсов как на стороне приложения, так и на стороне БД.
* `db.SetMaxOpenConns(n)`: Ограничивает общее количество открытых соединений с БД.
* `db.SetMaxIdleConns(n)`: Ограничивает количество соединений, которые могут простаивать в пуле.
* `db.SetConnMaxLifetime(d)`: Устанавливает максимальное время жизни соединения, чтобы избежать проблем с устаревшими или закрытыми со стороны сети соединениями.
**3. Асинхронная обработка**
Если операция заведомо долгая (например, генерация сложного отчета), ее не следует выполнять в рамках синхронного HTTP-запроса. Такую задачу лучше поместить в очередь (например, **RabbitMQ** или **NATS**) и обработать в фоновом воркере. Пользователю же можно сразу вернуть ответ, что задача принята в обработку.Ответ 18+ 🔞
Давай разберём эту тему, как защитить приложение от тормознутых ответов от внешних систем, особенно от базы данных. А то бывает, запросил что-то, а база ушла в запой и думает, блядь, полчаса, пока тебе один юзернейм подобрать. Клиент уже уснул, ресурсы все заняты — пиздец, а не сервис.
1. Контекст с таймаутом (context.WithTimeout)
Это, блядь, наш главный инструмент в Go, чтобы поставить на место любую долбоёбину, которая тянет время. context.Context ты суёшь во все функции, которые что-то читают или пишут куда-то (в БД, по HTTP, в файл — куда угодно).
-
Как работает: Создаёшь контекст с ограниченным сроком годности, как молоко. Если операция за этот срок не сдохла и не завершилась — контекст отменяется, и функция возвращает ошибку
context.DeadlineExceeded. Приложение не висит, как идиот, а говорит: «Всё, пошёл ты нахуй, я ждать не буду», и ресурсы освобождает. -
Смотри, как это выглядит в коде:
// Ставим таймаут в 3 секунды на запрос к базе. Больше — не спортивно. ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second) defer cancel() // Это ОБЯЗАТЕЛЬНО, иначе ресурсы потекут, как из дырявого ведра
var user User err := db.QueryRowContext(ctx, "SELECT id, name FROM users WHERE id = ?", userID).Scan(&user.ID, &user.Name)
if err != nil { // Проверяем, а не потому ли ошибка, что время вышло? if errors.Is(err, context.DeadlineExceeded) { log.Println("Запрос к базе данных сдох по таймауту, ебать его в сраку") // Тут можно отправить клиенту вежливую 504 Gateway Timeout return } log.Printf("Запрос к базе данных обосрался: %v", err) return }
**2. Настройка пула соединений (Connection Pool Tuning)**
Пакет `database/sql` сам управляет пулом соединений, но если его не настроить — он будет вести себя как распиздяй. Надо ограничить его аппетиты, чтобы он не сожрал все ресурсы и у тебя, и у базы данных.
* `db.SetMaxOpenConns(n)`: Сколько максимум соединений можно открыть с БД одновременно. Больше — не значит лучше, а то база захлебнётся.
* `db.SetMaxIdleConns(n)`: Сколько соединений могут просто валяться в пуле без дела. Держать много — тоже ресурсы жрут.
* `db.SetConnMaxLifetime(d)`: Максимальное время жизни одного соединения. Чтобы убивать старые, потрёпанные жизнью коннекты, которые уже ни на что не годны.
**3. Асинхронная обработка**
Если задача такая, что её выполнение — это как ждать, пока черепаха через дорогу переползёт (например, сгенерировать хуёвый отчёт на 500 страниц), то делать это в рамках HTTP-запроса — идиотизм, ёпта. Клиент просто отвалится по таймауту.
Такую задачу надо, блядь, **выкинуть в очередь** (типа RabbitMQ или NATS) и забыть. Пусть её там в фоне обрабатывает какой-нибудь воркер, а пользователю сразу сказать: «Ладно, мудила, задача принята, иди отсюда, жди уведомления». И все довольны, и сервер не падает.