Межпроцессного взаимодействия - PullRequest
2 голосов
/ 03 мая 2009

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

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

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

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

Некоторые проблемы с этим подходом:

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

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

1 Ответ

1 голос
/ 03 мая 2009

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

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

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

...