Оглавление

  1. Концепция Context
  2. Паттерн Pipeline (Конвейер)
  3. Масштабирование: Fan-Out и Fan-In
  4. Механизмы синхронизации и Graceful Shutdown
  5. Итоги и нюансы

1. Концепция Context

Context — один из важнейших интерфейсов в Go (второй по популярности после error). Он служит для управления жизненным циклом запросов и передачи метаданных.

Проблема и мотивация

  • Сквозные данные (Request-scoped data): Передача информации (ID трассировки, IP-адрес, данные аутентификации) через все слои приложения без изменения сигнатур бизнес-функций.
  • Управление отменой и таймаутами: Необходимость немедленно прекратить работу всех горутин в цепочке вызовов, если клиент закрыл соединение или истекло время ожидания. Это предотвращает утечки ресурсов.

Интерфейс context.Context

Интерфейс содержит четыре метода:

  • Done() <-chan struct{}: Возвращает канал, который закрывается при отмене контекста. Это основной сигнал для завершения работы горутин.
  • Err() error: Возвращает причину отмены (context.Canceled или context.DeadlineExceeded).
  • Deadline() (deadline time.Time, ok bool): Возвращает время автоматической отмены контекста.
  • Value(key any) any: Позволяет извлекать сквозные данные.

Создание и иерархия контекстов

Контексты строятся по принципу дерева:

  • Корневые контексты:
    • context.Background(): Пустой контекст, никогда не отменяется. Используется в main или начале запроса.
    • context.TODO(): Заглушка, если контекст еще не определен.
  • Дочерние контексты (Декораторы):
    • context.WithCancel(parent): Возвращает контекст и функцию cancel().
    • context.WithTimeout(parent, duration): Автоматическая отмена через указанное время.
    • context.WithDeadline(parent, time): Автоматическая отмена в конкретный момент времени.
    • context.WithValue(parent, key, value): Добавление метаданных.

Лучшие практики использования

  • Контекст всегда передается первым параметром функции.
  • Всегда вызывайте cancel() (через defer), чтобы освободить ресурсы таймеров и горутин, даже если операция завершилась успешно.
  • Используйте функции с суффиксом Context (например, http.NewRequestWithContext), если они доступны в стандартной библиотеке.

2. Паттерн Pipeline (Конвейер)

Pipeline — паттерн для организации конкурентного кода в горизонтальную структуру, где независимые задачи (горутины) связаны каналами.

Аналогия и структура

  • Цеха (Stages): Независимые горутины-обработчики.
  • Конвейерные ленты (Channels): Каналы, передающие данные между этапами.

Анатомия этапа (Stage)

Этап — это функция, которая:

  1. Принимает данные из входного канала (<-chan).
  2. Выполняет обработку.
  3. Отправляет результат в выходной канал (chan<-).

Использование направленных каналов (<-chan и chan<-) повышает безопасность кода, предотвращая ошибочные операции чтения/записи на уровне компиляции.

Типы этапов

  • Источник (Generator/Source): Создает данные (чтение файла, генерация чисел). Нет входного канала. Принимает Context для отмены.
  • Обработчик (Processor): Промежуточное звено. Имеет вход и выход.
  • Приемник (Sink): Конечная точка. Часто роль приемника выполняет main, читая данные из финального канала.

Правила корректного завершения

Чтобы избежать deadlock и утечек:

  1. Этап должен завершаться, когда закрывается ВХОДНОЙ канал. Это реализуется через for range по каналу.
  2. Этап должен закрывать свой ВЫХОДНОЙ канал при выходе. Это сигнализирует следующему этапу о завершении данных.

3. Масштабирование: Fan-Out и Fan-In

Если один из этапов пайплайна работает медленно (“узкое место”), его необходимо масштабировать.

Fan-Out (Распределение)

  • Суть: Запуск нескольких горутин-обработчиков для одного входного канала.
  • Механизм: Несколько горутин конкурентно читают из одного канала. Одна задача достается только одному свободному “рабочему”. Код самого обработчика при этом не меняется.

Fan-In (Объединение / Merge)

  • Суть: Сбор результатов из множества каналов в один общий канал.
  • Реализация через sync.WaitGroup:
    1. Создается общий выходной канал.
    2. Запускается по одной горутине на каждый входящий канал для пересылки данных в общий выход.
    3. sync.WaitGroup отслеживает завершение всех пересыльщиков.
    4. Отдельная горутина ждет через wg.Wait() и закрывает общий канал.

Буферизированные каналы

  • make(chan T, N): Позволяет отправителю записать N элементов без блокировки.
  • Назначение: Сглаживание пиков производительности. Быстрый генератор может наполнить буфер, пока медленный обработчик занят, минимизируя простои системы.

4. Механизмы синхронизации и Graceful Shutdown

Синхронизация через каналы

Главная горутина (main) не завершается раньше времени благодаря циклу for range по финальному каналу. Операция чтения из канала является блокирующей: main “спит”, пока в канал поступают данные или пока он не будет закрыт.

Цепочка завершения (Пошаговый разбор)

При вызове cancel() или нажатии Ctrl+C:

  1. Источник (generate): Видит ctx.Done(), выходит из цикла и выполняет defer close(in).
  2. Обработчик (process): Цикл for range in завершается, когда канал in пустеет и закрывается. Выполняется defer close(out).
  3. Приемник (main): Цикл for range out завершается после вычитки последних данных. Программа штатно завершается.

В основе лежит механизм проверки состояния канала: v, ok := <-ch. Когда ok == false, этап понимает, что данных больше не будет.

5. Итоги и нюансы

  • Типизация каналов: Буфер (capacity) не является частью типа канала. Функция, принимающая chan int, может работать как с буферизированным, так и с обычным каналом.
  • Направленность: Тип канала определяется направлением (чтение/запись) и типом данных (например, <-chan int).
  • Context: Всегда передается первым параметром. В современных библиотеках Go функции с поддержкой контекста имеют суффикс ...Context.
  • Масштабируемость: Паттерны Fan-Out/Fan-In позволяют распараллеливать тяжелые вычисления, увеличивая пропускную способность пайплайна в N раз.