Composer节点调度负载怎么分配？多工作节点负载均衡实操-composer-PHP中文网

composer本身不负责负载调度，真正的负载分发由nginx反向代理或docker内置dns轮询实现；--scale仅启动多实例，健康检查、故障剔除、权重分配等均需外部配合。

composer节点调度负载怎么分配？多工作节点负载均衡实操

Composer 节点调度负载分配，本质不是 Composer 自己在做调度，而是你用它编排的服务，由外部代理（如 Nginx）或 Docker 内置 DNS 轮询来分发请求。Composer 本身不提供动态负载感知或权重调整能力，这点必须先划清边界。

很多人以为执行 docker compose up --scale worker=4 就完成了负载均衡，其实只完成了“多实例启动”这一步。后续请求是否真能打到不同容器、失败后是否自动绕过、流量是否按需倾斜——这些全靠上层代理决定。

docker-compose.yml 中写 deploy: { replicas: 4 } 在非 Swarm 模式下会被忽略，Docker Desktop 默认不启用 Swarm，所以必须用 --scale 命令
Docker 内置 DNS（如 worker 解析为多个 IP）仅支持轮询（round-robin），且是客户端缓存行为，不感知健康状态
没有 health_check 配合时，挂掉的容器仍会出现在 DNS 列表里，导致 502/Connection refused

Nginx 的 upstream 是本地负载均衡的主力，但默认配置容易踩坑。比如只写 server worker:8080;，等效于轮询，但无法应对长连接、慢响应、节点故障等真实场景。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

least_conn：比轮询更合理，适合 PHP/Java 等处理时间波动大的服务，但需确认后端支持 HTTP keepalive，否则连接数统计失真
weight=3：仅在轮询或 ip_hash 下生效；least_conn 下 weight 被忽略（Nginx 官方文档明确说明）
max_fails=3 fail_timeout=30s：必须配，否则宕机容器仍持续收请求；fail_timeout 不是“恢复时间”，而是“标记为不可用”的持续窗口
keepalive 32：复用上游连接，减少握手开销，但要配合后端的 proxy_http_version 1.1 和 Connection "keep-alive"

Nginx 默认不做主动探活，health_check 只在 Plus 版或使用第三方模块（如 nginx_upstream_check_module）才支持。免费方案得靠 worker 主动暴露 /health 端点，并用外部工具触发 reload 或结合 Consul 等做服务发现。

最简做法：每个 worker 提供 /health 返回 200，用 curl -f http://worker:8080/health + shell 脚本定期检查，异常时调用 nginx -s reload
进阶做法：用 docker-compose.yml 中的 healthcheck 字段定义探测逻辑，再通过 docker events --filter 'event=die' --filter 'event=start' 监听容器状态变化
注意：healthcheck 本身不联动 Nginx，它只影响 docker ps 的 STATUS 列和依赖顺序，不能自动剔除 upstream 成员

负载均衡解决的是“请求分发”，不是“状态同步”。如果 worker 有本地缓存、文件写入、定时任务或 Session 存储，直接 scale 会出问题。

避免本地文件：所有日志走 stdout，临时文件挂 tmpfs 卷，上传文件必须存对象存储（如 MinIO）或共享 NFS
Session 不存本地：统一配 Redis，session.save_handler=redis + session.save_path="tcp://redis:6379"，别用 files 方式
定时任务禁用：多副本下 cron 会重复触发，要么关掉所有 worker 的定时器，只留一个调度中心；要么用分布式锁（如 Redis SETNX）包装任务入口
数据库连接池独立：每个 worker 自建连接池，不要共用一个连接，避免连接数爆限或事务隔离异常

真正难的不是起四个容器，而是让这四个容器在故障、扩容、慢响应、连接复用、状态共享这些细节上不互相拖后腿。很多线上问题都出在 healthcheck 没配、upstream 缺 max_fails、Session 还在写本地文件这种地方。