Laravel如何利用RoadRunner实现协程并发【实战】-php教程-PHP中文网

roadrunner 本身不提供 php 层协程，其“协程并发”实为 go 层 goroutine 调度请求 + 常驻 php worker 进程同步执行；php 内部仍为阻塞模型，file_get_contents、eloquent 等操作不会自动异步，需手动集成 amphp 或 swoole 协程客户端才能获得真正协程收益。

laravel如何利用roadrunner实现协程并发【实战】

RoadRunner 本身不提供 PHP 层协程，Laravel 也无原生协程支持；所谓“协程并发”实际是 RoadRunner 的 Go 层并发调度 + PHP Worker 进程复用，不是 yield 或 co::create 那种协程。

为什么 `php artisan octane:start --server=roadrunner` 不等于协程

RoadRunner 是 Go 写的服务器，它用 Go 协程（goroutine）管理 HTTP 连接和请求分发，但每个请求最终交给一个常驻的 PHP 进程（Worker）同步执行。这个 PHP 进程里没有协程调度器，file_get_contents、curl_exec、Eloquent 查询等仍是阻塞的——除非你手动集成 Swoole 协程客户端或改用 amphp 等异步库。

常见错误现象：开了 --workers=8，压测时 CPU 没跑满，但响应延迟陡增 → 实际是 PHP Worker 被 I/O 卡住，Go 层在排队
真正起作用的是“连接复用”和“进程常驻”，不是 PHP 层并发能力提升
如果你依赖 sleep(1) 或第三方 SDK 的同步 HTTP 调用，RoadRunner 无法帮你“协程化”它们

必须配 `rr.yaml` 才能启用 RoadRunner 的并发调度能力

仅靠 octane:start 命令启动，Octane 会 fallback 到内置的 FrankenPHP 或单线程模式，--workers 参数无效。RoadRunner 的并发模型由 rr.yaml 中的 pool.num_workers 和 http.pool 控制，不是 Octane 的参数。

Laravel Creem Agent

Creem 支付商店助理 — 查询订阅、客户、交易、产品，执行心跳检查，管理本地 Laravel支付商店。

下载

在项目根目录新建 rr.yaml，至少包含：

http:
  address: 0.0.0.0:8080
  pool:
    num_workers: 4
    max_jobs: 500
    supervisor:
      binary: "php"
      arguments: ["artisan", "roadrunner:worker"]

num_workers: 4 表示启动 4 个独立 PHP 进程，每个持有自己的数据库连接、Redis 客户端、内存实例
别漏掉 max_jobs: 500：防止内存缓慢泄漏，到数自动重启 Worker
启动命令必须是 ./vendor/bin/rr serve，不是 php artisan octane:start

`roadrunner:worker` 启动脚本不能有阻塞初始化逻辑

Laravel 的 roadrunner:worker 命令会预加载框架并进入循环，一旦某个 Worker 在启动阶段卡住（比如连不上 Redis、读取大配置文件、触发慢日志），整个进程就 hang 住，后续请求全堵死。

典型问题：config/services.php 里写了 file_get_contents('/path/to/big.json') → 每个 Worker 启动都读一次，4 个 Worker 就读 4 次
数据库连接池配置无效：RoadRunner 不识别 config/database.php 里的 'pool' 键（那是 Swoole/RoadRunner Bridge 用的），必须靠 rr.yaml 的 pool.max_idle_connections 和 pool.max_active_connections 控制（需 v2024+）
环境变量加载顺序错乱：Sail 或 Docker 下，.env 可能未在 Worker 启动前加载，导致 env('DB_HOST') 为 null

高并发下请求排队延迟，本质是 Worker 数量与 I/O 能力不匹配

当并发请求数 > rr.yaml 中 pool.num_workers，多余请求会在 RoadRunner 的 Go 层排队，表现为 P99 延迟跳变（比如从 50ms 突增至 2s）。这不是 Laravel 慢，是 Worker 被占满后没地方处理新请求。

不要盲目调高 num_workers：4 核机器设成 16，可能因上下文切换和内存争抢反而更慢
先确认瓶颈在哪：strace -p $(pgrep -f 'roadrunner:worker') -e trace=connect,sendto,recvfrom 看是否卡在下游服务
真实优化点是缩短单个 Worker 处理时间：把 Http\Client 换成 amphp/http-client，用 AsyncDatabase 替代 Eloquent 同步查询
如果只是想“撑住并发”，加负载均衡比硬堆 Worker 更可靠

真正容易被忽略的点：RoadRunner 的并发模型是“Go 层分发 + PHP 层同步执行”，它不改变 PHP 代码的执行方式。想获得协程收益，必须让 PHP Worker 自身具备异步能力，而不是指望 RoadRunner “自动协程化”。