在Python异步编程里，asyncio默认只使用一个事件循环运行在当前线程中。当并发任务数量极大或者单个回调处理偏重时，这个循环会成为性能瓶颈。把压力分散到不同事件循环，本质上是用多个独立的调度单元来分担负载，而不是把所有协程塞进同一个队列。
为什么单事件循环会受限
asyncio的事件循环基于单线程协作式调度，虽然协程在IO等待时会让出控制权，但所有回调最终还是在这个线程里依次执行。如果某个协程中有少量CPU密集型计算，或者回调链过长，就会阻塞后续任务。此外，由于全局解释器锁的存在，即便开多个线程跑事件循环，同一时刻也只有一个线程在执行Python字节码。
从底层看，事件循环内部维护着一个就绪队列和定时器堆。任务越多，队列操作与回调分发开销越大。当QPS超过单核处理能力时，延迟会非线性上升。因此，仅靠增加协程数量无法突破单循环的物理上限，必须引入多事件循环并行。
多进程配合多事件循环的方案
最稳妥的分散方式是使用多进程，在每个进程内创建全新的事件循环。这样每个循环都运行在独立解释器和线程中，能够真正利用多核。通过concurrent.futures.ProcessPoolExecutor或直接使用multiprocessing，可以把不同类别的任务指派给不同进程。
下面的示例展示如何在子进程中启动独立事件循环并处理一批网络请求任务。主进程负责将任务划分后提交，子进程内部调用asyncio.new_event_loop来避免继承父循环的冲突。
import asyncio
import multiprocessing
async def fetch_task(session_id):
# 模拟异步IO任务
await asyncio.sleep(0.1)
return f"session_{session_id}_done"
def run_loop_in_process(task_ids):
# 每个进程创建独立事件循环
loop = asyncio.new_event_loop()
asyncio.set_event_loop(loop)
try:
results = loop.run_until_complete(
asyncio.gather(*(fetch_task(tid) for tid in task_ids))
)
print(results)
finally:
loop.close()
if __name__ == "__main__":
all_tasks = list(range(20))
chunk_size = 5
processes = []
for i in range(0, len(all_tasks), chunk_size):
p = multiprocessing.Process(
target=run_loop_in_process,
args=(all_tasks[i:i+chunk_size],)
)
p.start()
processes.append(p)
for p in processes:
p.join()
该代码将二十个任务切成四块，每块由一个进程内的独立事件循环处理。由于进程之间内存隔离，不存在循环对象跨进程共享的问题。如果任务需要汇总结果，可以通过multiprocessing.Queue或Pipe将子进程结果回传主进程。
基于线程的轻量分散方式
如果不想承担多进程的内存开销，也可以在同一个进程内开多个线程，每个线程绑定一个事件循环。这种方式受GIL限制，不适合CPU重任务，但对纯IO型高并发有一定缓解作用。
实现时注意必须使用asyncio.new_event_loop在每个线程中显式创建，并用loop.run_forever启动，主线程通过asyncio.run_coroutine_threadsafe把协程提交到目标循环。示例如下：
import asyncio
import threading
def start_loop(loop):
asyncio.set_event_loop(loop)
loop.run_forever()
def submit_to_loop(loop, coro):
return asyncio.run_coroutine_threadsafe(coro, loop)
async def light_task(name):
await asyncio.sleep(0.2)
return name
loops = []
threads = []
for i in range(3):
lp = asyncio.new_event_loop()
t = threading.Thread(target=start_loop, args=(lp,), daemon=True)
t.start()
loops.append(lp)
threads.append(t)
futs = []
for idx, lp in enumerate(loops):
futs.append(submit_to_loop(lp, light_task(f"task_{idx}")))
for f in futs:
print(f.result())
for lp in loops:
lp.call_soon_threadsafe(lp.stop)
这种写法让三个循环分别位于三个线程，任务被近似平均地分散。缺点是GIL会让它们轮流执行，总体吞吐量仍受单核约束，仅适合降低单一循环排队长度。
任务分配与负载策略
分散到不同循环后，如何分派任务直接决定均衡效果。简单的取模或切片适用于同构任务；若任务耗时差异大，应采用工作窃取或中心队列模式。中心队列可由主进程维护，各循环空闲时主动拉取，避免某些循环闲置。
下表对比了常见分配策略的特点：
| 策略 | 实现复杂度 | 适用场景 | 缺陷 |
|---|---|---|---|
| 静态切片 | 低 | 任务均匀 | 倾斜时浪费资源 |
| 中心队列拉取 | 中 | 耗时差异大 | 需进程间通信 |
| 一致性哈希 | 高 | 有状态任务 | 重分布成本高 |
实际工程中，中心队列配合multiprocessing.Queue最常用。子循环处理完一批后向队列请求新任务，主进程按当前各循环负载返回对应协程参数，从而实现动态均衡。
注意事项与常见误区
开发者常误以为把loop对象通过全局变量传给另一进程就能复用，实际上事件循环不能跨进程序列化。同样，在一个循环中创建的Future或Task也不能直接被另一个循环await，否则会抛出循环不匹配异常。
另外，使用多进程时要避免大量重复初始化昂贵资源，例如每个子进程都新建数据库连接池。可以在进程启动时懒加载，或通过共享内存与连接代理减少开销。只有综合考量通信成本与计算成本，压力负载均衡才能真正提升异步系统吞吐。
asyncioevent_loopload_balancing修改时间：2026-08-01 19:42:31