다중 처리를위한 RPC, 디자인 문제

Question

다중 처리를 통해 rpc를 수행하는 좋은 방법은 무엇입니까? 프로세스입니까?

다음 아키텍처에 대한 조언도 디자인되어 있습니다. 프로세스 A * 10, 프로세스 B * 1. 각 프로세스 A는 특정 항목을 쿼리해야하는지 여부를 프로세서 B에서 확인해야합니다.

그래서 모든 As에 대해 다중 처리. 파이프() 객체를 구현하려고하고 있었고 B가 각각을 듣도록했습니다. 그러나 Multiprocessing.Pipe.recv는 블로킹 (blocking)이라는 것을 알고 있습니다. 그래서 나는 이것을 어떻게 할 수 있는지 정말로 모른다. (루프를 사용하여 루프가 차단 될 상대방을 통해 전송 된 것 중 어느 것이 있는지 확인하십시오).

트위스트를 사용하는 방법에 대한 제안 사항이 있습니다. 그러나 뒤틀린 상태에서이 작업을 수행하는 방법에 대해 확신하지 못합니다. 모든 프로세스 A에서 각 pipe.handler에 지연을 생성해야하며 recv()가 수신하면 어떤 일이 계속되고 특정 루틴을 완료합니까? 나는 개인적으로 트위스트가 멀티 프로세싱과 잘 섞이지 않는다는 것을 알고 있지만, 멀티 프로세싱 구현의 자식 프로세스 인 트위스티드 (twisted)에 대한 테스트를 수행했으며 이번에는 실행 가능하다고 생각합니다.

어떤 권장 사항이 있습니까?

Answer 1

저는 개인적으로 소켓 기반 RPC를 선호합니다. 왜냐하면 더 확장해야하는 경우 단일 노드의 제한으로부터 자유 로워지기 때문입니다. Twisted는 소켓 기반 통신을 처리하는 좋은 방법을 제공하지만 물론 다른 대안도 있습니다. HTTP 1.1은 일반적으로 방화벽을 쉽게 통과하고 보안이 필요할 때 HTTPS로 쉽게 마이그레이션되므로 이러한 용도로 사용할 수있는 훌륭한 "전송"계층입니다. 그것 이상의 페이로드에 관해서는 JSON을 선호하는 편이 좋을지 모르겠지만 XML이나 다른 많은 인코딩과 비교할 때 상당한 시간을 보냈습니다. 비록 Google의 protobufs이 오픈 소스가되었으므로 유혹을 느끼고 있음을 인정해야하지만 (특히 내부적으로는 거의 독점적으로 사용됩니다. 안타깝게도 HTTP를 통한 protobufs의 특정 RPC 구현은 오픈 소스 였지만 ... 스스로 해결하기는 어렵지 않습니다.

Answer 2

REST-ful 트랜잭션 설계에 만족합니다.

이것은 파이프 대신 HTTP를 사용한다는 것을 의미합니다.

프로세스 B가 다양한 프로세스 A가 수행 할 수있는 대기열이있는 경우이 프로세스는 다음과 같이 작동합니다.

프로세스 B는 프로세스 A의 쿼리를 처리하는 RESTful URI가있는 HTTP 서버입니다. B는 Python wsgiref 또는 werkzeug 또는 다른 WSGI 구현을 사용하여 구현됩니다.

대부분 B가 A의 GET 요청에 응답합니다. 각 GET 요청은 다음 작업을 대기열에서 제거하고 응답합니다. B는 여러 동시 요청을 가지므로 일종의 단일 스레드 대기열이 필수적입니다. 이를 보장하는 가장 쉬운 방법은 WSGI 서버가 단일 스레드임을 보장하는 것입니다. 각 요청은 상대적으로 빠르기 때문에 단일 스레드 처리가 매우 잘 작동합니다.

B는 대기열을로드해야하므로 POST 요청에 대해서도 대기열에 포함됩니다.

프로세스 A는 프로세스 B가 제공하는 RESTful URI를 요청하는 HTTP 클라이언트입니다. A는 urllib2을 사용하여 B의 요청을 구현합니다. A는 B의 GET 요청을 만들어 대기열에서 다음 작업을 가져옵니다.

Answer 3

MPI를 보았습니까? http://en.wikipedia.org/wiki/Message_Passing_Interface.

UNIX/Linux/etc에서 광범위하게 사용할 수 있습니다. 나는 그것이 Windows에서 가질 수 있다고 믿습니다. 기본적으로 RPC 메커니즘을 기반으로 구축해야하는 모든 배관을 제공하며 그 뒤에 수년간의 개발과 개선이있었습니다. 그것은 API를위한 스펙입니다. 원래 C로 작성되었으므로 C++에서도 작동합니다. 거기에는 파이썬 구현도 있습니다.