企业官网建设流程全解析

在实际的 Web 项目中，消息推送是一个高频且核心的需求，无论是电商订单状态变更、社交互动提醒，还是系统告警通知，都需要一个稳定、高效、可扩展的推送系统来支撑。PHP 作为后端开发的主流语言之一，其生态中提供了多种实现推送的方案，但很多开发者在构建时容易陷入“能用就行”的误区，忽略了连接管理、性能瓶颈、异常处理和水平扩展等工程细节。一个健壮的推送系统，不仅要能发得出消息，更要保证消息不丢失、连接不断开、服务能扛压。

本文将围绕 PHP 实现一个可投入生产环境使用的 WebSocket 推送系统展开。我们将从最基础的 Socket 编程概念讲起，逐步过渡到使用成熟的 Workerman 框架来构建长连接服务。文章会详细解释单机模式下如何管理连接与广播消息，并探讨当单机性能达到瓶颈时，如何借助 Redis 的发布订阅（Pub/Sub）机制实现多进程或多服务器间的消息协同，最终构建一个支持水平扩展的分布式推送架构。整个过程会包含环境准备、核心代码实现、关键配置参数解析、服务部署验证，以及生产环境中必然会遇到的连接闪断、内存泄漏、消息堆积等问题的排查路径与解决方案。

1. 理解推送系统的核心：从短轮询到 WebSocket

在动手写代码之前，必须理清推送技术的演进脉络和选型依据。这决定了我们系统的底层通信模型和资源消耗模式。

1.1 传统方案的局限：短轮询与长轮询

最原始的“推送”实际上是客户端不断向服务器发起请求询问是否有新消息，这被称为短轮询（Short Polling）。它的实现简单，但缺点极其明显：无论服务器是否有新数据，客户端都会频繁发起请求，造成大量无效的 HTTP 连接开销和服务器资源浪费，实时性也取决于轮询间隔。

为了改进，出现了长轮询（Long Polling）。客户端发起请求后，服务器会保持连接，直到有数据更新或超时才返回响应，客户端收到响应后立即发起下一次请求。这减少了无效请求，但每个连接在等待期间仍然占用服务器资源（如 Apache/NGINX 的工作进程或线程），并发能力受限于服务器的工作进程数。并且，连接建立和断开的开销依然存在。

这两种基于 HTTP 的方案，其本质都是“客户端拉取（Pull）”，并非真正的“服务器推送（Push）”。

1.2 WebSocket：真正的全双工通信协议

WebSocket 协议在 HTTP 握手之后，将连接升级为一个全双工（Full-Duplex）的 TCP 长连接。这意味着一旦连接建立，服务器和客户端可以在任意时刻主动向对方发送数据，而不需要反复建立连接。这对于需要高实时性、低延迟的推送场景是理想选择。

• 优点：真正的双向通信，低延迟，低开销（一个连接持续复用），高实时性。
• 挑战：需要服务器端有能维持大量 TCP 长连接的能力，这对传统 PHP 运行模式（每个请求结束后释放所有资源）是颠覆性的。因此，我们需要一个能常驻内存的 PHP 程序来处理连接。

在 PHP 生态中，直接操作 Socket 进行编程是可行的，但复杂度高。更普遍的做法是使用现成的常驻内存框架，例如Swoole或Workerman。它们封装了底层的 Socket、事件循环和进程管理，让开发者能更专注于业务逻辑。本文选择Workerman进行演示，因为它纯 PHP 实现，不依赖扩展，部署和调试相对更简单，适合大多数环境。

2. 环境准备与 Workerman 基础

在开始构建推送服务前，需要确保你的开发或生产环境满足基本要求，并理解 Workerman 的运行模型。

2.1 环境与依赖要求

首先，你的 PHP 环境需要支持 CLI（命令行接口）模式运行，并且建议禁用pcntl_fork和posix_setsid等函数限制，因为 Workerman 会使用它们来管理进程。

可以通过以下命令快速检查环境：

php -v | grep -i cli # 确认是 CLI 版本 php -m | grep -E 'pcntl|posix' # 检查相关扩展，非必须但推荐 php --ri sockets # 检查 sockets 扩展，Workerman 需要

接下来，使用 Composer 初始化项目并安装 Workerman：

mkdir php-push-system && cd php-push-system composer init --no-interaction composer require workerman/workerman

这会在项目根目录生成vendor文件夹和composer.json文件。Workerman 的核心就是一个 PHP 库，通过 Composer 引入后即可在代码中直接使用。

2.2 理解 Workerman 的进程模型

Workerman 以多进程模式运行。默认情况下，它会启动一个主进程（Master）和多个子进程（Worker）。主进程负责监控子进程，子进程才是真正处理客户端连接和业务逻辑的单位。每个子进程都是一个独立的 Reactor 事件循环实例，可以处理成千上万的连接。

这种模型带来了几个关键特性：

1. 进程隔离：一个 Worker 进程崩溃不会影响其他 Worker，主进程会重新拉起它。
2. 多核利用：多个 Worker 进程可以绑定到不同的 CPU 核心，充分利用多核性能。
3. 共享数据困难：默认情况下，Worker 进程间的内存是隔离的。这意味着在一个 Worker 中设置的变量，其他 Worker 无法直接访问。这是设计分布式推送系统时必须解决的核心问题。

3. 构建单机版 WebSocket 推送服务

我们先从最简单的单机场景开始，实现一个能接受连接并向所有在线客户端广播消息的服务。

3.1 项目结构与入口文件

创建以下目录结构：

php-push-system/ ├── composer.json ├── vendor/ ├── start.php # 服务启动入口 ├── Applications/ # 业务应用目录 │ └── Push/ │ ├── Events.php # 事件处理类 │ └── start_websocket.php # WebSocket 服务启动脚本 └── logs/ # 日志目录（手动创建）

首先创建服务启动入口start.php，它负责加载 Composer 的自动加载文件，并启动我们的推送应用：

<?php // start.php require_once __DIR__ . '/vendor/autoload.php'; // 运行 Applications/Push/ 下的服务 require_once __DIR__ . '/Applications/Push/start_websocket.php';

3.2 实现 WebSocket 服务与事件处理

核心逻辑在Applications/Push/目录下。我们先创建事件处理类Events.php：

<?php // Applications/Push/Events.php namespace Applications\Push; class Events { /** * 当客户端连接时触发 * @param \Workerman\Connection\TcpConnection $connection */ public static function onConnect($connection) { echo "New connection established, ID: {$connection->id}\n"; // 可以将连接ID与用户信息绑定，这里简单记录 $connection->last_heartbeat_time = time(); } /** * 当客户端发送消息时触发 * @param \Workerman\Connection\TcpConnection $connection * @param mixed $data 客户端发送的数据 */ public static function onMessage($connection, $data) { // 更新心跳时间 $connection->last_heartbeat_time = time(); // 假设客户端发送 JSON 格式消息: {"type": "ping", "content": "hello"} $message = json_decode($data, true); if (!$message) { $connection->send(json_encode(['error' => 'Invalid JSON format'])); return; } switch ($message['type'] ?? '') { case 'ping': // 心跳回应 $connection->send(json_encode(['type' => 'pong', 'time' => time()])); break; case 'broadcast': // 模拟管理员广播消息，这里直接广播给所有连接 // 注意：单机模式下，只能广播给当前 Worker 进程内的连接 $broadcastMsg = json_encode([ 'type' => 'broadcast', 'from' => 'system', 'content' => $message['content'] ?? '', 'time' => date('Y-m-d H:i:s') ]); foreach ($connection->worker->connections as $clientConn) { $clientConn->send($broadcastMsg); } break; default: $connection->send(json_encode(['type' => 'echo', 'received' => $message])); } } /** * 当客户端连接关闭时触发 * @param \Workerman\Connection\TcpConnection $connection */ public static function onClose($connection) { echo "Connection closed, ID: {$connection->id}\n"; } /** * 当客户端连接发生错误时触发 * @param \Workerman\Connection\TcpConnection $connection * @param int $code 错误码 * @param string $msg 错误信息 */ public static function onError($connection, $code, $msg) { echo "Error [{$code}] on connection {$connection->id}: {$msg}\n"; } }

接下来，创建 WebSocket 服务启动脚本start_websocket.php：

<?php // Applications/Push/start_websocket.php use Workerman\Worker; use Workerman\Connection\TcpConnection; require_once __DIR__ . '/Events.php'; // 创建一个 WebSocket 服务器，监听 2346 端口 $ws_worker = new Worker('websocket://0.0.0.0:2346'); // 设置进程数，根据 CPU 核心数调整，单机测试可设为1 $ws_worker->count = 4; // 设置连接回调函数 $ws_worker->onConnect = ['Applications\Push\Events', 'onConnect']; $ws_worker->onMessage = ['Applications\Push\Events', 'onMessage']; $ws_worker->onClose = ['Applications\Push\Events', 'onClose']; $ws_worker->onError = ['Applications\Push\Events', 'onError']; // 设置心跳检测，每 30 秒检查一次，55 秒无响应则断开 $ws_worker->onWorkerStart = function($worker) { // 每 30 秒遍历一次所有连接 Timer::add(30, function() use ($worker) { $time_now = time(); foreach ($worker->connections as $connection) { // 如果连接最后活跃时间在 55 秒前，则认为连接已死 if (empty($connection->last_heartbeat_time) || $time_now - $connection->last_heartbeat_time > 55) { echo "Connection {$connection->id} timeout, closing.\n"; $connection->close(); } } }); }; // 如果不是在根目录启动，则运行 Worker if (!defined('GLOBAL_START')) { Worker::runAll(); }

3.3 关键配置与参数解析

在上面的代码中，有几个关键点需要理解：

1. Worker('websocket://0.0.0.0:2346')：创建一个 WebSocket 协议的工作进程，绑定在所有网络接口（0.0.0.0）的 2346 端口。websocket://协议头告诉 Workerman 自动处理 WebSocket 握手协议。
2. $ws_worker->count = 4：设置启动 4 个 Worker 子进程。这通常设置为服务器 CPU 核心数或稍多一点。每个进程独立监听同一个端口（由内核负载均衡），但连接和内存数据不共享。
3. 心跳检测 (Timer::add)：由于网络不稳定或客户端异常退出，服务器可能残留“死连接”。定时器定期检查每个连接的最后活跃时间（通过onMessage或自定义心跳包更新），超时则主动关闭，释放资源。
4. 广播的局限性：在onMessage的broadcast分支中，我们遍历$connection->worker->connections。这只能广播给当前 Worker 进程内维护的连接。如果count=4，一个连接连到了 Worker 2，那么 Worker 1、3、4 中的客户端将收不到这条广播消息。这是单机多进程架构下推送系统要解决的首要问题。

3.4 启动服务与基础测试

在项目根目录下，运行以下命令以调试模式启动服务：

php start.php start

你会看到类似输出：

Workerman[php-push-system] start in DEBUG mode ----------------------------------------------- WORKERMAN ----------------------------------------------- Workerman version:4.1.15 PHP version:8.1.2 Event-Loop:\Workerman\Events\Select ----------------------------------------------- WORKERS -------------------------------------------------- proto user worker listen processes status tcp nobody none websocket://0.0.0.0:2346 4 [OK] --------------------------------------------------------------------------------------------------------- Press Ctrl+C to stop. Start success.

现在，你可以使用任何 WebSocket 客户端进行测试。例如，在浏览器控制台（确保页面协议为 https 或 http，且域名与服务器一致）中：

// 前端测试代码 const ws = new WebSocket('ws://你的服务器IP:2346'); ws.onopen = function() { console.log('Connected'); // 发送一个 ping 消息 ws.send(JSON.stringify({type: 'ping'})); }; ws.onmessage = function(event) { const data = JSON.parse(event.data); console.log('Received:', data); if (data.type === 'pong') { console.log('Heartbeat received at', data.time); } }; ws.onerror = function(error) { console.error('WebSocket Error:', error); }; ws.onclose = function(event) { console.log('Connection closed', event.code, event.reason); };

同时，在服务器终端，你会看到New connection established的日志。至此，一个最基础的单进程内广播的 WebSocket 服务就完成了。

4. 引入 Redis 实现跨进程/跨服务器消息广播

单 Worker 进程内的广播无法满足实际需求。我们需要一个“中间人”来协调所有 Worker 进程，甚至所有服务器节点。Redis 的发布订阅（Pub/Sub）模式是解决此问题的经典方案。

4.1 架构设计：发布-订阅模式

核心思想是：

1. 每个 Worker 进程在启动时，都订阅（Subscribe）一个共同的 Redis 频道（例如push_channel）。
2. 当某个 Worker 需要广播消息时，它不直接发送给它的连接，而是将消息发布（Publish）到push_channel。
3. Redis 会将这条消息推送给所有订阅了该频道的 Worker 进程。
4. 每个 Worker 进程收到 Redis 推送的消息后，再遍历自己进程内的连接，将消息发送出去。

这样，无论消息源自哪个 Worker 或哪台服务器，所有在线的客户端都能收到。

4.2 安装依赖与修改代码

首先，确保服务器安装了 Redis，并且 PHP 有 Redis 扩展（推荐使用phpredis或predis客户端库）。我们使用 Composer 安装predis，因为它更轻量且纯 PHP 实现。

composer require predis/predis

修改Events.php，增加 Redis 客户端属性和初始化逻辑。我们创建一个新的PushServer类来整合：

<?php // Applications/Push/PushServer.php namespace Applications\Push; use Workerman\Worker; use Workerman\Timer; use Predis\Client as RedisClient; class PushServer { /** * @var RedisClient Redis 客户端实例 */ protected static $redis = null; /** * Redis 配置 */ const REDIS_CONFIG = [ 'scheme' => 'tcp', 'host' => '127.0.0.1', // Redis 服务器地址 'port' => 6379, 'database' => 0, // 'password' => 'your_password', // 如果有密码 ]; /** * 广播频道名称 */ const BROADCAST_CHANNEL = 'push_system_broadcast'; /** * 初始化 Redis 连接 * @return RedisClient */ public static function getRedis() { if (self::$redis === null) { self::$redis = new RedisClient(self::REDIS_CONFIG); } return self::$redis; } /** * 启动 Worker 时的回调 * @param Worker $worker */ public static function onWorkerStart($worker) { echo "Worker {$worker->id} starting...\n"; // 1. 初始化 Redis 并订阅广播频道 $redis = self::getRedis(); // 创建一个新的 Redis 连接用于订阅（订阅会阻塞，必须用独立连接） $subscriber = new RedisClient(self::REDIS_CONFIG); // 在独立协程/进程中处理订阅（这里简化，实际生产环境需考虑连接管理） // 使用定时器模拟一个简单的订阅循环（注意：这不是标准做法，仅作演示。生产环境应用异步客户端或 workerman/redis） Timer::add(1, function() use ($subscriber, $worker) { try { // 监听频道 $pubsub = $subscriber->pubSubLoop(); $pubsub->subscribe(self::BROADCAST_CHANNEL); foreach ($pubsub as $message) { if ($message->kind === 'message') { // 收到来自其他进程/服务器的广播消息 $data = json_decode($message->payload, true); if ($data && $data['type'] === 'broadcast') { self::broadcastToLocalConnections($worker, $message->payload); } } } } catch (\Exception $e) { echo "Redis subscribe error in Worker {$worker->id}: " . $e->getMessage() . "\n"; } }); // 2. 启动心跳检测定时器 Timer::add(30, function() use ($worker) { $time_now = time(); foreach ($worker->connections as $connection) { if (empty($connection->last_heartbeat_time) || $time_now - $connection->last_heartbeat_time > 55) { echo "Worker {$worker->id}: Connection {$connection->id} timeout, closing.\n"; $connection->close(); } } }); } /** * 向本 Worker 进程内的所有连接广播消息 * @param Worker $worker * @param string $message JSON 字符串 */ public static function broadcastToLocalConnections($worker, $message) { foreach ($worker->connections as $conn) { $conn->send($message); } } /** * 向全局（所有 Worker、所有服务器）广播消息 * @param string $message JSON 字符串 */ public static function broadcastToGlobal($message) { $redis = self::getRedis(); $redis->publish(self::BROADCAST_CHANNEL, $message); } // ... 保留原有的 onConnect, onMessage, onClose, onError 方法，但需修改 onMessage ... public static function onMessage($connection, $data) { $connection->last_heartbeat_time = time(); $message = json_decode($data, true); if (!$message) { $connection->send(json_encode(['error' => 'Invalid JSON'])); return; } switch ($message['type'] ?? '') { case 'ping': $connection->send(json_encode(['type' => 'pong', 'time' => time()])); break; case 'broadcast': // 关键修改：不再本地广播，而是发布到 Redis $broadcastMsg = json_encode([ 'type' => 'broadcast', 'from' => $message['from'] ?? 'unknown', 'content' => $message['content'] ?? '', 'time' => date('Y-m-d H:i:s') ]); // 发布到 Redis 频道 self::broadcastToGlobal($broadcastMsg); // 注意：消息会通过 Redis 订阅循环回来，再由各个 Worker 发送给其连接 break; default: $connection->send(json_encode(['type' => 'echo', 'received' => $message])); } } // ... onConnect, onClose, onError 方法保持不变 ... }

然后，修改start_websocket.php，使用新的PushServer类：

<?php // Applications/Push/start_websocket.php use Workerman\Worker; require_once __DIR__ . '/PushServer.php'; $ws_worker = new Worker('websocket://0.0.0.0:2346'); $ws_worker->count = 4; // 使用 PushServer 类中的静态方法 $ws_worker->onWorkerStart = ['Applications\Push\PushServer', 'onWorkerStart']; $ws_worker->onConnect = ['Applications\Push\PushServer', 'onConnect']; $ws_worker->onMessage = ['Applications\Push\PushServer', 'onMessage']; $ws_worker->onClose = ['Applications\Push\PushServer', 'onClose']; $ws_worker->onError = ['Applications\Push\PushServer', 'onError']; if (!defined('GLOBAL_START')) { Worker::runAll(); }

4.3 验证分布式广播

1. 启动服务：php start.php start。你会看到 4 个 Worker 进程启动，每个都会打印Worker X starting...。
2. 连接多个客户端：打开两个以上的浏览器标签页，分别运行之前的前端测试代码，连接到 WebSocket 服务器。
3. 测试广播：在其中一个客户端发送广播消息：

   ws.send(JSON.stringify({type: 'broadcast', from: 'user1', content: 'Hello, everyone!'}));

4. 观察结果：所有连接的客户端（无论它们被分配到哪个 Worker 进程）都应该收到这条广播消息。同时，在服务器终端，你会看到消息被发布到 Redis，然后各个 Worker 收到并转发。

至此，一个支持跨进程广播的单机推送系统就完成了。如果要扩展到多台服务器，架构几乎不变，只需确保所有服务器上的 Worker 进程都连接到同一个 Redis 实例（或集群），并订阅相同的频道即可。

5. 生产环境部署、监控与问题排查

将上述代码直接用于生产环境是远远不够的。下面从部署、监控、排错和优化几个维度，阐述需要关注的要点。

5.1 部署与进程管理

在开发环境我们使用php start.php start在前台运行。生产环境必须使用守护进程（daemon）模式，并且需要进程管理器来保证服务异常退出后能自动重启。

1. 以守护进程模式启动：

php start.php start -d

使用-d参数后，Workerman 会转入后台运行，所有日志默认输出到标准输出（stdout）。建议重定向到日志文件：

php start.php start -d >> /path/to/your/logs/workerman.log 2>&1

2. 使用进程管理器（推荐 systemd 或 supervisor）：以 systemd 为例，创建服务文件/etc/systemd/system/php-push.service：

[Unit] Description=PHP Push System (Workerman) After=network.target redis.service [Service] Type=simple User=www-data # 根据你的运行用户修改 Group=www-data WorkingDirectory=/path/to/your/php-push-system ExecStart=/usr/bin/php /path/to/your/php-push-system/start.php start -d Restart=always RestartSec=3 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target

然后启用并启动服务：

sudo systemctl daemon-reload sudo systemctl enable php-push sudo systemctl start php-push sudo systemctl status php-push # 查看状态

5.2 关键配置参数与调优

Workerman 和系统层面有一些关键参数需要调整，以支撑高并发。

1. Worker 配置 (start_websocket.php中)：

• $worker->count：设置为 CPU 核心数。太多会增加进程切换开销，太少无法利用多核。
• $worker->reloadable：默认true，表示收到SIGUSR1信号（php start.php reload）时平滑重启。生产环境建议保持开启，用于代码更新。
• $worker->name：给 Worker 起个名字，方便在ps aux中识别。

2. 系统层面调优：

• 文件描述符限制：一个 TCP 连接占用一个文件描述符。使用ulimit -n查看当前限制。生产环境建议设置为 65535 或更高。

  # 临时生效 ulimit -n 65535 # 永久生效，修改 /etc/security/limits.conf * soft nofile 65535 * hard nofile 65535

• Linux 内核参数：调整 TCP 连接相关参数，例如net.core.somaxconn（监听队列长度）、net.ipv4.tcp_tw_reuse（TIME_WAIT 端口重用）等，需要根据实际压力测试调整。

3. Redis 连接池与异步客户端：上面的示例中，每个 Worker 使用独立的 Redis 连接进行订阅和发布。在高并发下，这可能会成为瓶颈。生产环境应考虑：

• 使用连接池管理 Redis 连接。
• 使用 Workerman 官方推荐的异步 Redis 客户端（如workerman/redis），避免阻塞 Worker 进程的事件循环。
• 对于超大规模部署，考虑使用 Redis Cluster 替代单点 Redis。

5.3 常见问题排查清单

当推送系统出现问题时，可以按照以下清单逐项排查。

5.4 日志与监控

没有日志的系统如同盲人摸象。除了 Workerman 自带的输出，应该将关键事件记录到文件或日志系统。

1. 集成 Monolog（推荐）：

composer require monolog/monolog

在PushServer.php的onWorkerStart中初始化日志：

use Monolog\Logger; use Monolog\Handler\StreamHandler; $log = new Logger('push_system'); $log->pushHandler(new StreamHandler('/path/to/logs/push.log', Logger::INFO)); // 然后使用 $log->info(), $log->error() 记录日志

2. 关键日志点：

• 连接建立/关闭（记录连接ID和来源IP）。
• 收到/发送特定类型的消息（如广播）。
• Redis 发布/订阅操作。
• 心跳检测触发的连接清理。
• 任何异常和错误。

3. 系统监控：

• 进程存活：通过 systemd 或 supervisor 监控。
• 连接数：可以通过 Workerman 的$worker->connections数量粗略估算，或通过netstat命令。
• 服务器资源：CPU、内存、网络 IO。
• Redis 状态：内存使用、连接数、命令延迟。

6. 扩展方向与最佳实践

基础推送系统搭建完成后，可以根据业务需求向以下几个方向深化。

6.1 用户-连接映射与私信推送

目前系统只有广播，实际业务需要点对点推送。这需要在服务端维护一个“用户ID”到“连接对象”的映射关系。由于连接对象无法跨进程序列化，这个映射关系必须存储在共享存储中，如 Redis。

思路：

1. 客户端连接后，发送一个认证消息，包含其用户唯一标识（如user_id）。
2. 服务端在onMessage中处理认证，将user_id与当前连接的$connection->id关联起来，存储到 Redis 的 Hash 或 Sorted Set 中，Key 可以设计为user_conn:{user_id}，Value 为worker_id:connection_id。
3. 当需要向特定用户推送时，从 Redis 中查出该用户所在的 Worker 和 Connection ID，然后通过 Redis 发布一个“私信”频道消息，目标 Worker 收到后，找到对应的连接并发送。
4. 在onClose中，需要清理 Redis 中的映射关系。

这是一个典型的有状态连接管理问题，设计时需要仔细考虑并发更新和过期清理。

6.2 消息持久化与可靠性保证

当前的系统是“发后即忘”的。如果客户端临时断线重连，会错过离线期间的消息。对于订单状态等关键消息，需要引入消息持久化。

方案：

1. 存储离线消息：当发布一条针对特定用户的消息时，如果检测到该用户不在线（Redis 中无映射），则将消息存入持久化队列（如 Redis List 或 MySQL）。
2. 用户上线后拉取：用户重连并认证后，服务端从持久化队列中取出该用户的未读消息，逐一推送。
3. 消息确认机制：客户端收到消息后，发送一个 ACK 回执，服务端才从队列中删除该消息，防止消息丢失。

6.3 协议优化与安全加固

1. 协议压缩：对于频繁的聊天或实时数据，可以考虑对 WebSocket 传输的数据进行压缩（如permessage-deflate扩展）。
2. WSS (WebSocket Secure)：生产环境务必使用wss://，即 WebSocket over TLS。这可以通过在 Workerman 前配置 Nginx 反向代理并启用 SSL，或者使用 Workerman 的 SSL 上下文配置来实现。
3. 连接认证：不应允许任意客户端连接。可以在onConnect或首次onMessage时进行 Token 验证，无效则立即断开。
4. 频率限制：防止恶意客户端发送大量消息耗尽资源。可以在onMessage中针对连接 ID 或用户 ID 进行限流。

6.4 从 Workerman 到 Swoole

如果你追求极致的性能，并且环境允许安装 PHP 扩展，可以考虑将底层框架从 Workerman 迁移到Swoole。Swoole 作为 C 扩展，在性能上有显著优势，特别是其协程特性可以更高效地处理大量并发 I/O。但 Swoole 的学习曲线和调试复杂度也更高。迁移并非简单替换类名，涉及到底层事件循环、进程模型和协程编程范式的转变，需要充分评估和测试。

构建一个生产级的 PHP 推送系统，技术选型只是起点，真正的挑战在于对连接生命周期、状态同步、资源管理和异常处理的精细把控。从单机 Worker 内广播，到基于 Redis 的跨进程协同，这套架构提供了一个清晰可扩展的基线。后续无论是引入用户会话管理、增加消息持久化，还是整合更复杂的微服务，核心思想都是将“连接”与“业务逻辑”解耦，通过中间件（如 Redis）进行状态同步和消息路由。在落地时，务必结合业务体量，从小规模验证开始，逐步完善监控、告警和容灾机制，让推送服务成为业务中可靠的基础设施，而非脆弱的短板。