Ответ
Межпроцессное взаимодействие (IPC) — это набор механизмов, позволяющих процессам обмениваться данными и синхронизировать свои действия. В контексте Go и бэкенда их можно разделить на несколько категорий.
1. Взаимодействие в рамках одного приложения (между горутинами)
Хотя это не является IPC в строгом смысле (т.к. происходит внутри одного процесса), это ключевой аспект конкурентности в Go.
- Каналы (Channels): Идиоматичный и безопасный способ общения между горутинами. Реализует принцип "не общайтесь через разделяемую память; разделяйте память через общение".
2. Взаимодействие между процессами на одной машине
- Unix-сокеты (Unix Domain Sockets): Работают как TCP-сокеты, но используют файловую систему вместо сетевого стека. Более быстрые и безопасные для локального IPC.
- Пайпы (Pipes):
- Анонимные (
os.Pipe): Однонаправленный канал данных между родительским и дочерним процессами. - Именованные (FIFO): Позволяют общаться несвязанным процессам через специальный файл в файловой системе.
- Анонимные (
- Разделяемая память (Shared Memory): Самый быстрый способ, так как процессы работают с одной и той же областью памяти. Требует сложной ручной синхронизации (например, с помощью мьютексов). В Go реализуется через системные вызовы (
mmap). - Сигналы (Signals): Простой способ отправки уведомлений процессам (например,
syscall.SIGTERM,syscall.SIGINT). Не подходят для передачи данных.
3. Взаимодействие между процессами по сети (распределенные системы)
Это наиболее частый сценарий в бэкенд-разработке.
- TCP/UDP сокеты (
net): Фундаментальный механизм для любого сетевого взаимодействия. TCP обеспечивает надежную доставку с установкой соединения, UDP — быструю доставку датаграмм без гарантий. - RPC (Remote Procedure Call):
net/rpc: Встроенный в стандартную библиотеку пакет для создания простых RPC-сервисов.- gRPC: Современный высокопроизводительный фреймворк от Google. Использует HTTP/2, Protocol Buffers для сериализации и поддерживает стриминг. Де-факто стандарт для коммуникации между микросервисами в Go.
- Веб-сервисы (HTTP API):
- REST: Архитектурный стиль, использующий стандартные HTTP-методы (
GET,POST,PUT,DELETE) для взаимодействия с ресурсами. Очень распространен. - GraphQL: Язык запросов для API, позволяющий клиентам запрашивать только те данные, которые им нужны.
- REST: Архитектурный стиль, использующий стандартные HTTP-методы (
- Очереди сообщений (Message Queues): Системы вроде NATS, RabbitMQ, Kafka. Обеспечивают асинхронное, отказоустойчивое взаимодействие между компонентами системы. Идеально подходят для событийно-ориентированной архитектуры.
Ответ 18+ 🔞
Да ты погляди, какие, блядь, распиздяйства творятся в мире процессов! Сидят они там, каждый в своей песочнице, как в крепости, блядь, а общаться-то хотят. Ну, как Герасим с барыней, только без топления Муму, надеюсь.
Вот смотри, есть у нас три этажа этого цирка.
Первый, для своих, внутри одной конторы (приложения). Тут горутины, эти шустрые суки, носятся. Им бы через общую память толкаться, как на рынке, но нет — умные дядьки придумали каналы. Всё по-пацански: «Не пизди в общей куче, а передавай записку через каналы». Красиво, чо.
Второй этаж — процессы на одной машине, как соседи по коммуналке. Тут уже веселее.
- Юникс-сокеты — это как трубка домофона между квартирами. Быстро, локально, в сеть не лезет.
- Папы (pipes), блядь, пайпы — анонимные, это как труба в стену к соседу, только в одну сторону. Именованные — уже как почтовый ящик у двери, любой может киннуть записку.
- Разделяемая память — это, сука, самый отчаянный способ. Представь: два процесса лезут в один холодильник. Скорость — овердохуища, но если не договориться (мьютексами там), то будет драка за последнюю сосиску. В Go это через
mmap, самому всё синхронизировать — тот ещё геморрой. - Сигналы — это как стук в дверь или кирпич в окно. «Эй, процесс, закругляйся!» (
SIGTERM). Для данных не годится, только для уведомлений.
Ну и третий, самый распиздяйский этаж — общение по сети, между серверами. Тут уже раздолье, блядь.
- TCP/UDP сокеты — основа основ. TCP — это как заказное письмо с уведомлением, всё долго, чинно. UDP — как крик в окно «Хули там?!» — быстро, но мог и не услышать.
- RPC (Удалённый Вызов Процедур). Во, звучит-то как! Ты как будто свою функцию вызываешь, а она, сука, на другом континенте выполняется.
- Стандартный
net/rpc— простой, как три копейки. - gRPC — это уже, блядь, бизнес-класс. На HTTP/2 летает, данные в бинарнике (
Protocol Buffers), ещё и стримы может гнать. Для микросервисов — просто песня, ёпта.
- Стандартный
- Веб-сервисы (HTTP API).
- REST — все его знают. Как общаешься с бюрократом: «Дай (GET) справку», «Прими (POST) заявление», «Измени (PUT) запись», «Удали (DELETE) всё нахуй». Стандартно, предсказуемо, иногда долго.
- GraphQL — это хитрая жопа. Клиент приходит и говорит: «Мне вот это, это и вот то, но только поля A и C, и в формате JSON, да побыстрее». Сервер пыхтит, но выдаёт ровно то, что просили, без лишнего.
- Очереди сообщений (NATS, RabbitMQ, Kafka) — это, блядь, чистая магия асинхронности. Один процесс крикнул в очередь «Событие!» и пошёл дальше пить кофе. Другие процессы подхватят, когда проснутся. Надёжно, масштабируемо, для событийных систем — просто вротберунчик.
Короче, инструментов — хуева туча. Выбирай по обстановке: быстро надо — разделяемая память, надёжно — TCP или gRPC, чтоб не зависеть — очереди. Главное — не выеби себе мозг сложностью там, где можно каналом обойтись.