03 并发与异步

难度：中级｜前置：网络｜目标：理解并发、队列、限流和任务生命周期

四个容易混淆的概念

概念	含义
并发	多个任务在一段时间内推进
并行	多个任务在同一时刻真正执行
异步	发起任务后不阻塞等待最终结果
多线程/协程	实现并发的具体手段

协程很多不代表系统一定快。瓶颈可能在数据库连接、外部 API、CPU 或下游限流。

为什么需要异步任务

同步请求适合短、可预测的操作：

请求 → 处理 → 返回

以下情况更适合异步：

• 批量设备操作；
• 生成报表；
• OTA；
• 多步骤 Agent；
• 调用多个慢外部服务；
• 用户不需要立刻得到最终结果。

异步模型：

创建任务 → 返回 task_id
              ↓
           队列/调度
              ↓
            Worker
              ↓
       查询状态或推送进度

并发不是越高越好

假设数据库连接池 50，应用同时启动 1,000 个数据库任务：

• 950 个任务只能等待；
• 内存和超时增加；
• 重试可能产生更大压力；
• 下游恢复后出现请求洪峰。

并发上限应该由最紧的下游容量决定。

任务至少需要哪些状态

pending → running → succeeded
                  ↘ failed
           ↘ cancelled

还需要保存：

• task_id；
• 当前步骤；
• 输入和结果位置；
• 已尝试次数；
• 下一次重试时间；
• 创建人与权限；
• 开始、更新时间；
• 错误类型。

取消不是删除一条记录

取消是协作过程：

1. 用户请求取消；
2. 状态变为 cancelling；
3. Worker 在安全点检查；
4. 停止新步骤；
5. 释放资源或执行补偿；
6. 进入 cancelled。

已经发出去的邮件或设备命令通常不能“撤回”，只能记录和补偿。

限流、并发控制与背压

• 限流：单位时间允许多少请求；
• 并发控制：同时运行多少任务；
• 背压：下游处理不过来时向上游反馈；
• 队列：临时吸收速度差，但不能无限积压。

自测

1. 协程数量增加为什么可能让系统更慢？
2. 什么任务应该从同步 HTTP 转成异步？
3. 取消任务为什么需要状态机？
4. 队列积压时需要观察哪些指标？

完成标准

• 能区分并发、并行和异步
• 能画出带 task_id 的异步任务数据流
• 能设计任务取消过程
• 能说明并发上限由什么决定

下一单元：数据库与索引