В программировании **общение между процессами** называется **межпроцессным взаимодействием** (Inter-Process Communication, **IPC**). Оно необходимо, потому что процессы изолированы друг от друга: у каждого — собственное адресное пространство и ресурсы. Ниже — систематизированный обзор **как именно процессы обмениваются данными**, от базовых механизмов до прикладных архитектур. --- ## 1. Почему IPC вообще нужен Процессы взаимодействуют, когда требуется: * передавать данные (результаты вычислений, события) * координировать действия (синхронизация) * строить распределённые системы (backend ↔ worker ↔ frontend) * изолировать компоненты (безопасность, отказоустойчивость) --- ## 2. Основные модели IPC ### 2.1 Обмен сообщениями (Message Passing) Процессы **не делят память**, а пересылают сообщения. **Примеры механизмов:** * Pipes (каналы) * Message Queues * Sockets * RPC / gRPC **Схема:** ``` [ Process A ] -- message --> [ Process B ] ``` **Плюсы** * Безопасно * Чёткие границы * Хорошо масштабируется **Минусы** * Накладные расходы на копирование данных --- ### 2.2 Общая память (Shared Memory) Процессы **разделяют участок памяти**. **Схема:** ``` [ Process A ] ↔ shared memory ↔ [ Process B ] ``` **Плюсы** * Максимальная скорость * Нет копирования данных **Минусы** * Сложная синхронизация * Риск race condition --- ## 3. Классические IPC-механизмы ОС ### 3.1 Pipes (каналы)   * Односторонний поток байт * Обычно между родителем и дочерним процессом ```bash ls | grep ".py" ``` **Используется когда:** простой линейный обмен --- ### 3.2 Named Pipes (FIFO) * Pipe с именем в файловой системе * Процессы могут быть не связаны напрямую ```bash mkfifo mypipe ``` --- ### 3.3 Message Queue   * Очередь сообщений в ядре ОС * Сообщения имеют типы / приоритеты **Пример:** POSIX message queues --- ### 3.4 Shared Memory   * Общий сегмент памяти * Требует синхронизации **Обычно вместе с:** * Semaphores * Mutex * Spinlocks --- ### 3.5 Semaphores и Mutex * **Semaphore** — счётчик доступа * **Mutex** — взаимоисключение **Назначение:** не передача данных, а **координация** --- ## 4. Сокеты — универсальный механизм   ### 4.1 Unix Domain Sockets * IPC на одной машине * Быстрее TCP ### 4.2 TCP / UDP * IPC через сеть * Основа микросервисов **Пример:** * Backend ↔ Worker * Frontend ↔ API --- ## 5. Высокоуровневые модели ### 5.1 RPC (Remote Procedure Call) Процесс вызывает функцию в другом процессе как локальную. **Примеры:** * gRPC * Thrift * JSON-RPC ``` client.call("getUser", id=10) ``` --- ### 5.2 Message Brokers   **Примеры:** * RabbitMQ * Kafka * Redis Pub/Sub **Используется когда:** * асинхронность * высокая нагрузка * отказоустойчивость --- ## 6. Сравнительная таблица | Механизм | Скорость | Сложность | Где применяют | | ------------- | ------------- | --------- | ------------------- | | Pipe | средняя | низкая | CLI, утилиты | | Message Queue | средняя | средняя | фоновые задачи | | Shared Memory | очень высокая | высокая | realtime | | Socket | высокая | средняя | сервисы | | RPC | средняя | низкая | микросервисы | | Broker | средняя | средняя | distributed systems | --- ## 7. Как это выглядит в реальных системах **Пример backend-архитектуры:** ``` API (FastAPI) ↓ HTTP (socket) Worker (Celery) ↓ Redis (queue) DB (PostgreSQL) ``` **Пример ОС:** * браузер ↔ рендер-процесс (IPC) * systemd ↔ сервисы * Docker контейнеры ↔ хост --- ## 8. Как выбрать подход **Если кратко:** * Нужно просто → pipe / socket * Максимальная скорость → shared memory * Масштабирование → broker * Сервисы → HTTP / gRPC * Асинхронные задачи → очередь --- ## 9. Ключевая мысль > Процессы **никогда не “разговаривают напрямую”** — они всегда используют **механизмы, предоставленные ОС или инфраструктурой**. Если хочешь, в следующем шаге могу: * разобрать **IPC на примере Linux** * показать **код на Python (multiprocessing / socket / shared memory)** * объяснить разницу **процесс ↔ поток ↔ корутина** * разобрать **IPC в Docker / Kubernetes** Скажи, в каком направлении идти дальше.