gunicorn 是基于预分叉多进程模型的 python wsgi 服务器，主进程管理 worker 生命周期但不处理请求，每个 worker 同步阻塞处理一个请求，共享监听 socket 由内核分发连接。
Gunicorn 是一个 Python WSGI HTTP 服务器，核心设计是基于 预分叉（pre-fork）多进程模型，不依赖异步框架也能稳定承载高并发请求。它本身不直接处理网络 I/O 或路由逻辑，而是作为 Web 应用（如 Flask、Django）和反向代理（如 Nginx）之间的桥梁，专注高效、安全地运行 Python Web 程序。
主进程负责管理，不处理请求
启动时，Gunicorn 先创建一个主进程（master process），它的唯一职责是：
- 根据配置（如 workers 数量）预生成指定数目的工作进程（worker processes）
- 监听系统信号（如 SIGHUP 用于平滑重启、SIGTERM 用于优雅关闭）
- 监控工作进程状态，自动拉起崩溃的 worker（若启用 preload=False 或未设 --preload）
主进程本身不接收或响应任何 HTTP 请求，也不加载应用代码——这避免了单点阻塞，也提升了可靠性。
工作进程独立运行，同步处理请求
每个 worker 是一个独立的 Python 进程，拥有自己的内存空间和解释器实例。默认采用同步阻塞模式（sync worker class），特点包括：
- 每个 worker 同一时间只处理一个请求（适合 CPU-bound 或简单 I/O 场景）
- 应用代码在 worker 进程内被完整加载一次（除非使用 --preload，否则加载发生在 fork 之后）
- 可通过 --worker-class 切换为 gevent 或 eventlet 实现协程并发，但需额外安装和适配
例如：配置 --workers 4 会启动 1 个 master + 4 个 worker，最多并行服务 4 个请求（同步模式下）。
请求分发由操作系统完成
Gunicorn 不实现负载均衡逻辑。所有 worker 进程共享同一个监听 socket（通过 Unix fork 继承文件描述符），当请求到达时，由内核的 accept() 竞争机制决定哪个 worker 接收连接——这是典型的“惊群”问题缓解后的标准 Unix 多进程模型。Nginx 通常前置部署，负责 SSL 终止、静态文件服务与请求转发，进一步降低 Gunicorn 的负担。
生命周期与信号控制是运维关键
理解信号行为对线上平稳运行至关重要：
- SIGHUP：重新加载配置并滚动替换 worker（旧 worker 处理完当前请求后退出）
- SIGUSR2：热升级——启动新 master 和新 worker，旧 master 逐步下线
- SIGTTIN / SIGTTOU：动态增减 worker 数量（需配置 --preload 才能安全生效）
未启用 --preload 时，每个 worker 单独导入应用模块，内存占用略高但隔离性更好；启用后主进程提前加载，再 fork，节省内存但需确保应用代码线程/进程安全。
