Межпроцессная коммуникация

Question

Каковы плюсы и минусы использования файла для межпроцессного взаимодействия?Позвольте мне дать некоторое представление о контексте, в котором я задаю этот вопрос.

Проблема представляет собой классическую проблему производителя-потребителя с некоторыми ограничениями.Производители представляют собой совокупность совместных процессов, запущенных на кластере машин, и общаются друг с другом с помощью широковещательных передач.У каждого процесса есть локальные пользователи, о которых он знает, а также сообщает о них другим процессам с помощью описанного выше механизма широковещательной передачи.До сих пор информация о состоянии, которая транслировалась / делилась, не сохранялась, но теперь это необходимо.

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

1. Мы получаем настойчивость бесплатно.В случае, если у нового процесса возникнут проблемы, мы не потеряем ни одного локального трафика, поскольку записываем его в файловую систему.Пока потребитель знает, на чем он остановился, всякий раз, когда он появляется, он может начать обработку данных.
2. Нет кривой обучения использованию библиотек очередей в обычном старом unix file IO.
3. Самый большой плюс заключается в том, что мы вообще не влияем на текущий процесс создания, за исключением нового потока для записи файла.

Некоторые из проблем, связанных с таким подходом, заключаются в следующем:

1. Блокировка и конфликт файлов и их влияние на производительность.
2. Убедитесь, что буферы записи очищены и producer снимает блокировку файла только после того, как в файл будет записано полное событие.Потребитель должен прочитать неполные записи.

Мысли?Является ли такой подход наивным, и должны ли мы просто оплатить первоначальную стоимость за время наращивания за использование готовой библиотеки постоянных очередей?Главный момент здесь в том, что мы хотим оказать минимально возможное влияние на текущий процесс и не добавлять к нему никаких зависимостей.

Answer 1

Недавно я столкнулся с этим выбором и решил узнать достаточно о Berkeley DB, чтобы использовать ее механизм очередей.Но в конечном счете я решил вместо этого использовать файловую систему Unix и напишите мои собственные примитивы атомарной очереди используя Семафоры Posix.Если все процессы выполняются на одной машине, это довольно просто.Атомарная функция put состоит примерно из дюжины строк кода;атомарный get, поскольку он должен ждать, если очередь пуста, примерно в три раза больше по размеру.

Мой совет заключается в том, что вы разработайте API с атомной очередью это скроет эти детали.(Классический пример следования совету Парнаса по использованию интерфейса для сокрытия деталей дизайна, которые могут измениться.) Вы можете выполнить первую версию API, используя обычный файловый ввод-вывод Unix.Затем вы можете попробовать такие варианты, как блокировка, Berkeley DB или семафоры - все с "минимальным воздействием на текущий процесс".

Вы не узнаете, как это влияет на производительность, пока что-то не попробуете.Блокировка файлов в реальных файловых системах довольно хороша;блокировка файлов в NFS - это проблема.