gunicorn+gevent是Django应对突发高并发最稳妥的轻量级方案之一，需正确配置monkey patch、连接池及worker参数，否则易卡死或丢请求。
直接上结论：用 gunicorn + -k gevent 是 Django 应对突发高并发最稳妥的轻量级方案之一，但必须配好 gevent 的 monkey patch 和连接池，否则容易卡死或丢请求。
为什么 gunicorn + gevent 比纯 sync 更抗突发
默认 gunicorn 用的是同步 worker（-k sync），每个请求独占一个 OS 线程，100 个并发就要开 100 个线程，内存和上下文切换成本高；而 gevent 是基于协程的异步 I/O 模型，单进程能并发处理数千连接，特别适合大量短连接、带网络/数据库 I/O 的 Web 请求。
但注意：gevent 不是“开箱即用”的异步——它依赖 monkey patch 把标准库（如 socket、ssl、threading）替换成协程安全版本。漏掉这步，gunicorn 还是会阻塞。
- 必须在
gunicorn启动前执行gevent.monkey.patch_all()，常见做法是在wsgi.py开头加 -
psycopg2（PostgreSQL）或pymysql（MySQL）也要单独 patch，比如gevent.monkey.patch_psycopg() - 不 patch 的典型表现：CPU 很低，但请求排队、响应延迟飙升，
gunicorn日志里出现大量worker timeout
gunicorn 启动命令的关键参数怎么设
光加 -k gevent 不够，还要调几个关键参数来匹配突发流量特征：
立即学习“Python免费学习笔记（深入）”；
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
-
--workers 4：建议设为 CPU 核数 × 2，避免过多 worker 导致调度混乱；突发时更靠单 worker 内协程并发，不是靠堆 worker 数 -
--worker-class gevent或简写-k gevent：必须显式指定，否则 fallback 到 sync -
--worker-connections 1000：每个 gevent worker 最大协程数，默认只有 1000，突发时容易打满；可设到 2000～4000，但要同步调高系统ulimit -n -
--timeout 30：防止慢协程长期占着连接，超时后强制 kill；比默认 30 秒更激进的话（比如 15），要确认业务逻辑真能快速返回 -
--preload：让 gunicorn 在 fork worker 前先加载 Django 应用，避免每个 worker 单独 import 造成启动慢或内存重复
示例命令：gunicorn myproject.wsgi:application --bind 127.0.0.1:8000 --workers 4 --worker-class gevent --worker-connections 2000 --timeout 30 --preload
数据库连接池必须跟上，否则全卡在 DB
gevent 让 Python 层并发上去了，但如果数据库连接没池化，所有协程还是会抢同一个连接，变成串行等待。
- Django 默认的
CONN_MAX_AGE=0表示每次请求都新建+关闭连接，完全不适合 gevent - 必须设
CONN_MAX_AGE > 0（比如 60），并配合连接池中间件，推荐django-db-geventpool - 安装后在
settings.py改数据库引擎：'ENGINE': 'django_db_geventpool.backends.postgresql_psycopg2'（PostgreSQL） - 同时加
'MAX_CONNS': 20和'MIN_CONNS': 4到OPTIONS里，避免连接数爆炸或空等 - 不配池的后果：
OperationalError: FATAL: remaining connection slots are reserved for non-replication superuser connections
nginx 反向代理不能只转发，得调缓冲和超时
即使后端扛住了，nginx 配置不当也会成为瓶颈：
-
proxy_buffering off：关掉缓冲，让流式响应（比如 SSE、大文件下载）能及时透出；但普通 JSON 接口建议保持 on -
proxy_read_timeout 60：必须 ≥ gunicorn 的--timeout，否则 nginx 先断连 -
proxy_next_upstream error timeout http_502 http_503 http_504：允许 nginx 自动踢掉暂时不可用的 gunicorn worker -
upstream里别只写一个地址，哪怕单机也建议加max_fails=3 fail_timeout=30s，防 worker 暂时卡死
最容易被忽略的是：突发流量下，nginx 的 worker_connections 和系统 ulimit -n 必须一致调高，否则新连接直接被拒，日志里只有 accept() failed (24: Too many open files)。
