异步IO是高并发任务的核心突破口，适用于IO密集型任务；CPU密集型任务需用多进程或加速方案；任务分发应选合适中间件；监控降级和超时控制不可或缺。
异步IO是高并发任务的核心突破口
Python 的 GIL 限制了多线程的 CPU 并行能力，但对 IO 密集型任务（如 HTTP 请求、数据库读写、文件操作），真正瓶颈在等待响应，而非 CPU 计算。这时用 asyncio + aiohttp / aiomysql / aiosqlite 构建协程池，单线程就能高效调度成百上千并发连接。关键不是“开更多线程”，而是让一个线程在等待时立刻切走，去处理其他就绪任务。
常见误区：用 threading 处理大量 API 调用——线程创建销毁开销大，且受 GIL 和系统线程数限制，容易触发 OSError: can't start new thread；正确做法是用 asyncio.Semaphore 控制并发请求数（比如同时最多 50 个 HTTP 请求），避免压垮服务端或耗尽本地资源。
CPU 密集型任务必须绕过 GIL
如果任务本身要大量计算（如图像处理、数值模拟、加密解密），asyncio 无济于事。此时应使用 multiprocessing 或 concurrent.futures.ProcessPoolExecutor 将任务分发到多个进程。注意：进程间数据传递有开销，不适合高频小任务；大任务才值得上进程池。
补充方案：
- 使用 numba 或 Cython 加速单个函数，让它在 GIL 下跑得更快；
- 把核心计算模块用 Rust/Go 重写，通过 subprocess 或 cffi 调用，兼顾性能与 Python 生态；
- 对批处理场景，优先考虑向量化（numpy）或使用 dask 实现分布式并行计算。
任务分发与状态管理不能只靠内存
用 asyncio.Queue 或 multiprocessing.Queue 做内部通信没问题，但一旦涉及故障恢复、任务持久化、跨机器扩展，就必须引入外部中间件。面试中常被追问：“服务挂了，正在跑的任务怎么办？”
立即学习“Python免费学习笔记（深入）”；
推荐组合：
- 简单可靠：Redis + RQ / Celery（RQ 更轻量，Celery 功能全）；
- 高吞吐/强一致：**Kafka + Faust** 或 **Celery with RabbitMQ**；
- 云原生场景：直接对接 **AWS SQS + Lambda** 或 **阿里云 MNS + 函数计算**。
务必强调：任务对象必须可序列化（避免传 lambda、嵌套类实例），失败重试需设最大次数+指数退避，关键任务加唯一 ID 防重复执行。
监控与降级是高并发落地的临门一脚
没有监控的并发系统等于埋雷。至少要暴露三类指标：
- 并发水位：当前活跃协程数 / 进程数 / 队列积压长度；
- 延迟分布：P95/P99 响应时间，区分成功/失败路径；
- 错误归因：HTTP 状态码分布、数据库超时次数、下游服务熔断状态。
简单实现可用 aiometer 统计协程耗时，用 prometheus_client 暴露指标；生产环境建议集成 OpenTelemetry 做链路追踪。当错误率突增或延迟飙升时，自动触发降级：比如关闭非核心接口、返回缓存数据、切换备用 API 通道。
不复杂但容易忽略：所有异步任务必须有超时控制（asyncio.wait_for(task, timeout=10)），否则一个卡死协程可能拖垮整个事件循环。
