FPM Master 进程接收连接，唤醒一个 Worker 进程。

真相是：

1. Master 进程通常不直接接收业务连接（除非配置了listen.owner/group且使用 Unix Socket，但即使如此，它也不处理 HTTP 协议）。
2. Master 进程绝不“唤醒” Worker 去处理请求。Worker 进程是常驻内存 (Resident)的，它们处于空闲 (Idle)状态，监听在共享的 Socket 上。
3. 连接是由 Worker 进程自己 accept 的，或者由 Nginx 通过 FastCGI 协议直接分发给空闲的 Worker。
4. 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：
  1. 读取 FastCGI 请求数据。
  2. 初始化 PHP 环境（加载php.ini, 扩展）。
  3. 执行 PHP 脚本。
  4. 输出响应。
  5. 清理资源（释放变量，但保留内存池）。
  6. 回到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 只控制进程的生命周期。

二、工作流程：一个请求的完整旅程

1. Client -> Nginx：用户发起 HTTP 请求。
2. Nginx -> PHP-FPM Socket：Nginx 解析请求，通过 FastCGI 协议写入 Socket。
3. Kernel Scheduler：操作系统发现 Socket 上有数据，唤醒一个在该 Socket 上等待的Idle Worker。
4. Worker Accepts：Worker 进程从epoll_wait返回，调用accept()获取连接。
5. Worker Executes：
   • Worker 读取 FastCGI 包。
   • Zend Engine 编译/执行 PHP 代码。
   • 可能涉及 DB/Redis IO（此时 Worker 阻塞，直到 IO 完成）。
6. Worker Responds：Worker 将结果写回 Socket，Nginx 读取并返回给 Client。
7. Worker Resets：Worker 清理本次请求的内存（Request Shutdown），回到 Idle 状态，继续等待下一个请求。
8. 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 架构”全景图

终极心法：

FPM 的本质，是“用空间换时间，用进程换隔离”。
Master 是幕后黑手，Worker 是台前演员。
别指望 Master 帮你干活，它只负责确保你有足够的帮手。
于进程中见隔离，于常驻见效率；以架构为尺，解混淆之牛，于 Web 服务中，求稳定之真。

行动指令：

1. 检查配置：查看你的www.conf，确认pm模式。生产环境推荐static或dynamic。
2. 监控进程数：使用top或htop观察 php-fpm 进程数量变化，是否符合预期。
3. 理解重启：执行systemctl reload php-fpm，观察 Master 如何平滑重启 Worker（旧 Worker 处理完请求后退出，新 Worker 接替）。
4. 思维升级：记住，PHP-FPM 是传统的、沉重的、但极其稳定的架构。理解它的局限性，才能明白为什么 Swoole/Hyperf 是未来的方向。