> Может ли приложение работать в нескольких процессах? (Go)

Короткий ответ

Да, приложение может работать в нескольких процессах, и в Go это штатный сценарий. Один процесс - это изолированное адресное пространство с собственными ресурсами, а несколько процессов позволяют масштабироваться горизонтально, повышать отказоустойчивость и обходить ограничения одного ядра. В Go для этого используются стандартные механизмы ОС: fork/exec, а также встроенные средства для межпроцессного взаимодействия - сокеты, каналы, разделяемая память. Главное - правильно спроектировать обмен данными и управление состоянием.

Подробное объяснение

Многопроцессная архитектура - это фундаментальный паттерн в системном программировании. В отличие от многопоточности, где потоки делят память внутри одного процесса, процессы полностью изолированы: у каждого своё виртуальное адресное пространство, свои файловые дескрипторы и свои счётчики. Это даёт два ключевых преимущества: устойчивость к сбоям (падение одного процесса не убивает остальные) и возможность распределения нагрузки по нескольким ядрам или даже машинам.

В Go многопроцессность реализуется через os/exec для запуска дочерних процессов, а для коммуникации между ними - через:

• TCP/UDP сокеты (самый распространённый способ, особенно для микросервисов)
• Unix domain sockets (быстрее, чем TCP, для локальной связи)
• именованные каналы (FIFO)
• разделяемую память через mmap (редко в Go, чаще через cgo)
• стандартный ввод/вывод (stdin/stdout) для простых конвейеров

Важный нюанс: в Go нет fork() как в C. Вместо этого используется exec.Command, который создаёт новый процесс с чистым окружением. Это проще и безопаснее, но означает, что дочерний процесс не наследует состояние родителя - всё нужно передавать явно.

Ключевой trade-off: многопроцессность сложнее в управлении состоянием. Если несколько процессов пишут в одну базу данных или файл, нужны блокировки или транзакции. Если нужно шарить кэш - придётся использовать внешний store (Redis, etcd) или реализовывать распределённую блокировку. Зато изоляция ошибок и возможность независимого деплоя часто перевешивают эти сложности.

На практике

В реальных Go-приложениях многопроцессность встречается в трёх типичных сценариях:

1. Worker pool: один главный процесс раздаёт задачи дочерним воркерам через очередь (например, NATS или RabbitMQ). Каждый воркер - отдельный процесс, который можно масштабировать независимо.

2. Sidecar pattern: основное приложение запускает вспомогательный процесс (например, log collector или metrics exporter) рядом с собой, общаясь через localhost.

3. Graceful restart: старый процесс передаёт слушающий сокет новому через ExtraFiles в exec.Cmd, чтобы не было разрыва соединений.

На практике важно помнить про сигналы: SIGTERM нужно перехватывать и корректно завершать дочерние процессы, иначе останутся зомби. Также стоит использовать context для отмены и таймаутов при запуске дочерних процессов.

Пример кода

GO
package main

import (
    "context"
    "fmt"
    "os/exec"
    "time"
)

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()

    // Запускаем дочерний процесс с передачей аргументов
    cmd := exec.CommandContext(ctx, "python3", "-c", "print('hello from child')")

    // Перехватываем stdout дочернего процесса
    output, err := cmd.Output()
    if err != nil {
        fmt.Printf("ошибка: %v\n", err)
        return
    }

    fmt.Printf("дочерний процесс вернул: %s", output)
}

Для передачи файлового дескриптора (например, сокета) при graceful restart:

GO
// Родительский процесс передаёт слушающий сокет
listener, _ := net.Listen("tcp", ":8080")
file, _ := listener.(*net.TCPListener).File()

cmd := exec.Command("./child")
cmd.ExtraFiles = []*os.File{file} // fd 3 в дочернем процессе
cmd.Start()

Как отвечать на собеседовании

Начни с прямого ответа "да", затем структурируй ответ по трём блокам: что такое процесс, зачем нужно несколько процессов, какие механизмы в Go. Обязательно упомяни trade-off между изоляцией и сложностью синхронизации. Приведи конкретный пример из практики - например, как ты запускал воркеры или делал graceful restart. Если спросят про производительность, скажи, что межпроцессное взаимодействие дороже, чем межпоточное, но в Go это компенсируется простотой модели и возможностью горизонтального масштабирования. Не углубляйся в детали реализации, если не просят - покажи понимание картины в целом.

Что проверяет интервьюер

Интервьюер оценивает:

• понимание разницы между процессом и потоком
• знание конкретных механизмов IPC в Go
• умение видеть trade-off между изоляцией и накладными расходами
• способность проектировать систему с учётом многопроцессности (как управлять состоянием, как обрабатывать сбои)
• практический опыт: умеешь ли ты запускать дочерние процессы, передавать дескрипторы, обрабатывать сигналы

Типичные ошибки

• Путать процессы и потоки, говорить "процесс" когда имеется в виду "поток"
• Утверждать, что в Go нельзя создавать процессы (можно, через os/exec)
• Забывать про изоляцию памяти - думать, что дочерний процесс видит переменные родителя
• Не упоминать необходимость синхронизации при доступе к общим ресурсам (БД, файлы)
• Предлагать разделяемую память как основной способ IPC, хотя в Go это редкость и сложно
• Игнорировать обработку сигналов и корректное завершение дочерних процессов