Готовую реализацию для IPC с буферизацией?

Question

[KEKSOV]

В рамках одного компьютера работают два процесса — Процесс А собирает данные с оборудования, он очень быстрый и его допиливать нужно очень осторожно, поэтому запись данных в MySQL вынесена в отдельный Процесс Б. Особенность задачи в том, что базы данных может в какой-то момент не быть — сервер выключили, сеть пропала и т.п., при этом данные пропасть не должны — когда снова появляется БД они должны быть туда записаны. Получается, что процесс А должен их сохранять в какой-то промежуточный буфер (файл), а процесс Б их читать из этого буфера (и удалять их оттуда после успешной записи в БД). Напрашивается реализация что-то типа MemoryStream поверх memory mapped file, с синхронизацией через семафоры/события. Еще как вариант — SQLite база, но не хочется ее сюда тащить для решения такой узкой задачи.


Возможно, кто-то сталкивался с подобной задачкой и может подсказать готовое решение.

Answer 1

[Ilya Evseev]

1) Универсальный вариант — это Redis, т.е. быстрое клиент-серверное nosql-хранилище в ОЗУ со снимками на диск.

2) Если требуется что-то предельно простое, то можно создать pipe с буфером максимального размера.
stackoverflow.com/questions/4624071/pipe-buffer-size-is-4k-or-64k

Процесс А читает данные и пишет в pipe. Процесс Б читает pipe и пишет в базу. Буферизацию выполняет Линукс.

Главные моменты, на которые надо обратить внимание:
— максимальный размер буфера для pipe,
— возможность потерять данные из-за аварийного завершения Б.

3) Если писать в mysql-таблицу типа Memory или Archive с помощью INSERT DELAYED прямо из А, скорость удовлетворительная?

Comments

[KEKSOV]

3) Если писать в mysql-таблицу типа Memory или Archive с помощью INSERT DELAYED прямо из А, скорость удовлетворительная?

Гениально! Я совсем забыл про Memory движок… это не ответ на мой вопрос, но решение для другой задачи, которая у меня тоже есть в рамках этого проекта. А базы данных может не быть несколько часов, так что большой pipe не спасет, в любом случае нужно сначала сохранить на диск, а потом разбираться с записью в базу. Если база зависнет, а мы пишем прямо из А, то А зависнет пока не закончится таймаут, что приведет к потере данных, которые могут прийти в этот момент.

Answer 2

[mayorovp]

А чем не устраивает второй поток в рамках того же процесса?

Comments

[KEKSOV]

На мой взгляд, что выбор двух потоков, что двух процессов, в моем случае не влияет на механизм передачи данных между ними:
1. Процесс А записывает полученные данные в буфер, который должен сохранить свое состояние в случае остановки процесса А. После успешной записи процесс А переставляет указатель на конец данных в буфере и сообщает процессу Б, что поступили данные
2. Процесс Б читает данные из буфера, записывает их в БД и переставляет указатель на начало данных.
3. При очередной записи в буфер процесс А сравнивает указатели на начало и конец и, если они равны (т.е. буфер пуст), начинает писать в начало буфера.
4. При завершении любого из процессов/потоков где-то должна сохраниться информация о состоянии его указателя на буфер.

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

[mayorovp]

Еще как влияет!
1. Два процесса могут обмениваться информацией только через ограниченное окно общей памяти — отсюда необходимость точного управления памятью. Потоки же разделяют все адресное пространство, и многие объекты могут продолжать оставаться в куче.
2. Из двух потоков вряд ли один внезапно упадет по внешним причинам — а в случае двух процессов один из них может быть и прибит из диспетчера задач. Обработка такой ситуации также не упростит реализацию IPC.

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

[KEKSOV]

Вы правы, я уже остановился на варианте с двумя потоками, так будет проще и надежнее. Готового ничего не нашел. Видимо, придется взять SQLite.