RPC для многопроцессорной обработки, вопросы дизайна

какой хороший способ сделать rpc через multiprocessing.Process?

Я также открыт для рекомендаций по проектированию следующей архитектуры: процесс A * 10, процесс B * 1. Каждый процесс A должен проверять с процессом B, нужно ли запрашивать конкретный элемент.

Поэтому я подумал о реализации объекта multiprocessing.Pipe() для всех As, а затем B прослушивал каждого из них. Однако я понимаю, что Multiprocessing.Pipe.recv БЛОКИРУЕТСЯ. поэтому я действительно не знаю, как я могу это сделать. (если я использую цикл, чтобы проверить, какой из них отправлен через другой конец, цикл будет заблокирован).

Есть предложения для меня использовать скрученный, но я не уверен, как мне сделать это в скрученном: должен ли я создать отсрочку для каждого pipe.handler из всех процессов A, а затем, когда recv() получает что-то, он продолжается и выполнить определенную рутину? Лично я знаю, что Twisted не очень хорошо сочетается с многопроцессорной обработкой, но я провел некоторые тесты Twisted, которые являются дочерними процессами реализации многопроцессорной обработки, и я думаю, что на этот раз это работает.

Есть рекомендации?


python multiprocessing rpc
person Community    schedule 30.08.2009    source источник

Ответы (3)


arrow_upward
6
arrow_downward

Лично я всегда склоняюсь к RPC на основе сокетов, потому что это освобождает меня от ограничений одного узла, если и когда мне нужно расшириться. Twisted предлагает отличный способ управления связью на основе сокетов, но, конечно, есть и другие альтернативы. HTTP 1.1 — отличный «транспортный» уровень для таких целей, поскольку он обычно легко проходит через брандмауэры и легко мигрирует в HTTPS, если и когда вам нужна безопасность. Что касается полезной нагрузки, то я могу быть несколько эксцентричным, предпочитая JSON, но я отлично провел время с ним по сравнению с XML или многими другими кодировками. Хотя я должен признать, что теперь, когда protobufs от Google стали открытыми, они тоже заманчиво (тем более, что они - то, что мы используем внутри, почти исключительно - к ним обязательно привыкаешь ;-). Жаль, что никакой конкретной RPC-реализации protobufs через HTTP не было с открытым исходным кодом ... но это не так сложно приготовить для себя ;-).

person Alex Martelli    schedule 30.08.2009

arrow_upward
1
arrow_downward

Я доволен использованием дизайна транзакций REST-ful.

Это означает использование HTTP вместо каналов.

Если процесс B имеет очередь действий для различных процессов A, он будет работать следующим образом.

Процесс B — это HTTP-сервер с RESTful URI, который обрабатывает запросы от процесса A. B реализован с использованием Python wsgiref или werkzeug или какая-либо другая реализация WSGI.

В основном B отвечает на запросы GET от A. Каждый запрос GET берет следующую вещь из очереди и отвечает ею. Поскольку B будет иметь несколько одновременных запросов, необходима какая-то однопоточная очередь. Самый простой способ убедиться в этом — убедиться, что сервер WSGI является однопоточным. Каждый запрос выполняется относительно быстро, поэтому однопоточная обработка работает довольно хорошо.

B должен загрузить свою очередь, поэтому он, вероятно, также отвечает на запросы POST для постановки в очередь.

Процесс A является HTTP-клиентом, выполняющим запросы RESTful URI, которые предоставляет процесс B. A реализован с использованием urllib2 для выполнения запросов к B. A отправляет GET-запросы от B к получить следующую вещь из очереди.

person S.Lott    schedule 30.08.2009

arrow_upward
1
arrow_downward

Вы смотрели МПИ? http://en.wikipedia.org/wiki/Message_Passing_Interface.

Он широко доступен в UNIX/Linux/и т. д. Я считаю, что это может быть в Windows. По сути, он предоставляет всю инфраструктуру, которую вам придется строить поверх механизмов RPC, и за ним стоят многие годы разработки и усовершенствования. Это спецификация для API, изначально написанная на C, поэтому работает и с C++, и там также есть реализации Python.

person Eric M    schedule 14.10.2009