python3 多进程库 multiprocessing 使用简介

布满荆棘的人生 2021-08-28 00:21 690阅读 0赞

### 引子 ###

前段时间在做的一个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标准库当中是完全一样的。

### 跨进程对象共享 ###

在mp库当中，跨进程对象共享有三种方式，第一种仅适用于原生机器类型，即python.ctypes当中的类型，这种在mp库的文档当中称为***shared memory***方式，即通过共享内存共享对象；另外一种称之为***server process***，即有一个服务器进程负责维护所有的对象，而其他进程连接到该进程，通过代理对象操作服务器进程当中的对象；最后一种在mp文档当中没有单独提出，但是在其中多次提到，而且是mp库当中最重要的一种共享方式，称为***inheritance***，即继承，对象在父进程当中创建，然后在父进程是通过multiprocessing.Process创建子进程之后，子进程自动继承了父进程当中的对象，并且子进程对这些对象的操作都是反映到了同一个对象。

这三者共享方式各有特色，在这里进行一些简单的比较。

首先是共享方式所应对的对象类型，看这个表：

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"><strong>共享方式</strong></td> 
   <td style="vertical-align:top;"><strong>支持的类型</strong></td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;">Shared memory</td> 
   <td style="vertical-align:top;">ctypes当中的类型，通过RawValue，RawArray等包装类提供</td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;">Inheritance</td> 
   <td style="vertical-align:top;">系统内核对象，以及基于这些对象实现的对象。包括Pipe, Queue, JoinableQueue, 同步对象(Semaphore, Lock, RLock, Condition, Event等等)</td> 
  </tr> 
  <tr> 
   <td style="vertical-align:top;">Server process</td> 
   <td style="vertical-align:top;">所有对象，可能需要自己手工提供代理对象(Proxy)</td> 
  </tr> 
 </tbody> 
</table>

这个表总结了三种不同的共享方式所支持的类型，下面一个个展开讨论。

其中最单纯简单的就是shared memory这种方式，只有ctypes当中的数据类型可以通过这种方式共享。由于mp库本身缺少命名的机制，即在一个进程当中创建的对象，无法在另外一 个进程当中通过名字来引用，因此，这种共享方式依赖于继承，对象应该由父进程创建，然后由子进程引用。关于这种机制的例子，可以参见[Python文档][multiprocessing]当中的例子 Synchronization types like locks, conditions and queues，参考其中的test\_sharedvalues函数。

然后是继承方式。首先关于继承方式需要有说明，继承本质上并不是一种对象共享的机制，对象共享只是其副作用。子进程从父进程继承来的对象并不一定是共享的。继承本质上是父进程fork出的子进程自动继承父进程的内存状态和对象描述符。因此，实际上子进程**复制**了 一份父进程的对象，只不过，当这个对象包装了一些系统内核对象的描述符的时候，拷贝这个对象（及其包装的描述符）实现了对象的共享。因此，在上面的表当 中，只有系统内核对象，和基于这些对象实现的对象，才能够通过继承来共享。通过继承共享的对象在linux平台上没有任何限制，但是在Windows上面 由于没有fork的实现，因此有一些[额外的限制条件][Link 1]，因此，在Windows上面，继承方式是几乎无法用的。

最后就是Server Process这种方式。这种方式可以支持的类型比另外两种都多，因为其模型是这样的：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70][]

server process模型

在这个模型当中，有一个manager进程，负责管理实际的对象。真正的对象也是在manager进程的内存空间当中。所有需要访问该对象的进程都 需要先连接到该管理进程，然后获取到对象的一个代理对象（Proxy object），通常情况下，这个代理对象提供了实际对象的**公共函数**的 代理，将函数参数进行pickle，然后通过连接传送到管理进程当中，管理进程将参数unpickle之后，转发给相应的实际对象的函数，返回值（或者异 常）同样经过管理进程pickle之后，通过连接传回到客户进程，再由proxy对象进行unpickle，返回给调用者或者抛出异常。

很明显，这个模型是一个典型的RPC（远程过程调用）的模型。因为每个客户进程实际上都是在访问manager进程当中的对象，因此完全可以通过这个实现对象共享。

manager和proxy之间的连接可以是基于socket的网络连接，也可以是unix pipe。如果是使用基于socket的连接方式，在使用proxy之前，需要调用manager对象的connect函数与远程的manager进程建 立连接。由于manager进程会打开端口接收该连接，因此必要的身份验证是需要的，否则任何人都可以连上manager弄乱你的共享对象。mp库通过 authkey的方式来进行身份验证。

在实现当中，manager进程通过multiprocessing.Manager类或者BaseManager的子类实现。 BaseManager提供了函数register注册一个函数来获取共享对象的proxy。这个函数会被客户进程调用，然后在manager进程当中执 行。这个函数可以返回一个共享的对象（对所有的调用返回同一个对象），或者可以为每一个调用创建一个新的对象，通过前者就可以实现多个进程共享一个对象。 关于这个的用法可以参考[Python文档][Python]当中的例子“Demonstration of how to create and use customized managers and proxies”。

典型的导出一个共享对象的代码是：

ObjectType object_
    class ObjectManager(multiprocessing.managers.BaseManager): pass
    ObjectManager.register("object", lambda: object_)

注意上面介绍proxy对象的时候，我提到的“公共函数”四个字。每个proxy对象只会导出实际对象的公共函数。这里面有两个含义，一个是“公 共”，即所有非下划线开头的成员，另一个是“函数”，即所有callable的成员。这就带来一些限制，一是无法导出属性，二是无法导出一些公共的特殊函 数，例如\_\_get\_\_, \_\_next\_\_等等。对于这个mp库有一套处理，即自定义proxy对象。首先是BaseManager的register可以提供一个 proxy\_type作为第三个参数，这个参数指定了哪些成员需要被导出。详细的使用方法可以参见文档当中的第一个例子。

另外manager还有一些细节的问题需要注意。由于Proxy对象不是线程安全的，因此如果需要在一个多线程程序当中使用proxy，mp库会为 每个线程创建一个proxy对象，而每个proxy对象都会对server process创建一个连接，而manager那边对于每个连接都创建一个单独的线程来为其服务。这样带来的问题就是，如果客户进程有很多线程，很容易会 导致manager进程的fd数目达到ulimit的限制，即使没有达到限制，也会因为manager进程当中有太多线程而严重影响manager的性 能。解决方案可以是一个进程内cache，只有一个单独的线程可以创建proxy对象访问共享对象，其余线程只能访问该进程当中的cache。

一旦manager因为达到ulimit限制或者其他异常，manager会直接退出，遗憾的是，这时候已经建立的proxy会试图重新连接 manager – 但是它已经不存在了。这个会导致客户进程hang在对proxy的函数调用上，这个时候，目前除了杀掉进程没有找到别的办法。

另外proxy使用socket的方式比较tricky，因此和内置的socket库有很多冲突，比如socket.setdefaulttimeout（[Python Issue 6056][] ）。在setdefaulttimeout调用了之后，进程当中所有通过socket模块建立的socket都是被设置为unblock模式的，但是mp 库并不知道这一点，而且它总是假设socket都是block模式的，于是，一旦调用了setdefaulttimeout，所有对于proxy的函数调 用都会抛出OSError，错误代码为11，错误原因是非常有误导性的“Resource temporarily unavailable”，实际上就是EAGAIN。这个错误可以通过我提供的一个[patch][]来补救（这个patch当中还包含其他的一些修复，所以请自行查看并修改该patch）。

由于以上的一些原因，server process模式作为一个对象的共享模式，能够提供最为灵活的共享方式，但是也有最多的问题。这个在使用过程当中就靠自己去衡量了。目前我们的系统对于 数据可靠性方面要求不高，丢失数据是可以接受的，但是也只用这种模式来维护统计值，不敢用来维护更多的东西。

### 关于Queue ###

Queue是mp库当中用来提供多进程对象交换的方式。对象交换和[上一部分][Link 2]当中提到的对象共享都是使多个进程访问同一个对象的方式，两者的区别就是，对象共享是多个进程访问同一个对象，对象交换则是将对象从一个进程传输的另一个进程。

multiprocessing当中的Queue使用方式和Python内置的threading.Queue对象很像，它支持一个put操作，将 对象放入Queue，也支持一个get操作，将对象从Queue当中读出。和threading.Queue不同的是，mp.Queue默认不支持 join()和task\_done操作，这两个支持需要使用mp.JoinableQueue对象。

由于Queue对象负责进程之间的对象传输，因此第一个问题就是如何在两个进程之间共享这个Queue对象本身。在上一部分所言的三种共享方式当 中，Queue对象只能使用继承（inheritance）的方式共享。这是因为Queue本身基于unix的Pipe对象实现，而Pipe对象的共享需 要通过继承。因此，在一个典型的应用实现模型当中，应该是父进程创建Queue，然后创建子进程共享该Queue，由父进程和子进程分别读写。例如下面的 这个例子：

import multiprocessing
     
    q = multiprocessing.Queue()
     
    def reader_proc():
        print q.get()
     
    reader = multiprocessing.Process(target=reader_proc)
    reader.start()
     
    q.put(100)
    reader.join()

另一种实现方式是父进程创建Queue，创建多个子进程，有的子进程读Queue，有的子进程写Queue，例如：

import multiprocessing
     
    q = multiprocessing.Queue()
     
    def writer_proc():
        q.put(100)
     
    def reader_proc():
        print q.get()
     
    reader = multiprocessing.Process(target=reader_proc)
    reader.start()
    writer = multiprocessing.Process(target=writer_proc)
    writer.start()
     
    reader.join()
    writer.join()

由于使用继承的方式共享Queue，因此代码当中并没有明显的传输Queue对象本身的代码，看起来似乎只要将multiprocessing当中 的对象换成threading当中的对象，程序仍然能够工作。反之，拿到一个现有的多线程程序，是不是将threading改成 multiprocessing就可以工作呢？也许可以，但是更可能的情况是你会遇到很多问题。

第一个问题就是mp的Queue需要考虑多进程之间的对象传输，因此所传输的对象必须是可以pickle的。否则，在Queue的put操作上会抛出PicklingError。

其他的一些差异表现在一些技术细节上，这些不是任何高层逻辑可以抽象掉的，不知道这些差异会导致一些潜在的错误，例如死锁。在总结这些潜在的犯错的 可能的同时，我们会简单看一下mp当中Queue的实现方式，以便能够方便的理解为什么会有这样的行为。这些实现问题仅仅针对Linux，Windows 上面的实现和出现的问题在这里不涉及。

mp.Queue建构在系统的Pipe之上，但是实际上进程并不是直接将对象写入到Pipe里面，而是先写入一个本地的buffer，再由一个专门 的feed线程将其放入Pipe当中。读取端则是直接从Pipe当中读出对象。之所以有这样一个feed线程，是为了能够提供Queue接口函数所需要的 put的超时控制。但是由于这个feed线程的存在，mp.Queue提供了几个额外的函数来控制它，一个函数close来停止该线程，以及 join\_thread来join该线程。close同时负责把所有在buffer当中的对象刷新到Pipe当中。

但是这个feed线程也是个麻烦制造者，为了保证所有被放入Queue的东西最终都能够到达另外一端的进程，mp库注册了一个atexit的处理函 数，用来在进程退出的时候自动close并且join该feed线程。这个join动作带来了很多问题，比如潜在的死锁。考虑下面一种状况：一个父进程创 建了两个子进程，一个子进程读，另一个子进程写。当需要停止这些进程的时候，父进程如果先把读进程结束，但是同时写进程已经将太多的对象写入Queue， 导致后继的对象等待在buffer当中，则这个进程将无法终止，因为atexit的处理函数等待把所有buffer当中的对象放入Pipe，但是Pipe 已经满了，然后陷入了死锁。

有人可能会问，那只要保证总是按照数据流的顺序来停止进程不就行。问题是在很多复杂的系统流程当中，可能存在一个环形的数据流，这种情况下，无论按照什么顺序停止进程，终究有一个进程可能陷入这种情景当中。

幸运的是，Queue对象还提供了一个成员函数cancel\_join\_thread，这个函数可以使得在进程停止的时候不进行join操作，这样 可以避免死锁，代价就是这个时候尚未刷新到Pipe当中的对象都会丢失。鉴于即使调用了join\_thread，残留在Pipe当中的对象仍然可能丢失， 所以一旦选择使用mp的Queue对象，就不要假设不会在流程当中丢对象了。

另外一个可能的方案是使用mp库当中的SimpleQueue对象。这个对象在文档当中没有提及，但是在multiprocessing.queue模块当中有定义。这个对象就是去掉了buffer的Queue对象，因此**可能**能够避免上面说的问题的。但是SimpleQueue没有提供put和get的超时处理，两个动作都是阻塞的。

除了使用multiprocessing.Queue，还可以使用multiprocessing.Pipe进行通信。mp.Pipe是Queue 的底层结构，但是没有feed线程和put/get的超时控制。一定程度上和SimpleQueue很像。需要注意的是Pipe带有一个参数 duplex，当设置为True（默认）的时候，Pipe并不是使用系统的pipe来实现，而是通过socketpair，即Unix Domain Socket来实现。这个和pipe相比有些微的性能差异。

另外一个使用Queue的方式不是mp库内置的。这种方式使用上一篇文章当中提到的server process的方式来共享一个Queue对象。这个Queue对象实际上在server process当中，所有的子进程通过socket连接到server process获取该Queue的代理对象进行操作。说到这有人会想起来mp库有一个内置的[SyncManager对象][SyncManager]， 可以通过multiprocess.Manager函数获取到，通过该对象的Queue方法可以获取一个Queue的代理对象。不幸的是，这个方法不是正 确的获取Queue的方式，原因正如上一篇文章所说，SyncManager.Queue方法的每次调用获取到的是一个新建对象的代理对象，而不是一个共 享对象。正确的使用server process当中的Queue的方式是：

共同部分：

import multiprocessing.managers as mpm
    import Queue
     
    class SharedQueueManager(mpm.BaseManager): pass
    q = Queue.Queue()
    SharedQueueManager.register('Queue', lambda: q)

服务进程：

mgr = SharedQueueManager(address=('', 12345))
    server = mgr.get_server()
    server.serve_forever()

客户进程：

mgr = SharedQueueManager(address=('localhost', 12345))
    mgr.connect()
    q = mgr.Queue() # 这里q就是共享的Queue对象的代理对象

这种方式比起mp库内置的Queue，有一些性能上的影响，因为毕竟牵涉到多次网络通讯，但是带来的好处是没有feed线程带来的一系列问题，而且 理论上不会存在丢数据的问题，除非server process崩溃。但是正如上一篇所说，server process本身就不是很靠谱的，因此这里也只是“理论上”不会丢数据而已。

说到性能，这里就列两个性能数据，以前在twitter上面[提到][Link 3][过的][Link 4]（这两个连接无法访问的请联系我）：

操作对象为 pickle后512字节的对象，通过proxy操作Queue的性能大约是7000次/秒（本机）或1100次/秒（多机），如果使用 multiprocessing.Queue，效率可达54000次/秒。

[Global Interceptor Lock]: http://docs.python.org/c-api/init.html#thread-state-and-the-global-interpreter-lock
[multiprocessing]: http://docs.python.org/library/multiprocessing.html
[RabbitMQ]: http://www.rabbitmq.com/
[backport]: http://code.google.com/p/python-multiprocessing/
[Link 1]: http://docs.python.org/library/multiprocessing.html#windows
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70]: /images/20210728/e1dad567ec5e41f1a2ff392c78074f2f.png
[Python]: http://docs.python.org/library/multiprocessing.html#examples
[Python Issue 6056]: http://bugs.python.org/issue6056
[patch]: http://blog.ftofficer.com/pub/patches/python/multiprocessing-bugs-patch.txt
[Link 2]: http://blog.ftofficer.com/2009/12/python-multiprocessing-2-object-sharing-across-process/
[SyncManager]: http://docs.python.org/library/multiprocessing.html#multiprocessing.managers.SyncManager
[Link 3]: http://twitter.com/ftofficer/status/3856021276
[Link 4]: http://twitter.com/ftofficer/status/3856933460