Как обмениваться данными между процессами Python без записи на диск

Question

Helllo, Я хотел бы поделиться небольшими объемами данных (<1 КБ) между питоном и процессами. Данные представляют собой физические данные pc / 104 IO, которые изменяются быстро и часто (24x7x365). Будет один «сервер», записывающий данные, и несколько клиентов, считывающих его части. Система, на которой она будет работать, использует флэш-память (CF-карту), а не жесткий диск, поэтому я беспокоюсь об изнашивании флэш-памяти по схеме, основанной на файлах. Я также хотел бы использовать меньше энергии (процессорного времени), поскольку мы на 100% питаемся от солнечной энергии. </p>

• Это действительное беспокойство? Мы могли бы заменить CF-карту на SSD.
• При изменении значения с помощью mmap физически записываются данные на диск или это виртуальный файл?
• Мы будем работать на Debian, так что, возможно, POSIX IPC для модуля Python является лучшим решением. Кто-нибудь использовал это?
• Кто-нибудь пробовал модуль Python Object Sharing (POSH) ? На первый взгляд, это выглядит многообещающе, но оно в «Альфе» и, похоже, активно не разрабатывается.

Спасибо

UPDATE: Мы снизили максимальную частоту обновления данных примерно до 10 Гц, но чаще всего до 1 Гц. Клиенты будут уведомлены только при изменении значения, а не с постоянной частотой обновления. Мы обратились к модели с несколькими серверами / несколькими клиентами, где каждый сервер специализируется на определенном типе инструмента или функции. Поскольку оказалось, что большая часть программирования должна была выполняться программистами Java, мы в конечном итоге использовали JSON-RPC через TCP. Серверы будут написаны на Java, но я все еще надеюсь написать основной клиент на Python и изучаю реализации JSON-RPC.

Answer 1

Альтернативой записи данных в файл в процессе сервера может быть прямая запись в клиентские процессы:

Используйте доменные сокеты UNIX (или сокеты TCP / IP, если клиенты работают на разных компьютерах), чтобы подключить каждого клиента к серверу и заставить сервер записывать в эти сокеты. В зависимости от вашей конкретной модели обработки, выбор клиента / сокета может быть сделан сервером (например, циклическим перебором) или клиентами, сигнализирующими, что они готовы к большему.

Answer 2

Создайте раздел ramfs и напишите в него. (Вы можете использовать tmpfs, но в отличие от tmpfs, ramfs не выгружается на диск). Однако, поскольку ramfs не имеет ограничения по размеру, вы должны позаботиться о том, чтобы у вас не хватало памяти; так как вы пишете туда только крошечные данные, это не должно быть проблемой.

Таким образом, ваши данные никогда не будут записаны на диск (примечание: вы потеряете их в случае сбоя питания).

См. Также документы ramfs .

Answer 3

Согласно статье Википедии о системном вызове mmap содержимое отображенных в память файлов записывается обратно на диск при обновлении.

Вы смотрели на многопроцессорный модуль (в стандартной библиотеке) - особенно на часть состояния общего доступа между процессами?

Ramfs, как упомянуто Piskvor, также кажется хорошим решением, особенно когда не все процессы написаны на Python.

Answer 4

При работе на флэш-системах, убедитесь, что ваша файловая система спроектирована правильно, чтобы максимизировать срок службы флэш-памяти (выравнивание износа). JFFS и, я полагаю, другие теперь способны сделать это эффективно. Если вы используете такую ​​систему, вам не следует слишком беспокоиться об использовании флэш-памяти, но, разумеется, если вы пишете постоянный поток данных, вам следует избегать этого на флэш-памяти.

Использование файловой системы RAM - хорошая идея. Еще лучше - полностью избегать файловых систем, если вы позволите их проектировать. Для этого вы упоминаете POSH. Я никогда не пробовал, но мы обнаружили, что Pyro («Удаленные объекты PYthon») является элегантным и эффективным решением в некоторых подобных случаях.

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