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

Question

что такое хороший способ выполнения rpc для многопроцессорности. Процессы?

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

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

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

Любые рекомендации?

Answer 1

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

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