第二部分：PHP 7/8 底层原理、Workerman 常驻内存与高并发工程实战

---

第 1 章：Workerman 常驻内存框架底层原理与生产避坑准则

1.1 Workerman 物理本质与 Master-Worker 多进程模型

Workerman 是一个纯 PHP 编写的高性能常驻内存 Socket 异步网络编程框架。它脱离了传统 PHP-FPM 每次请求重新加载全盘代码的生命周期，实现了 100% 常驻内存。

                                [ Master 主进程 ] 
                                (监听 SIGCHLD/SIGHUP/SIGUSR1)
                                       │
                ┌──────────────────────┼──────────────────────┐
                ↓                      ↓                      ↓
       [ Worker 进程 1 ]       [ Worker 进程 2 ]       [ Worker 进程 3 ]
       (epoll 事件循环)        (epoll 事件循环)        (epoll 事件循环)

1. Master 主进程：不处理任何业务网络请求，只负责监听操作系统信号、管理 Worker 进程的生命周期与平滑重启 (reload)；
2. Worker 子进程：基于 Linux 内核 select / epoll I/O 多路复用机制，各自独立监听 Socket 端口，处理读写与业务逻辑。

---

1.2 Workerman 常驻内存 3 大生产致命坑点与排坑

💬 1. 跨请求全局变量污染事故 (Global State Leak)

• 原理：在传统 PHP-FPM 中，请求结束时所有变量被销毁；而在 Workerman 中，Worker 进程长期存活，声明的静态变量或全局数组（如 $GlobalData['user']）不会被销毁；
• 后果：下一个用户的请求可能读取到上一个用户的敏感数据，引发严重数据越权与内存泄漏；
• 解法：在 onMessage 业务回调结束前，必须显式 unset() 或重置上下文。

💬 2. 数据库长连接超时断开事故 (MySQL has gone away)

• 原理：Workerman 中的数据库连接是长连接，若闲置超过 MySQL 的 wait_timeout (默认 8 小时)，MySQL 会主动切断 TCP 连接；
• 后果：当新请求到来时，PHP 继续使用已断开的旧 PDO 句柄，抛出 SQLSTATE[HY000]: General error: 2006 MySQL server has gone away；
• 解法：在数据库封装类中捕获 2006 异常并自动执行重连 (Reconnect)，或者定期发送 SELECT 1 心跳包保活。

💬 3. 代码修改不实时生效与平滑重启 (Reload 原理)

• 原理：Worker 进程在启动时已将 PHP 文件编译为 Opcodes 载入内存，直接修改磁盘上的 .php 文件不会生效；
• 解法：使用 php start.php reload 进行平滑重启。
• 物理机制：Master 进程收到 reload 指令后，向 Worker 进程发送 SIGUSR1 信号。Worker 进程在完成当前正在处理的请求后优雅退出 (Exit)，Master 进程重新 Fork 新的 Worker 进程载入新代码，实现 0 停机时间升级。

---

第 2 章：SSE (Server-Sent Events) 打字机协议原理与 SSE vs WebSocket 对比

2.1 SSE 打字机流式推流物理规范

SSE (Server-Sent Events) 是基于 HTTP/1.1 长连接 (Persistent Connection) 的服务器单向推流协议，在大模型 (LLM) 打字机流式输出中被广泛应用。

[ Client 浏览器 (EventSource) ] ➔ 发起标准 HTTP GET 请求 ➔ [ Server 后端网关 ]
                                                                │
                                                                ↓ (保持 HTTP 长连接不关闭)
[ 收到 Token 1 ] ➔ 推送 data: {"token": "你"}\n\n ───────────────┤
[ 收到 Token 2 ] ➔ 推送 data: {"token": "好"}\n\n ───────────────┤
[ 流传输结束 ]   ➔ 推送 event: close\ndata: [DONE]\n\n ──────────┘

必背 HTTP 4 大推流 Header 规范：

HTTP/1.1 200 OK
Content-Type: text/event-stream; charset=utf-8
Cache-Control: no-cache, no-transform
Connection: keep-alive
X-Accel-Buffering: no   <-- 关键！通知 Nginx 禁用 FastCGI/Proxy 缓冲区缓存！

物理切分标记：

每条 SSE 消息必须包含 data: 前缀，且必须以 双换行符 \n\n 作为单条消息的物理结束分隔符！

---

2.2 Workerman vs SSE vs WebSocket 考点纵向对比

维度对比	Workerman (Socket 框架)	SSE (Server-Sent Events 协议)	WebSocket 协议
物理协议	原生 TCP/UDP，可承载 HTTP/WS	标准 HTTP / HTTP/2 协议	独立 ws:// / wss:// (Upgrade 握手)
通信方向	双向 / 自定义	单向 (仅 Server ➔ Client 推流)	双向全双工 (Full-Duplex)
适合场景	游戏服务端、长连接 Gateway、IM	大模型 API 打字机流式输出 (LLM Streaming)	实时聊天室、多人在线协同编辑
防火墙穿透	需要配置安全组与开放新端口	天然穿透防火墙 (借用 80/443 标准 HTTP 端口)	需要 Nginx 配置 Upgrade 头代理
断线重连	需业务层手动写心跳 Ping/Pong	原生 EventSource 浏览器自动重连	需业务层写心跳保活
Nginx 代理坑点	需配置 stream 模块或 WS 代理	必须设置 proxy_buffering off;	需配置 proxy_set_header Upgrade

---

2.3 生产环境 2 大致命故障事故分析

💬 事故 1：Nginx 缓冲区拦截导致打字机变成“卡顿等待几秒后一次性爆出”

• 现象：大模型输出了 50 个 Token，但前端界面毫无反应，过了 5 秒后突然把 50 个字一下子弹出来；
• 根因：Nginx 开启了 FastCGI Buffer / Proxy Buffer，将后端的 SSE 小数据包缓存在了 Nginx 内存中，积累到 4KB 才吐给前端；
• 解决方案：
  1. 后端输出 Header：X-Accel-Buffering: no；
  2. Nginx 配置：proxy_buffering off; 与 fastcgi_buffering off;；
  3. PHP 代码每次 echo 之后必须强行刷新缓冲区：ob_flush(); flush();。

💬 事故 2：PHP-FPM 进程池被单次 SSE 长连接挂死打爆 (502 Bad Gateway)

• 现象：同时有 50 个用户在使用 AI 聊天，整个网站突然爆出 502 Bad Gateway；
• 根因：PHP-FPM 是阻塞同步模型。处理 SSE 时，1 个用户维持 1 分钟长连接就独占 1 个 FPM Worker 进程。当 50 个 Worker 被卡住，新来的普通 Web 请求无 Worker 可用；
• 解决方案：处理长连接/SSE 推流，严禁使用 PHP-FPM，必须使用 Workerman / Swoole / Go (Gin) / Python (FastAPI) 等常驻内存异步网络引擎！

---

🔍 本章 6 重自审计报告

1. 【知识审计】：已全量补充 Workerman 底层 Master-Worker 多进程模型、常驻内存全局变量污染、MySQL has gone away 重连机制与 SIGUSR1 平滑重启 reload 原理；全量补充 SSE 4 大 Header 规范、双换行分隔符、Workerman vs SSE vs WebSocket 三方物理对比，以及 Nginx 缓冲区卡顿与 PHP-FPM 长连接挂死 502 事故排查！已适配移动端 ::: info 💬 自适应排版！