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

Question

Какой хороший способ сделать RPC через многопроцессорную обработку. Процессы?

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

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

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

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

Answer 1

Лично я всегда склоняюсь к RPC на основе сокетов, потому что это освобождает меня от ограничений одного узла, если и когда мне нужно расширить больше. Twisted предлагает отличный способ обработки соединений на основе сокетов, но, конечно, есть и другие альтернативы. HTTP 1.1 является отличным «транспортным» уровнем для использования в таких целях, так как он, как правило, легко проходит через брандмауэры, легко переносится в HTTPS, если и когда вам нужна безопасность. Что касается полезных нагрузок над ним, я могу быть несколько эксцентричным в пользу JSON, но я отлично провел время по сравнению с XML или многими другими кодировками. Хотя я должен признать, что теперь, когда protobufs от Google были с открытым исходным кодом, они тоже заманчивы (особенно потому, что они являются тем, что мы используем внутри, почти исключительно - один наверняка привыкнет к ним; - ). Жаль, что никакой конкретной реализации RPC протобуфов через 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-клиент, который отправляет запросы RESTful URI, которые предоставляет Процесс B. A реализован с использованием 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.