ftofficer|张聪的blog

前段时间在做的一个Python项目，需要实现一个后台服务程序，程序流程比较复杂，而且可能经常变动，但是如果把整个流程切分成一些步骤，每个步骤有自己的输入输出和处理。只要将他们的输入输出接在一起，进行不同的组合就可以实现常见的流程变动。

使用多进程的原因是考虑到Python的全局解释器锁（Global Interceptor Lock, GIL）。由于GIL的存在，在CPU密集型的程序当中，使用多线程并不能有效地利用多核CPU的优势，因为一个解释器在同一时刻只会有一个线程在执行。要想尽可能利用多核CPU并发，多进程是必需的。

引入多进程就带来几个问题：首先是这种设计方案需要一个类似于UNIX Pipe的底层结构，说的更确切一点就是message queue，操作类似于Python的Queue.Queue。另一个问题就是需要一个进程间信息共享的基础设施。

先说Queue，这个Queue需要满足下面一些需求，优先级递减：

• 轻量 – 不需要依赖数据库等比较重型的程序。代价就是丢点东西没关系；
• 跨进程 – 读端和写端可以不在一个进程当中；
• 支持多进多出 – 读端和写端都要支持多个进程；
• 稳定和高效 – 这个就不用多说了吧；
• 有Pythonçš„API，再不济要有Cçš„API可以让我写Pythonçš„binding。

另外是进程间共享的设施，系统shm是迫不得已使用的，因为要自己处理Pickling和Unpickling，以及一些杂七杂八的竞争条件问题。有建构在上面的现成的库最好。

最终出于轻量的考虑，选定了Python的multiprocessing库，而没有用IPC MQ 或 RabbitMQ。这个库在Python2.6被引入到标准库当中，有为2.5提供的backport。因为我们的系统使用的是2.5版本，因此我们使用的其实是2.5的backport。这个实现除了一些细枝末节的地方之外，核心实现和2.6标准库当中是完全一样的。

在使用过程当中，遇到了挺多的问题，在这里一一记录。