Python多消费者场景下multiprocess.Queue的提速方法

两类优化方案失效的核心原因如下：

• 同进程内单multiprocessing.Queue/多multiprocessing.Queue性能无差异：原生multiprocessing.Queue底层依赖OS管道+内部全局互斥锁实现状态保护，只要存在多个进程/线程同时对同一个队列执行get()/put()操作，所有调用都会串行争抢锁资源。短耗时任务场景下，锁争抢、进程上下文切换、管道IO的开销甚至会超过任务本身的执行耗时，最终所有队列操作的负载都会落在单个内核上，吞吐量碰到天花板。同进程内建多个队列但没有消除多消费者争抢同一队列锁的问题时，本质和单队列场景没有区别。
• multiprocessing.Manager().Queue性能更差：Manager托管的队列所有操作都走本地Socket的RPC调用，每次get()/put()都要经历参数序列化、两次跨进程上下文切换、结果反序列化的流程，额外开销是原生Queue的3~10倍，不仅入队效率暴跌，整体运行速度自然也会下降。

• 1:1绑定专属队列+批量投递
  每个消费者进程启动时，自行创建专属的原生multiprocessing.Queue实例，将所有专属队列的引用提前传递给生产者。生产者不需要维护公共任务队列，按轮询/负载权重规则，直接将批量任务投递到对应消费者的专属队列中，每个消费者仅从自己的专属队列拉取任务，完全消除多消费者争抢同一把队列锁的问题。

  投递时务必按批次投递，不要单任务单次调用put()，比如每次往单个消费者队列塞入10_{100个短任务，将系统调用、锁操作的开销平摊到多个任务上。该方案在毫秒级短任务场景下，吞吐量可比单公共队列提升5}10倍，不会出现单核负载打满的问题。

• 共享内存无锁队列替换
  如果任务为固定格式的结构化数据（比如数值、数组、定长字符串），可以基于multiprocessing.shared_memory实现跨进程环形无锁队列，完全去掉锁争抢、管道通信的开销，get()/put()操作耗时可降到纳秒级，特别适合单任务耗时在微秒级的超短任务场景。全程不要引入Manager组件，跨进程RPC的序列化开销对短任务来说占比过高。
• 任务粗粒度合并
  如果单任务执行耗时仅为几微秒到几十微秒，任何队列方案的通信开销占比都会过高。最省成本的优化方式是直接在生产者侧将数十个小任务合并为一个任务块投递，消费者拿到任务块后循环执行所有子任务再返回结果，将单次通信的开销平摊到多个小任务上，很多时候该方案的收益比更换队列实现更高。

多队列方案确实可以实现性能提升，但之前的部署方式存在逻辑问题才没有拿到收益：

• 错误部署逻辑：多个消费者共用所有队列、所有队列的写入集中在单进程串行分发、消费者跨队列争抢任务，这类场景下锁竞争的开销和单队列没有本质区别，自然没有优化效果。
• 正确部署逻辑：严格做到队列和消费者1:1绑定，不存在两个及以上的生产者/消费者对同一个队列执行读写操作，配合批量投递规则，就能拿到接近线性的吞吐量提升，不需要将队列托管给Manager，原生multiprocessing.Queue在无争抢场景下的性能足够支撑高吞吐短任务场景。

内容的提问来源于stack exchange，提问作者Axd