本文介绍如何在保持发送顺序的前提下,将原本同步阻塞的 `send_to_space()` 调用转为非阻塞异步执行,从而显著提升批量任务吞吐量,同时无需修改原函数、不依赖线程且避免竞态风险。
在实际开发中,我们常遇到这样一类场景:需按严格顺序向外部服务(如 Space API)逐个发送请求,但每个请求本身是 I/O 密集型、耗时数十毫秒,且调用方并不关心响应内容。若直接使用同步循环(for item in items_list: send_to_space(item)),整个流程将被逐次阻塞,总耗时 ≈ N × 单次延迟 —— 这在处理数百项时会明显拖慢整体性能。
此时,asyncio 是最恰当的选择,而非多线程或多进程。原因如下:
- ✅ send_to_space() 是 I/O 等待型函数(即使当前是同步写法),本质适合异步调度;
- ✅ asyncio.create_task() 可立即提交协程并返回 Task 对象,不等待其完成,实现“发完即走”;
- ✅ await 在循环体内逐个 await create_task(…) 保证了逻辑上的严格串行性:前一个请求已发起(非必须完成),才发起下一个,既避免乱序,又消除阻塞;
- ❌ 多线程(threading.Thread)会引入 GIL 争用与上下文切换开销,且无法天然保障执行/发送顺序;
- ❌ asyncio.gather() 或 asyncio.as_completed() 会导致并发乱序,违背“必须按列表顺序发送”的硬性要求。
以下是优化后的完整实现:
import asyncio
# 假设 send_to_space 是一个同步函数(不可修改),例如:
# def send_to_space(sub_item):
# requests.post("https://api.space.example", json={"data": sub_item})
# 将其包装为可 await 的协程(推荐方式)
async def send_to_space_async(sub_item):
loop = asyncio.get_running_loop()
# 使用 run_in_executor 非阻塞调用同步函数
await loop.run_in_executor(None, send_to_space, sub_item)
# 主协程:按序发起请求,不等待响应完成
async def send_items(items_list):
for item in items_list:
sub_item = item['sub_item']
# 创建任务并立即继续下一轮 —— 发送动作已启动
task = asyncio.create_task(send_to_space_async(sub_item))
# 注意:此处不 await task,否则退化为同步
# 但我们仍需确保“发起顺序”,所以用 await task 确保前一个已提交再发下一个
# 更准确地说:await task 保证前一个请求已进入网络栈,符合“顺序发送”语义
await task
# 入口点
if __name__ == "__main__":
my_finite_list = [
{"sub_item": "A"}, {"sub_item": "B"}, {"sub_item": "C"}
]
asyncio.run(send_items(my_finite_list))
⚠️ 关键注意事项: