真相是：
- Master 进程通常不直接接收业务连接（除非配置了
listen.owner/group且使用 Unix Socket，但即使如此，它也不处理 HTTP 协议）。 - Master 进程绝不“唤醒” Worker 去处理请求。Worker 进程是常驻内存 (Resident)的，它们处于空闲 (Idle)状态，监听在共享的 Socket 上。
- 连接是由 Worker 进程自己 accept 的，或者由 Nginx 通过 FastCGI 协议直接分发给空闲的 Worker。
- Master 的职责是管理 (Management)：fork 子进程、监控健康、平滑重启、回收僵尸进程。它像一个牧羊人，而不是接线员。
如果把 PHP-FPM 比作一家银行：
- Nginx：是大堂经理/取号机。它接收客户（HTTP 请求），进行初步分流。
- Master 进程：是行长。
- 职责：招聘员工（fork workers）、开除不合格员工（kill bad workers）、制定排班表（pm.max_children）、处理突发客流（dynamic/static pm）。
- 禁忌：行长不坐柜台，不直接办理业务。如果行长去办业务，整个银行的管理就瘫痪了。
- Worker 进程：是柜员。
- 状态：他们一直坐在柜台后（常驻内存）。
- 空闲时：他们在打盹或整理文件（Idle, waiting for events）。
- 忙碌时：当有客户（请求）被分配过来，他们立即开始办理业务（执行 PHP 代码）。
- 核心逻辑：别以为行长在派单。柜员们自己盯着叫号屏幕（Socket），谁有空谁就喊“下一位”。行长只在幕后确保柜员数量足够，且没有柜员猝死。
一、架构纠正：Master 到底做了什么？
1. Master 的核心职责
- 初始化：绑定端口（Socket），创建共享内存段（用于 scoreboard，记录每个 Worker 的状态）。
- Forking：根据配置 (
pm.start_servers) 创建初始数量的 Worker 子进程。 - 信号处理：接收
SIGTERM,SIGUSR2等信号，执行平滑重启 (Graceful Reload) 或停止。 - 心跳监控：定期检查 Worker 是否存活。如果 Worker 崩溃，Master 会重新 fork 一个新的替补。
- 日志聚合：收集全局日志。
2. Worker 的核心职责
- Accept Loop：每个 Worker 都在一个循环中，调用
accept()等待新的 FastCGI 连接。 - Request Processing：
- 读取 FastCGI 请求数据。
- 初始化 PHP 环境（加载
php.ini, 扩展）。 - 执行 PHP 脚本。
- 输出响应。
- 清理资源（释放变量，但保留内存池）。
- 回到
accept()等待下一个请求。
3. 谁在“接收连接”？
- 场景 A：Nginx + PHP-FPM (最常见)
- Nginx 建立 TCP 连接。
- Nginx 通过 FastCGI 协议将请求发送给 PHP-FPM 监听的 Socket (TCP 或 Unix Domain Socket)。
- 哪个 Worker 接收？操作系统内核根据 Socket 的监听队列，唤醒一个正在
epoll_wait或select的空闲 Worker。这是OS 级别的调度，不是 Master 做的。
- 场景 B：PHP-FPM 直接监听 (少见)
- Master 绑定端口，但通常会将监听 Socket 传递给 Worker，或者 Worker 继承 Master 的文件描述符。
- 依然是 Worker 自己在
accept。
💡 核心洞察：Master 是“元进程” (Meta-Process)，它不处理业务数据流。业务数据流直接在 Nginx 和 Worker 之间传输。Master 只控制进程的生命周期。
二、工作流程：一个请求的完整旅程
- Client -> Nginx：用户发起 HTTP 请求。
- Nginx -> PHP-FPM Socket：Nginx 解析请求，通过 FastCGI 协议写入 Socket。
- Kernel Scheduler：操作系统发现 Socket 上有数据，唤醒一个在该 Socket 上等待的Idle Worker。
- Worker Accepts：Worker 进程从
epoll_wait返回，调用accept()获取连接。 - Worker Executes：
- Worker 读取 FastCGI 包。
- Zend Engine 编译/执行 PHP 代码。
- 可能涉及 DB/Redis IO（此时 Worker 阻塞，直到 IO 完成）。
- Worker Responds：Worker 将结果写回 Socket，Nginx 读取并返回给 Client。
- Worker Resets：Worker 清理本次请求的内存（Request Shutdown），回到 Idle 状态，继续等待下一个请求。
- Master Watches：Master 全程旁观，除非 Worker 崩溃或超时，否则不介入。
三、进程管理策略：Master 如何决定 Worker 数量？
pm(Process Manager) 配置决定了 Master 的行为。
1.static(静态)
- 行为：Master 启动时固定创建
pm.max_children个 Worker。 - 优点：性能最高，无 fork 开销。
- 缺点：内存占用固定，无法应对流量波动。
- 适用：高配置服务器，流量稳定。
- PHP 隐喻：Fixed Thread Pool。预创建所有线程，复用即可。
2.dynamic(动态)
- 行为：
- 启动时创建
pm.start_servers个。 - 空闲少于
pm.min_spare_servers时，Master fork 新 Worker。 - 空闲多于
pm.max_spare_servers时，Master kill 多余 Worker。
- 启动时创建
- 优点：节省内存，适应一定波动。
- 缺点：频繁 fork/kill 有 CPU 开销，高并发下可能响应延迟。
- 适用：中等流量，内存敏感。
- PHP 隐喻：Auto-Scaling Group (Slow)。扩容缩容有滞后性。
3.ondemand(按需)
- 行为：
- 启动时不创建 Worker（或极少）。
- 有请求时才 fork。
- 空闲超过
pm.process_idle_timeout后 kill。
- 优点：极致节省内存。
- 缺点：首请求延迟极高（Cold Start），高并发下 Fork 风暴导致 CPU 满载。
- 适用：极低流量开发环境。
- PHP 隐喻：Serverless / Cold Start。每次调用都要初始化环境。
四、认知牢笼：常见误区
1. 误区：“Master 负责负载均衡。”
- 真相：Master 不做 LB。操作系统的 Socket 监听机制（SO_REUSEPORT）或 Nginx 的上游配置才是 LB。多个 Worker 监听同一个 Socket，内核负责分发。
- 对策：理解 OS 层面的并发模型。
2. 误区：“Worker 处理完请求就销毁了。”
- 真相：Worker 是常驻的。它只重置请求相关的内存，进程本身不退出。这就是为什么 PHP-FPM 比 CGI 快得多（避免了每次 fork/exec 的巨大开销）。
- 对策：注意内存泄漏。如果 PHP 代码有内存泄漏，Worker 会随着处理请求越来越多而膨胀，直到达到
pm.max_requests被 Master 重启。
3. 误区：“Master 挂了，服务就停了。”
- 真相：如果 Master 挂了，现有的 Worker 还能处理完当前请求，但无法接受新连接（因为监听 Socket 通常由 Master 持有或管理）。服务会逐渐不可用。
- 对策：使用 Supervisor/Systemd 监控 Master 进程，自动重启。
4. 误区：“Swoole/Hyperf 也是这样的。”
- 真相：完全不同。
- FPM：多进程，同步阻塞，请求级隔离，无状态。
- Swoole：多进程（Master/Manager/Worker）+ 多线程（Reactor）+ 协程。Worker 内部是异步非阻塞的，一个 Worker 可以同时处理成千上万个请求（通过协程切换）。
- 对比：FPM 是“一人一事”，Swoole 是“一人万事（并发）”。
🚀 总结：原子化“FPM 架构”全景图
| 维度 | 关键点 |
|---|---|
| 本质 | Pre-forked, Resident, Synchronous Process Model |
| Master 角色 | 管理者 (Manager)：Fork, Monitor, Reload.不处理业务。 |
| Worker 角色 | 执行者 (Executor)：Accept, Execute, Reset.常驻内存。 |
| 连接接收 | OS Kernel + Worker Accept Loop. Master 不参与。 |
| 进程策略 | Static (高性能), Dynamic (平衡), Ondemand (省内存) |
| 性能瓶颈 | Fork 开销, Context Switch, Memory Limit |
| PHP 隐喻 | Traditional Thread Pool vs. Serverless |
| 公式 | Throughput = Worker_Count × (1 / Request_Duration) |
终极心法：
FPM 的本质，是“用空间换时间，用进程换隔离”。
Master 是幕后黑手，Worker 是台前演员。
别指望 Master 帮你干活，它只负责确保你有足够的帮手。
于进程中见隔离，于常驻见效率；以架构为尺，解混淆之牛，于 Web 服务中，求稳定之真。
行动指令：
- 检查配置：查看你的
www.conf，确认pm模式。生产环境推荐static或dynamic。 - 监控进程数：使用
top或htop观察 php-fpm 进程数量变化，是否符合预期。 - 理解重启：执行
systemctl reload php-fpm，观察 Master 如何平滑重启 Worker（旧 Worker 处理完请求后退出，新 Worker 接替）。 - 思维升级：记住，PHP-FPM 是传统的、沉重的、但极其稳定的架构。理解它的局限性，才能明白为什么 Swoole/Hyperf 是未来的方向。
