多进程的RPC，设计问题
在多进程之间进行远程过程调用（RPC）有什么好的方法吗？
我也想听听关于以下架构的设计建议：有10个进程A和1个进程B。每个进程A都需要和进程B确认某个特定的项目是否需要查询。
所以我在考虑为所有的A进程实现一个multiprocessing.Pipe()对象，然后让B进程监听它们。不过，我意识到multiprocessing.Pipe.recv是阻塞的，这让我不知道该怎么做。（如果我用一个循环去检查哪个管道有数据发送过来，这个循环就会被阻塞）。
有人建议我使用twisted，但我不太确定该怎么在twisted中实现：我是否应该为所有A进程的每个管道创建一个defer，然后当recv()接收到数据时，继续执行某个例程？我知道twisted和多进程不太兼容，但我在多进程实现的子进程中做过一些twisted的测试，我觉得这次是可行的。
有什么推荐的吗？
3 个回答
你有没有听说过MPI？ http://en.wikipedia.org/wiki/Message_Passing_Interface。
它在UNIX、Linux等系统上都可以使用，我想在Windows上也能找到。简单来说，MPI提供了很多基础功能，这些功能是你在使用RPC机制时需要自己去搭建的。而且它经过了多年的开发和改进。MPI是一个API的规范，最初是用C语言写的，所以也能和C++一起使用，另外还有Python的实现版本。
我对使用RESTful事务设计感到满意。
这意味着我们用HTTP来传输数据，而不是用管道。
如果有一个叫做B的进程，它有一个队列，里面存放着各种A进程需要处理的任务，工作流程大致是这样的。
B进程充当一个HTTP服务器，使用RESTful的URI来处理来自A进程的请求。B是用Python的wsgiref或werkzeug，或者其他的WSGI实现来搭建的。
通常，B会响应来自A的GET请求。每个GET请求会从队列中取出下一个任务，并将其返回。因为B会同时处理多个请求，所以需要一种单线程的队列来确保处理的顺利进行。确保WSGI服务器是单线程的，最简单的方法就是这样做。每个请求的处理速度相对较快，所以单线程处理效果很好。
B需要有一个加载好的队列，所以它可能还会响应POST请求，以便将任务添加到队列中。
A进程是一个HTTP客户端，它向B提供的RESTful URI发送请求。A是用urllib2来向B发送请求的。A通过GET请求向B获取队列中的下一个任务。
我个人比较喜欢用基于套接字的远程过程调用（RPC），因为这样可以让我在需要扩展的时候，不受单一节点的限制。Twisted是一个很好的处理套接字通信的工具，但当然还有其他选择。HTTP 1.1是一个很不错的“传输”层，适合用来做这些事情，因为它通常能轻松穿过防火墙，而且如果需要安全性，也可以很方便地升级到HTTPS。至于在这个基础上传输的数据，我可能有点特别，偏爱使用JSON格式，因为相比于XML或其他编码方式，我觉得用起来更顺手。不过我得承认，自从谷歌的protobufs开源后，它们也很吸引人（尤其是我们内部几乎都是在用它们——用久了就习惯了;-）。可惜的是，目前还没有开源的基于HTTP的protobufs的具体RPC实现……不过自己动手做一个其实也不难;-）。