如何对运行中的Workerman进行无缝扩容？增加服务器节点的步骤-php教程-PHP中文网

直接修改$worker->count不生效，因其仅在启动时读取；必须通过reload平滑重启（更新子进程数）或restart彻底重启主进程才能生效。

如何对运行中的workerman进行无缝扩容？增加服务器节点的步骤

Workerman 的进程数由 $worker->count 控制，但这个值只在 Worker 启动时读取一次。运行中直接修改变量（比如在 onWorkerStart 里重赋值）完全无效——子进程早已 fork 完毕，内存隔离，改了也白改。

真正可行的方式只有两种：

向主进程发送 reload 信号：Workerman 会平滑关闭旧子进程、拉起新子进程（数量按当前代码里的 $worker->count 值），连接不中断，但要求代码已提前写好目标值（比如从配置文件读取）
用进程管理器（如 Supervisor、systemd）执行 restart：更彻底，但会有短暂连接断开窗口，适合低敏感业务
若用 Docker/K8s，应避免手动改 count，而是通过环境变量 + 启动脚本注入，再触发滚动更新

水平扩容的本质不是“让某台机器变强”，而是“让请求能分到新机器上”。Workerman 本身不提供服务发现或自动注册能力，所有节点都是独立、无状态（或需自行管理状态）的孤岛。

所以加节点前必须确认以下三点已就绪：

新服务器已部署相同版本的 Workerman 应用，且监听端口、协议一致（如都监听 websocket://0.0.0.0:2346）
前端负载均衡器（Nginx / HAProxy / 云 SLB）已将新节点 IP 加入后端服务器池，并开启健康检查（例如定期 GET /status 端点）
客户端连接逻辑不硬编码单点地址（比如 WebSocket URL 写死 ws://old-server:2346），而应指向负载均衡 VIP 或域名

扩容后常出现“老连接卡住不释放”“新节点负载始终偏低”，根本原因不是扩容操作本身，而是连接生命周期没管好。

Ribbi

一款AI视频创作工具，主要用于全能型AI视频创作与运营平台，适合需要提升相关任务效率的用户。

下载

Workerman 默认不会主动踢掉空闲连接，必须靠你自己定义清理策略：

在 onConnect 中设置连接超时：$connection->timeout = 60;（单位秒）
实现心跳检测：客户端定时发 ping，服务端在 onMessage 中刷新 $connection->lastPingTime = time();，再配合定时器扫描并 close 超时连接
务必实现 onClose 回调：清理用户上下文、释放资源、通知其他服务（如从 Redis 在线列表移除）
如果用了 Redis 存连接映射，注意不同节点间无法共享内存连接对象，所有跨节点操作必须走外部存储

在 Kubernetes 中执行 kubectl scale deploy/workerman --replicas=6 后，流量没立刻打到新 Pod，常见于 readinessProbe 配置不当或客户端复用连接。

典型问题和对策：

readinessProbe 返回 200 但 Workerman 还没 ready：Probe 脚本应检查 Worker::$pidMap 是否非空，或用 netstat -tlnp | grep :2346 确认端口已监听
客户端（尤其是浏览器 WebSocket）复用 TCP 连接：已有长连接不会自动切到新节点，只能等自然断连或主动重连
Service 的 sessionAffinity 设为 ClientIP：导致同一 IP 始终打到同一 Pod，关掉它（默认是 None）
新 Pod 启动慢：检查 Dockerfile 是否把 composer install 放在最后，避免镜像层缓存失效拖慢构建

Workerman 的扩容动作本身很简单，难的是让整个链路——从连接建立、路由分发、状态同步到连接回收——每个环节都不掉链子。最容易被忽略的，其实是客户端重连策略和后端健康检查的响应延迟。