Python gunicorn 的 worker 模型选择（sync/gevent/eventlet）

sync worker 在 i/o 密集场景下易卡死，因其同步阻塞特性使整个进程在数据库查询、http 调用等操作时停滞，导致 503 增多、worker timeout、请求堆积；根本原因非参数可解，需换 gEvent/eventlet 或异步 worker。

sync worker 为什么在 I/O 密集场景下容易卡死

sync worker 是 gunicorn 默认模型，每个 worker 对应一个 OS 进程，用同步阻塞方式处理请求。一旦遇到数据库查询、HTTP 调用、文件读写等 I/O 操作，整个 worker 就停在那里，无法响应新请求。

常见错误现象：503 Service Unavailable 突然增多、gunicorn 日志里大量 Worker timeout (pid:xxx)、CPU 使用率低但请求堆积严重。

适用场景：纯 CPU 计算型服务（如图像缩放、数值计算），或已用异步客户端（如 aiohttp）但没配对 worker 类型。

• 不要在调用 requests.get() 或 psycopg2.connect() 的 Web 接口里硬扛 sync worker
• --workers 设太高会吃光内存，设太低又压不住并发——这不是调参能解决的根本问题
• python 的 GIL 不影响 sync worker 的进程隔离性，但 I/O 阻塞本身不受 GIL 控制，所以卡是实打实的

gevent worker 要求代码“无阻塞”但不强制 async/await

gevent 通过 monkey patch 把标准库里的阻塞调用（如 socket、ssl、threading）替换成协程友好的版本。它不要求你改写成 async def，但要求所有 I/O 调用最终落到被 patch 过的底层上。

立即学习“Python免费学习笔记（深入）”；

容易踩的坑：gevent.monkey.patch_all() 必须在任何其他 import 之前执行；否则像 requests 可能仍走原生阻塞 socket；某些 C 扩展（如 ujson、numpy）不兼容 patch，但一般不影响 HTTP 处理。

• 启动命令必须加 --worker-class gevent --worker-connections 1000，后者定义每个 worker 最大协程数
• gevent 不支持 windows，开发机是 Win？别试了，直接换 WSL 或 linux 容器
• 如果用了 celery，注意 gevent 和 celery 的 event loop 冲突，需用 celery -P gevent 显式指定

eventlet worker 和 gevent 的关键区别在哪

两者都靠 monkey patch 实现协程，但 eventlet 更早支持 SSL/TLS 分块读写，在某些 https 后端代理（如 nginx + keepalive）下更稳；gevent 在高并发短连接场景下调度开销略小，生态支持略广（比如 psycopg2 官方文档明确推荐 gevent）。

性能差异在大多数业务中感知不强，但兼容性问题很具体：

• eventlet 对 threading.local 支持较弱，如果你依赖线程局部变量存 request context（比如 flask 的 g），可能出错
• eventlet patch 后的 time.sleep() 行为和原生不同，单元测试里写 time.sleep(0.1) 等待异步完成？大概率失败
• 不能混用：gevent 和 eventlet 的 patch 互斥，装了两个还都 patch，Gunicorn 启动直接报 ImportError: cannot import name 'hubs'

怎么判断你的应用该选哪个 worker

别猜，看 I/O 调用链路是否可控。如果项目里大量使用 requests、redis-py、psycopg2 这类同步阻塞库，又没精力重构成异步，gevent 是最现实的选择。

真实使用场景参考：

• django 项目 + postgresql + requests 调第三方 API → 用 gevent，加 --worker-class gevent --worker-connections 1000 --timeout 30
• Flask + sqlite（文件锁敏感）→ 别用 gevent/eventlet，SQLite 的 WAL 模式在协程下有竞争风险，老实用 sync + --workers 2
• fastapi + httpx.AsyncClient → 用 uvicorn，不是 Gunicorn 的活；非要用 Gunicorn，得配 --worker-class uvicorn.workers.UvicornWorker，和 gevent/eventlet 无关

最常被忽略的一点：worker 类型选错，日志里不会报错，只会慢慢变慢、超时、OOM——得靠 gunicorn 的 --statsd-host 或进程级监控（如 ps aux --sort=-%cpu）才能发现 worker 是否真在干活。