Какие эффективные способы передачи данных (2 МБайта) от одного приложения к другому есть в linux?

Question

[x32net]

Есть web-app, который в Post запросе принимает файл от пользователя:
1. Сохраняет файл (1 МБайт) в fs по уникальному пути: uniquePath := userID + time
2. Передает путь к файлу программе z-app: exec.Command(Z, uniquePath).Stdout = &stdout
3. Ждет завершения работы программы z-app (около 5-10 сек, web-api запросы)
4. Передает результат (2 MБайта) в Post: w.Write(stdout.Bytes())

Программа z-app:
1. Будет часто обновляться, без потерь для ожидающих завершения работы пользователей.

Как эффективнее реорганизовать взаимодействие web-app с z-app? Pipe, FIFO, что-то другое?
web-app и z-app написаны на Golang

Answer 1

[TargetSan]

Если ваша z-app по сути является бэкендом для web-app, не вижу проблемы запускать z-app как субпроцесс, скармливая ей данные через stdin и забирая результат из её stdout, Поскольку z-app всё равно работает долго, накладные расходы на запуск дочернего процесса проблемой не будут. Python это делает своим модулем subprocess, как это делает golang - не знаю.
В любом случае вы уткнётесь в передачу данных или напрямую через поток, или сохранением потока на диск в файл и передачей имени файла. Если же у вас z-app часто обновляется, решение с субпроцессами даст ещё и отсутствие проблем с апдейтами - новый инстанс просто запустится из нового файла

Comments

[x32net]

Благодарю, вариант решения: stackoverflow.com/questions/25023502/pipe-a-http-r...

Answer 2

[Александр Павлюк]

В чем проблема выведения ошибки в консоль? Если ошибки выводить в STDERR, а обмен данными производить через STDOUT, никаких проблем не будет.
Общение удобнее организовать через юникс-сокеты или через tcp на localhost. Пускай z-app висит демоном и принимает задачи на обработку.

Comments

[x32net]

z-app предполагается часто обновлять, без потерь

[Александр Павлюк]

x32net: тогда пусть z-app просто посылает ответ через сокеты, коннектясь к web-app.

[x32net]

Получится примерно так? stackoverflow.com/questions/36598819/go-how-to-use...

[Александр Павлюк]

x32net: не особо понял цель этого кода, особенно цель select в нем, он не нужен.

[x32net]

Александр Павлюк: целью была попытка ожидать пока z-app отправит данные, сопоставить полученные данные с уникальным путём и записать в post.

[Александр Павлюк]

x32net: select используется когда надо ждать данные из нескольких каналов или надо сделать что-то в случае если данных сейчас в канале нет.
Чтобы просто подождать ответ из канала можно оставить только конструкцию msg := <-jr

[x32net]

Александр Павлюк: тут было предположение: пользователей одновременно отпавивших post больше одного, чей первый обработается неивестно. А так же есть канал откуда поступают данные и их надо распределять по пользователям.

[Александр Павлюк]

x32net: у вас изначально неверный подход, postHandler читает из канала значение и если оно не совпадает с его номером, то просто его выкидывает. Поэтому у вас и теряются сообщения.

[x32net]

Согласен, первый опыт работы с многопоточностью. Ищу решение..

[Александр Павлюк]

x32net: сделайте map-ы для хранения пользователей, обработчиков, итд. Главное, помните, что изменять map можно только из одного потока одновременно.

[x32net]

Есть простой пример на go?

[Александр Павлюк]

x32net: если я правильно понял вашу задачу, то это будет выглядеть вот так: pastebin.com/zHJpvr53

Answer 3

[uvelichitel]

Если латентность 5-10сек вас устраивает можно обойтись fsnotify(например https://fsnotify.org/). web-app плодит файлы по уникальному пути. z-app отслеживает изменения в файловой системе и обрабатывает новые. Результат работы z-app заливает в тот же или новый файл по уникальному пути. web-app в свою очередь мониторит файловую систему и забирает новые результаты. Все асинхронно, прямой связи вообще нет. z-app может работать в несколько потоков.

Comments

[x32net]

Оно сейчас так работает. Хочется снять нагрузку с дисковой системы и переложить на ОЗУ.

Answer 4

[Никита]

Linux? Ну начните с этого
D-Bus
CORBA
Это ж очевидно.