5.5 🚫 Context и отмена операций

Context — это один из самых важных и фундаментальных пакетов в экосистеме Go, который решает ключевые проблемы управления жизненным циклом операций в современных приложениях. Этот механизм предоставляет элегантное решение для отмены длительных операций, установки таймаутов, передачи метаданных между функциями и контроля выполнения горутин.

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

🌟 Проблемы, которые решает Context

Проблема управления ресурсами

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

Каскадная отмена операций

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

Контроль времени выполнения

Долгоживущие операции могут заблокировать систему или создать плохой пользовательский опыт. Context предоставляет встроенные механизмы для установки таймаутов и дедлайнов.

Передача метаданных

В распределенных системах часто необходимо передавать сквозную информацию: идентификаторы запросов, данные аутентификации, метрики трассировки. Context предоставляет безопасный способ передачи таких данных.

💬 Реальный пример из практики
В высоконагруженном веб-сервисе один отмененный Context может сэкономить до 500MB памяти и десятки процессорных ядер, если операция включала загрузку больших файлов и сложные вычисления.

⚡ Архитектурные преимущества Context

Context в Go реализует паттерн “cancellation token”, но делает это более элегантно, чем многие другие языки. Он интегрирован в стандартную библиотеку и используется во всех современных Go пакетах: от net/http до database/sql.

Особенность Go Context в том, что он неизменяем (immutable) и формирует древовидную структуру. Когда вы создаете дочерний контекст, он наследует все свойства родителя, но может добавить свои собственные ограничения. Это создает мощную модель композиции, где отмена родительского контекста автоматически отменяет все дочерние.

Интеграция с экосистемой Go

Большинство стандартных библиотек Go поддерживают Context из коробки:

net/http - для HTTP запросов и серверов
database/sql - для работы с базами данных
os/exec - для выполнения внешних команд
context - множество утилит для создания и управления

Это означает, что изучив Context один раз, вы сможете эффективно использовать его во всей экосистеме Go.

🎯 Основы работы с Context

Context в Go основан на интерфейсе, который определяет четыре ключевых метода:

Done() - возвращает канал, который закрывается при отмене контекста
Err() - возвращает ошибку, объясняющую причину отмены
Deadline() - возвращает время, когда контекст должен быть отменен
Value(key) - возвращает значение, связанное с ключом

Типы Context

Существует несколько базовых типов контекстов:

Background Context - корневой контекст, который никогда не отменяется
TODO Context - заглушка для случаев, когда структура контекста еще не определена
WithCancel - контекст с ручной отменой
WithTimeout/WithDeadline - контекст с автоматической отменой по времени
WithValue - контекст для передачи данных

Создание и использование Context

Работа с Context начинается с понимания его основных паттернов. Самый простой пример — функция, которая может быть отменена через Context:

func doWork(ctx context.Context, name string) error {
    for i := 0; i < 5; i++ {
        select {
        case <-ctx.Done():
            return ctx.Err() // Возвращаем причину отмены
        default:
            fmt.Printf("%s: шаг %d\n", name, i+1)
            time.Sleep(1 * time.Second)
        }
    }
    return nil
}

Паттерн проверки отмены

Ключевой элемент здесь — конструкция select с проверкой ctx.Done(). Это канал, который закрывается при отмене контекста. Такая проверка должна выполняться регулярно в любой длительной операции.

Background vs WithCancel

Существует два основных способа создания контекста:

context.Background() — создает корневой контекст, который никогда не отменяется
context.WithCancel() — создает отменяемый контекст с функцией cancel

Когда вы вызываете cancel(), все операции, использующие этот контекст, получают сигнал к завершению.

В этом примере мы видим фундаментальные принципы работы с Context:

Проверка отмены: В цикле мы регулярно проверяем ctx.Done() через select, что позволяет немедленно прервать работу при получении сигнала отмены.
Graceful shutdown: Функция не просто завершается, а возвращает осмысленную ошибку через ctx.Err(), что позволяет вызывающему коду понять причину остановки.
Неблокирующая проверка: Конструкция select с default позволяет проверить отмену без блокировки выполнения.

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

⏰ Управление временем с Context

Одна из самых мощных возможностей Context — автоматическое управление временем выполнения операций. В продакшене это критически важно: без таймаутов одна медленная операция может заблокировать весь сервис.

WithTimeout vs WithDeadline

Go предоставляет два способа ограничения времени:

WithTimeout - отмена через определенный интервал от текущего момента
WithDeadline - отмена в конкретное время

WithTimeout идеален для ограничения продолжительности операции, а WithDeadline - когда у вас есть жесткий временной лимит (например, до конца рабочего дня).

Практическое применение таймаутов

// Операция с таймаутом
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

// Операция с дедлайном
deadline := time.Now().Add(10 * time.Second)
ctx, cancel := context.WithDeadline(context.Background(), deadline)
defer cancel()

Стратегии установки таймаутов

Короткие таймауты (1-5 секунд):

API вызовы к внешним сервисам
Запросы к базе данных
HTTP запросы

Средние таймауты (30-60 секунд):

Обработка файлов
Сложные вычисления
Batch операции

Длинные таймауты (5-30 минут):

Резервное копирование
Миграции данных
ML модели

Обработка разных типов ошибок

Context может быть отменен по трем причинам:

context.Canceled - ручная отмена через cancel()
context.DeadlineExceeded - превышение таймаута
Родительский контекст отменен - каскадная отмена

Проверка типа ошибки позволяет реагировать соответственно:

if err := ctx.Err(); err != nil {
    switch err {
    case context.Canceled:
        log.Println("Операция отменена пользователем")
    case context.DeadlineExceeded:
        log.Println("Превышен таймаут операции")
    }
}

Паттерны работы с таймаутами

Этот пример демонстрирует важные аспекты временного управления:

Превентивная отмена: Context автоматически отменяется при превышении лимита времени, предотвращая зависание операций.
Каскадное наследование: Дочерние контексты наследуют ограничения родительских, но могут устанавливать более строгие лимиты.
Детализированный контроль: WithDeadline позволяет синхронизировать операции с внешними событиями (например, окончанием рабочего дня или закрытием торговой сессии).

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

📦 Передача данных через Context

Context предоставляет безопасный механизм передачи метаданных между функциями без явного добавления параметров в сигнатуры. Это особенно полезно в веб-приложениях, где информация о пользователе, запросе или сессии должна быть доступна на всех уровнях обработки.

Принципы работы с данными в Context

При работе с Context.Value важно соблюдать несколько правил:

Используйте типизированные ключи для избежания коллизий
Храните только immutable данные
Не передавайте через Context обязательные параметры функций
Используйте для метаданных: ID запросов, токены, настройки трассировки

WithValue для передачи данных

Передача данных через Context требует особой осторожности. Основные принципы:

// Типизированные ключи предотвращают коллизии
type contextKey string
const UserIDKey contextKey = "user_id"

// Helper функции для type safety
func GetUserID(ctx context.Context) (int, bool) {
    userID, ok := ctx.Value(UserIDKey).(int)
    return userID, ok
}

func SetUserID(ctx context.Context, userID int) context.Context {
    return context.WithValue(ctx, UserIDKey, userID)
}

Что передавать через Context

Подходящие данные:

Request ID для трассировки
User ID и session данные
Токены аутентификации
Trace spans для мониторинга
Настройки локализации

Неподходящие данные:

Обязательные параметры функций
Большие объекты данных
Mutable состояние
Бизнес-логика

Паттерн middleware в веб-приложениях

В веб-приложениях Context часто используется для передачи данных между middleware:

// Middleware добавляет request ID
func requestIDMiddleware(next http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        requestID := generateRequestID()
        ctx := context.WithValue(r.Context(), RequestIDKey, requestID)
        next(w, r.WithContext(ctx))
    }
}

// Функция извлекает request ID из любого места в коде
func logWithRequestID(ctx context.Context, message string) {
    requestID, _ := ctx.Value(RequestIDKey).(string)
    log.Printf("[%s] %s", requestID, message)
}

Такой подход обеспечивает сквозную трассируемость запросов без необходимости передавать request ID явно через все функции.

Архитектура передачи данных

Этот пример показывает типичную архитектуру enterprise-приложения:

Типизированные ключи: Использование contextKey типа предотвращает конфликты между разными частями приложения.
Helper функции: GetUserID, SetUserID инкапсулируют логику работы с контекстом и обеспечивают type safety.
Цепочка обработки: Данные из контекста доступны во всей цепочке вызовов функций без изменения их сигнатур.
Разделение ответственности: Каждая функция извлекает только те данные, которые ей нужны.

Такой подход особенно ценен в микросервисах, где request ID может передаваться через десятки функций и сервисов для трассировки.

🌐 Context в HTTP серверах

В веб-разработке Context становится основой архитектуры. Каждый HTTP запрос создает свой контекст, который живет на протяжении всего времени обработки. Это позволяет элегантно решать задачи аутентификации, логирования, мониторинга и отмены операций.

Архитектурные паттерны HTTP + Context

Современные Go веб-приложения строятся вокруг middleware архитектуры, где каждый middleware может:

Добавлять данные в контекст
Устанавливать таймауты для операций
Логировать действия пользователей
Проверять права доступа

Context становится “позвоночником” приложения, связывающим все уровни обработки.

Middleware архитектура с Context

Современные веб-серверы на Go строятся как цепочка middleware, где каждый обогащает контекст:

// Request ID для трассировки
func requestIDMiddleware(next http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        requestID := generateRequestID()
        ctx := context.WithValue(r.Context(), RequestIDKey, requestID)
        w.Header().Set("X-Request-ID", requestID)
        next(w, r.WithContext(ctx))
    }
}

// Аутентификация пользователя
func authMiddleware(next http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        userID, err := authenticateUser(r.Header.Get("Authorization"))
        if err != nil {
            http.Error(w, "Unauthorized", http.StatusUnauthorized)
            return
        }
        ctx := context.WithValue(r.Context(), UserIDKey, userID)
        next(w, r.WithContext(ctx))
    }
}

Обработка долгих операций

В HTTP обработчиках Context особенно важен для:

1. Таймауты операций:

func dataHandler(w http.ResponseWriter, r *http.Request) {
    // Таймаут для запроса к БД
    dbCtx, cancel := context.WithTimeout(r.Context(), 5*time.Second)
    defer cancel()
    
    data, err := queryDatabase(dbCtx, "SELECT * FROM users")
    if err == context.DeadlineExceeded {
        http.Error(w, "Database timeout", http.StatusRequestTimeout)
        return
    }
}

2. Отмена при отключении клиента:

func slowHandler(w http.ResponseWriter, r *http.Request) {
    select {
    case <-time.After(10 * time.Second):
        // Обычная обработка
    case <-r.Context().Done():
        // Клиент отключился - прекращаем работу
        return
    }
}

Композиция middleware

Middleware можно элегантно комбинировать:

// Публичные эндпоинты
http.HandleFunc("/", 
    requestID(logging(homeHandler)))

// Защищенные эндпоинты  
http.HandleFunc("/api/data",
    requestID(logging(auth(rateLimiting(dataHandler)))))

Каждый middleware добавляет свою функциональность, не затрагивая остальные, что создает гибкую и тестируемую архитектуру.

🔄 Context в горутинах

Context особенно важен при работе с горутинами, поскольку позволяет координировать их выполнение и graceful shutdown.

Паттерн Worker Pool с Context

type Worker struct {
    id   int
    name string
}

func (w *Worker) processTask(ctx context.Context, taskID int) error {
    select {
    case <-time.After(time.Duration(taskID) * time.Second):
        fmt.Printf("Worker %d: завершил задачу %d\n", w.id, taskID)
        return nil
    case <-ctx.Done():
        fmt.Printf("Worker %d: задача %d отменена\n", w.id, taskID)
        return ctx.Err()
    }
}

func (w *Worker) run(ctx context.Context, tasks <-chan int, wg *sync.WaitGroup) {
    defer wg.Done()
    
    for {
        select {
        case task, ok := <-tasks:
            if !ok {
                return // Канал закрыт
            }
            w.processTask(ctx, task)
            
        case <-ctx.Done():
            return // Контекст отменен
        }
    }
}

Архитектурные преимущества

1. Централизованная отмена: Один вызов cancel() останавливает все горутины

2. Graceful shutdown: Горутины завершают текущую работу и корректно выходят

3. Timeout для группы операций:

ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()

// Все горутины автоматически остановятся через 30 секунд

4. Каскадная отмена: Дочерние контексты автоматически отменяются при отмене родительского

Практические сценарии

Batch обработка данных:

Обработка файлов в parallel
Отмена всей batch при ошибке
Timeout для всей операции

Микросервисы:

Распределенные запросы
Circuit breaker паттерн
Graceful shutdown сервисов

Real-time обработка:

WebSocket соединения
Event streaming
Monitoring и метрики

🎯 HTTP клиент с Context

Context критически важен при работе с HTTP клиентами - он позволяет контролировать время выполнения запросов и отменять их при необходимости.

Создание Context-aware HTTP клиента

type APIClient struct {
    baseURL    string
    httpClient *http.Client
}

func (c *APIClient) makeRequest(ctx context.Context, method, path string) error {
    url := c.baseURL + path
    
    // Создаем запрос с контекстом
    req, err := http.NewRequestWithContext(ctx, method, url, nil)
    if err != nil {
        return err
    }
    
    // Выполняем запрос - он автоматически отменится при отмене контекста
    resp, err := c.httpClient.Do(req)
    if err != nil {
        return err
    }
    defer resp.Body.Close()
    
    return nil
}

Ключевые преимущества

1. Автоматическая отмена запросов: При отмене контекста HTTP запрос немедленно прерывается, освобождая сетевые ресурсы.

2. Таймауты на уровне операций:

// Каждый запрос с индивидуальным таймаутом
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

user, err := client.GetUser(ctx, userID)

3. Batch операции с общим лимитом:

// Группа запросов с общим таймаутом
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()

for _, userID := range userIDs {
    if ctx.Err() != nil {
        break // Контекст отменен
    }
    user, err := client.GetUser(ctx, userID)
    // Обработка результата
}

Продвинутые паттерны

Circuit Breaker с Context:

func (c *APIClient) GetUserWithCircuitBreaker(ctx context.Context, userID int) error {
    if c.circuitBreaker.IsOpen() {
        return errors.New("circuit breaker is open")
    }
    
    return c.makeRequest(ctx, "GET", fmt.Sprintf("/users/%d", userID))
}

Retry с backoff:

func (c *APIClient) GetUserWithRetry(ctx context.Context, userID int) error {
    for attempt := 1; attempt <= 3; attempt++ {
        if ctx.Err() != nil {
            return ctx.Err()
        }
        
        err := c.makeRequest(ctx, "GET", fmt.Sprintf("/users/%d", userID))
        if err == nil {
            return nil
        }
        
        // Exponential backoff
        delay := time.Duration(attempt*attempt) * time.Second
        select {
        case <-time.After(delay):
            continue
        case <-ctx.Done():
            return ctx.Err()
        }
    }
    return errors.New("max retries exceeded")
}

Параллельные запросы:

func (c *APIClient) GetMultipleUsers(ctx context.Context, userIDs []int) {
    var wg sync.WaitGroup
    results := make(chan UserResult, len(userIDs))
    
    for _, userID := range userIDs {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            user, err := c.GetUser(ctx, id)
            results <- UserResult{User: user, Error: err}
        }(userID)
    }
    
    wg.Wait()
    close(results)
}

🛡️ Лучшие практики Context

1. Всегда передавай Context первым параметром

// ✅ Правильно
func ProcessUser(ctx context.Context, userID int) error

// ❌ Неправильно
func ProcessUser(userID int, ctx context.Context) error

2. Не храни Context в структурах

// ❌ Неправильно
type Service struct {
    ctx context.Context
}

// ✅ Правильно
type Service struct {
    // другие поля
}

func (s *Service) DoWork(ctx context.Context) error

3. Используй типизированные ключи

// ✅ Правильно
type contextKey string
const UserIDKey contextKey = "user_id"

// ❌ Неправильно
ctx = context.WithValue(ctx, "user_id", 123)

4. Не игнорируй отмену

func longOperation(ctx context.Context) error {
    for i := 0; i < 1000; i++ {
        // ✅ Проверяем отмену
        select {
        case <-ctx.Done():
            return ctx.Err()
        default:
        }
        
        // выполняем работу
    }
    return nil
}

🧠 Проверь себя

Зачем нужен Context в Go?
Как создать Context с таймаутом?
Как правильно передавать данные через Context?
Почему Context должен быть первым параметром функции?
Как обрабатывать отмену операций в горутинах?

📌 Главное из главы

Context управляет жизненным циклом операций и передачей данных
context.WithCancel() для ручной отмены
context.WithTimeout() для автоматической отмены по времени
context.WithValue() для передачи данных между функциями
ctx.Done() сигналит об отмене операции
Всегда проверяй ctx.Done() в длительных операциях
Context первый параметр в функциях по конвенции

🌟 Проблемы, которые решает Context#

Проблема управления ресурсами#

Каскадная отмена операций#

Контроль времени выполнения#

Передача метаданных#

⚡ Архитектурные преимущества Context#

Интеграция с экосистемой Go#

🎯 Основы работы с Context#

Типы Context#

Создание и использование Context#

Паттерн проверки отмены#

Background vs WithCancel#

⏰ Управление временем с Context#

WithTimeout vs WithDeadline#

Практическое применение таймаутов#

Стратегии установки таймаутов#

Обработка разных типов ошибок#

Паттерны работы с таймаутами#

📦 Передача данных через Context#

Принципы работы с данными в Context#

WithValue для передачи данных#

Что передавать через Context#

Паттерн middleware в веб-приложениях#

Архитектура передачи данных#

🌐 Context в HTTP серверах#

Архитектурные паттерны HTTP + Context#

Middleware архитектура с Context#

Обработка долгих операций#

Композиция middleware#

🔄 Context в горутинах#

Паттерн Worker Pool с Context#

Архитектурные преимущества#

Практические сценарии#

🎯 HTTP клиент с Context#

Создание Context-aware HTTP клиента#

Ключевые преимущества#

Продвинутые паттерны#

🛡️ Лучшие практики Context#

1. Всегда передавай Context первым параметром#

2. Не храни Context в структурах#

3. Используй типизированные ключи#

4. Не игнорируй отмену#

🧠 Проверь себя#

📌 Главное из главы#