Nginx + PHP-FPM 进程模型, 处理http请求的机制

Nginx + PHP-FPM 进程模型

整体架构

客户端
│ HTTP Request
▼
┌─────────────────────────────────────┐
│ Nginx │
│ Master Process (1个) │
│ └─ Worker Process × N (多个) │
│ 事件驱动、异步非阻塞 │
└──────────────┬──────────────────────┘
│ FastCGI 协议 (Unix Socket / TCP)
▼
┌─────────────────────────────────────┐
│ PHP-FPM │
│ Master Process (1个) │
│ └─ Worker Process × M (多个) │
│ 同步阻塞，每个 Worker 一次 │
│ 只处理一个请求 │
└─────────────────────────────────────┘

Nginx：事件驱动

Nginx Worker Process
│
├─ epoll (Linux) / kqueue (macOS)
│ 同时监听成千上万个连接的 fd
│
├─ 静态文件 → 直接读磁盘返回，全程不阻塞
│
└─ PHP 请求 → 转发给 PHP-FPM，等待响应
（此时 Worker 可以继续处理其他连接）

一个 Nginx Worker 可以同时持有数千个连接，因为 I/O 等待期间不占用 CPU。

PHP-FPM：进程池模型

PHP-FPM Master
│
├─ 监控 Worker 健康状态
├─ 管理进程池（按配置动态增减）
└─ Worker Pool
├─ Worker 1: [空闲] ←── 接收请求 → 执行 PHP → 返回 → [空闲]
├─ Worker 2: [忙碌] 正在执行 /api/user/auto_login
├─ Worker 3: [忙碌] 正在执行 /api/activity/config
└─ Worker 4: [空闲]

每个 PHP-FPM Worker 同步执行，一次只处理一个请求。你代码里的 $user（L53）在某个 Worker 进程的内存里，与其他 Worker 完全隔离。

一次请求的完整生命周期

1. 客户端 TCP 连接 → Nginx Worker 接受
│
2. Nginx 解析 HTTP，匹配 location 规则
│ location ~ \\.php$ { fastcgi_pass … }
│
3. Nginx 通过 FastCGI 协议发送给 PHP-FPM
│ 包含: SCRIPT_FILENAME, REQUEST_METHOD,
│ HTTP_AUTHORIZATION, 请求体等
│
4. PHP-FPM Master 分配一个空闲 Worker
│
5. Worker 执行 PHP（同步）
│ bootstrap → ServiceProvider::boot()
│ → 路由匹配
│ → Authenticate::handle()
│ └─ Auth::user() → $user (L53)
│ → Controller
│ → 返回 Response
│
6. Worker 将结果写回 FastCGI 连接
│
7. Nginx 收到响应 → 写回客户端 TCP 连接
│
8. Worker 状态变为 [空闲]，等待下一个请求

关键特性对比

对你代码的影响

// Authenticate.php:53
$user = \\Illuminate\\Support\\Facades\\Auth::user();

• $user 存在于某个 PHP-FPM Worker 进程的内存中
• 请求结束后自动销毁，不存在跨请求泄漏
• 这也是为什么要用 Redis（RedisService）做跨请求共享状态——进程内存不能共享
• PHP-FPM Worker 数量决定了同时能处理多少个并发 PHP 请求，这是系统吞吐量的直接上限