高效资源编排的5种Python技术
内容提要
本文介绍Python并发资源编排的五种技术：用TaskGroup实现结构化并发，任务失败时自动取消；用Semaphore按后端真实容量限制并发；用AsyncExitStack动态管理运行时决定的资源清理；用asyncio.timeout()实现嵌套超时与截止时间传播；用Python 3.14新增的asyncio ps/pstree命令实时诊断任务。核心观点是并发易得，但有限、无泄漏、可恢复的并发需刻意构建。
延伸解读
从“能并发”到“可控并发”的思维转变
文章开篇即点明，让 Python 代码并发运行早已不是难题，真正的挑战在于让有限资源在并发下正确工作。这要求开发者从追求“跑得快”转向构建“有界、无泄漏、可恢复”的并发系统。TaskGroup 确保任务生命周期不泄漏，Semaphore 防止压垮后端，AsyncExitStack 和 timeout 则处理异常路径。这种思维转变是区分演示代码与生产级代码的关键。
信号量作用域：全局共享而非请求级创建
文章强调，Semaphore 的关键设计决策在于作用域：应为每个后端创建一个信号量，其容量匹配该后端的真实处理能力，并在整个进程内共享，而不是在每个请求中新建。若在请求内创建，信号量只能限制单个请求的并发，无法约束全局负载。文中通过 30 个并发请求的实测表明，全局信号量成功将风险模型后端的峰值并发控制在设定的 3 个，验证了其有效性。
嵌套超时：区分单后端故障与整体预算
asyncio.timeout() 支持嵌套，这允许同时设置每个后端的独立超时和整个请求的总预算。内层超时能隔离单个慢后端，避免其拖垮整个请求；外层超时则强制总耗时上限。文章实测将总预算设为 0.1 秒，而部分后端需 0.5 秒，结果快速后端的结果被保留，慢后端被取消并记录错误，请求在约 0.16 秒内返回部分结果，而非一直挂起。这种设计让系统在硬截止时间下仍能提供部分可用性。
Python 3.14 的实时任务诊断能力
文章特别指出，Python 3.14 新增的 python -m asyncio ps/pstree 命令，允许直接附加到运行中的进程，查看实时任务树、调用栈和等待状态，无需修改代码或添加日志。这对于诊断生产环境中意外的挂起问题极具价值，例如判断请求是卡在风险模型后端还是编排逻辑本身。虽然前四种技术能减少此类问题的发生，但无法完全避免，该工具提供了标准库级别的最后一道排查手段。
Q&A
Python 3.11 中 asyncio.TaskGroup 相比 asyncio.gather 有什么优势？
asyncio.gather 在某个任务失败时不会自动取消其他任务，可能导致孤儿任务在后台继续运行。而 asyncio.TaskGroup 保证块内所有任务在退出前要么完成要么被取消，一个任务失败会自动取消其余任务，避免任务泄漏。
如何用 asyncio.Semaphore 限制对后端服务的并发请求数？
为每个后端创建一个模块级的 asyncio.Semaphore，容量设为该后端的真实容量，并在整个进程内共享。在获取连接时使用 async with semaphore 阻塞直到有空闲槽位，退出时自动释放。这样能确保并发数不超过后端限制。
AsyncExitStack 在动态资源清理中解决了什么问题？
当需要打开的异步上下文管理器数量在运行时才能确定时，AsyncExitStack 允许将任意数量的上下文管理器压入一个栈，并保证在退出时按相反顺序全部关闭，避免资源泄漏。
asyncio.timeout() 如何实现嵌套超时和截止时间传播？
asyncio.timeout() 作为异步上下文管理器，可以将超时作用域嵌套。外层超时包裹整个 TaskGroup 设置总预算，内层超时为每个任务设置更紧的截止时间。这样单个慢后端不会影响其他任务，同时整体请求也有硬性时间限制。
Python 3.14 新增的 asyncio ps 和 pstree 命令有什么用途？
这两个命令可以附加到正在运行的 Python 进程，实时打印任务树。ps 显示所有活动任务的扁平表格，包括名称、协程调用栈和等待对象；pstree 以层次结构展示任务由哪个 TaskGroup 创建。无需修改代码或添加日志即可诊断生产环境中的挂起问题。
文章中的仪表盘聚合器场景使用了哪些后端服务？
场景中需要并发查询四个后端服务：定价 API、持仓数据库、新闻源和风险模型。每个后端有不同的容量和延迟特征，例如风险模型容量为 3，延迟 0.3-0.5 秒，并有 15% 的模拟失败率。
