PHP/Laravel：异步分批向客户端返回搜索结果的最佳实践

一、Laravel Websockets 方案：解决顾虑后的最优选择 #

你担心的两个问题都有明确的优化方案：

• 进程开销：Laravel Websockets 默认基于 Ratchet，单进程就能支撑上千并发连接，中小规模流量完全够用。如果流量较大，可切换为 Redis 广播驱动，配合多进程横向扩展，常驻进程的资源消耗远低于频繁创建的 HTTP 请求。
• 私有频道登录限制：无需强制用户登录，可采用两种方式：
  • 使用公开频道：为每个搜索请求生成唯一的 search_id，客户端订阅 search-{search_id} 公开频道，后端仅向该频道推送对应结果。
  • 自定义频道授权：客户端连接时携带 search_id，在频道授权逻辑中验证该 ID 是否存在于临时缓存（如 Redis，设置15-30分钟过期），验证通过即可订阅，实现专属推送。

实现流程：

1. 用户提交搜索请求，后端生成 search_id 存入缓存，同时分发多个异步任务调用外部 API。
2. 客户端连接 Websockets，订阅对应频道。
3. 每个异步任务完成后，通过 broadcast(new SearchResultEvent($search_id, $result)) 推送结果，客户端实时渲染。

二、轮询方案：优化后可满足低实时性场景 #

针对你担心的延迟和资源问题，可通过以下方式优化：

• 降低延迟：短轮询（1-2秒间隔）结合缓存标记，后端每返回一个API结果，就设置 has_new:{search_id} 标记，客户端轮询时先检查标记，有新结果再拉取具体数据，减少无效请求。
• 减少资源消耗：改用长轮询（Comet），客户端发起请求后，后端挂起连接直到有新结果或超时（如10秒）再返回，大幅降低请求频次。Laravel 可通过 response()->stream() 实现长轮询逻辑，Nginx 需调整 worker_connections 适配并发连接数。

适用场景：部署环境无法运行常驻 Websockets 进程（如共享主机），或业务对实时性要求不高。

三、选型决策 #

• 优先选 Websockets 方案：航班搜索这类对实时体验要求高的场景，Websockets 能带来最佳用户体验，优化后的方案完全能解决你的顾虑。
• 轮询方案作为备选：仅当 Websockets 部署受限或流量极小的时候考虑。
• 兼容性降级：若需兼容老浏览器，可实现双方案自动切换——优先尝试 Websockets，连接失败则 fallback 到长轮询。

内容的提问来源于stack exchange，提问作者Carl Mahnke