Nginx + Flask 并发能力与扩展思路（草稿/未完全论证）

1. 并发到底指什么？（先统一概念）

日常说“并发 1000”，经常会混淆两件事：

1）并发连接数（Concurrent Connections）

• 同时有 1000 个客户端保持连接（例如 HTTP keep-alive、WebSocket、长轮询）

• 特点：连接在，但不一定都在做计算

2）并发执行中的请求数（In-flight Requests）

• 同时有 1000 个请求正在被后端处理（查库/计算/调用外部接口）

• 特点：真正消耗 CPU / IO / DB

这两种“1000并发”，难度完全不同：

• ✅ 1000 连接并发：对 Nginx 来说通常不算大

• ⚠️ 1000 请求同时执行：大概率会卡在后端 worker 或数据库

2. Flask 自己能跑多大并发？

2.1 Flask 开发模式（flask run / python app.py）

这属于开发服务器，特点：

• 单进程为主

• 并发能力弱

• 不适合生产

经验上：

• 几十并发以内还能凑合

• 再高容易出现排队、超时、卡死

结论：生产环境不要用 Flask 自带运行方式扛并发。

3. 生产级部署：Gunicorn 是核心

3.1 Gunicorn 是什么？

Gunicorn 可以理解为：

Flask 是应用逻辑
Gunicorn 是生产级运行容器（多进程/多线程/更稳定）

它负责把 Flask 稳定跑起来，并支持并发能力扩展。

3.2 并发上限大致怎么算？

在最常见的 Gunicorn sync 模型下：

• 一个 worker 同时只能处理 1 个请求
  所以：

并发执行数 ≈ worker 数量

如果加线程：

并发执行数 ≈ workers × threads

举例：

• 9 workers × 8 threads = 72 个请求“同时在执行”

注意：
这不等于系统只能支撑 72 人访问，而是指 72 个请求同时处理。
如果接口很快，吞吐（RPS）可能仍然很高。

3.3 推荐启动方式（通用 IO 型后端）

适用于常见的：查 MySQL、读 Redis、请求外部接口 的后台接口

gunicorn app:app -w 9 --threads 8 -b 127.0.0.1:5000 --timeout 60

解释：

• -w 9：worker 进程数（常见经验：2*CPU+1）

• --threads 8：每个 worker 再开线程，提升 IO 并发

• -b 127.0.0.1:5000：只给 Nginx 反代用，更安全

3.4 什么时候考虑 gevent？

如果你的请求大部分都在 “等待 IO”，比如：

• 等数据库返回

• 等外部 HTTP 返回

• 等队列返回

可考虑：

gunicorn app:app -k gevent -w 4 --worker-connections 2000 -b 127.0.0.1:5000 --timeout 60

⚠️ 注意：gevent 更适合“等待型业务”，如果是大量 CPU 运算，它也救不了。

4. Nginx + Flask 能不能扛“1000并发”？

4.1 如果是 1000 个连接并发

✅ 结论：可以
Nginx 专门擅长处理大量连接。

4.2 如果是 1000 个请求同时在执行

⚠️ 结论：单机大概率不稳
原因通常不是 Flask，而是：

• Gunicorn worker/thread 数不够

• 慢 SQL 导致请求堆积

• 外部接口过慢导致请求挂起

• 日志过重造成 IO 阻塞

• 数据库先撑不住

真正要实现“1000请求同时执行”，往往必须：

• 缓存（Redis）

• 异步队列

• 多机扩容

5. 那“标准后端”比如 PHP 呢？

PHP 的生产模式通常是：

Nginx/Apache + PHP-FPM

5.1 PHP 并发的核心参数

pm.max_children = 可同时处理的请求数

每个 child 本质也是 “一次处理一个请求”，所以：

并发执行数 ≈ pm.max_children

这与 Flask 的 sync worker 思路非常类似。

5.2 为什么很多 PHP 网站看起来很能扛？

因为真实承压大头被分走了：

• 静态资源 Nginx 扛

• 页面缓存扛

• OPcache 加速

• Redis 缓存热点接口

• 数据库查询优化

所以“1000在线”不代表“1000请求同时跑 PHP”。

6. 单机多线程够了吗？还是必须分布式？

结论偏工程经验：

多线程/多进程属于纵向扩展（榨干单机）
多主机+负载均衡属于横向扩展（规模上限更高、更稳定）

如果目标是：

• 只是让系统更快、更稳：单机优化 + 缓存 可能就够了

• 真的要在高峰稳定抗住大流量：最终一定会走到多机 + LB + 缓存 + 队列

7. 多后端实例，登录怎么同步？

这是扩容时的必答题：
后端一旦多实例，登录状态必须共享，否则会随机掉线。

7.1 两条主流路线

方案 A：Session 共享（Redis Session）

浏览器只保存 session_id，登录数据放 Redis，所有后端都能查到。

优点：

• ✅ 最像传统后台登录

• ✅ 支持踢人（删 Redis session）

• ✅ 适合面板类系统（非常推荐）

实现思路（示例）：

pip install flask-session redis

from flask import Flask
from flask_session import Session
import redis

app = Flask(__name__)
app.secret_key = "YOUR_SECRET_KEY"  # 所有后端实例必须一致

app.config["SESSION_TYPE"] = "redis"
app.config["SESSION_REDIS"] = redis.Redis(host="127.0.0.1", port=6379, db=0)
app.config["SESSION_PERMANENT"] = True
app.config["PERMANENT_SESSION_LIFETIME"] = 3600

Session(app)

⚠️ 关键点：所有实例的 secret_key 必须完全一致
不一致会导致 cookie 校验失败，登录随机失效。

方案 B：JWT / Token 无状态登录

登录后发 token，客户端每次请求携带 token，后端只验签。

优点：

• ✅ 完全无状态，天然适合水平扩容

• ✅ API 体系非常舒服

缺点：

• ⚠️ 需要额外设计“踢人/失效机制”（黑名单、token_version）

7.2 Sticky 会话（不推荐）

负载均衡把同一个用户一直粘到同一台后端。

问题：

• 扩容缩容麻烦

• 机器重启用户就掉线

• 本质不是同步，只是绕开同步

只适合临时救急，不适合作为长期架构。

8. 推荐的“低成本可扩展”架构

一个现实可落地的组合：

• ✅ Nginx（入口、TLS、限流）

• ✅ 多台 Flask（Gunicorn）

• ✅ Redis（Session共享 + 缓存热点接口）

• ✅ MySQL（用户/权限数据统一存储）

• ✅ 队列（导出、统计、慢任务异步化）

这套结构不会复杂到“微服务地狱”，但扩展能力很强。