长运行请求下HTTP连接生命周期处理及重I/O任务方案咨询

问题解答 #

1. 调用res.json返回后的连接状态 #

• 当res.json()执行完成时，完整的HTTP响应已经写入内核发送缓冲区，正常客户端收到完整响应后会认为本次请求已结束：若使用短连接则会主动关闭socket，若使用HTTP/1.1长连接则会将连接放回连接池复用，不会为本次请求持续持有连接。
• 你当前的代码存在特殊情况：由于在res.json后加了await heavyIO()，整个async handler的Promise还未完成，Express不会标记请求处理结束。若客户端没有主动断开连接，在Node.js HTTP服务默认超时时间（120秒）到达前，socket会保持打开状态，超时后服务端会主动销毁socket，不存在半打开状态，除非中间网络中断未传输FIN包。

2. 是否需要手动销毁socket #

不需要。你已经将完整响应发送给客户端，客户端会自行处理连接的关闭或复用，手动销毁socket反而可能导致客户端未收全响应，或者异常销毁连接池中的可用连接，影响后续正常请求。你当前需要解决的核心问题不是操作socket，而是将重IO任务的生命周期和HTTP请求的生命周期解绑。

3. 重IO任务29分钟后报错进入错误处理的问题 #

存在严重问题：

• Node.js HTTP服务默认的socket超时时间只有2分钟，远低于30分钟的任务耗时，早在任务报错前，socket就已经被服务端主动销毁，此时Express错误处理逻辑只能在服务端打印错误日志，无法通知客户端任务失败。
• 任务执行过程中如果发生服务重启、部署、进程崩溃，任务会直接丢失，没有任何持久化和重试机制。
• 请求上下文（req、res对象）会被长耗时任务持有，直到任务结束才会被GC回收，高并发场景下会触发严重内存泄漏。

4. 当前处理模式的合理性及替代方案 #

当前模式完全不合理，生产环境绝对不能使用，必须采用异步任务解耦方案：

1. 接收请求时生成唯一任务ID，将任务元信息存入Redis、数据库等持久化存储，标记状态为待执行
2. 将任务投递到专用的任务队列（如BullMQ、RabbitMQ），立即返回给客户端任务ID，提示任务已启动
3. 部署独立的Worker进程消费队列任务，执行重IO操作，过程中更新存储中的任务状态（运行中、成功、失败、进度等）
4. 按需提供任务进度查询接口，或通过WebSocket、Webhook等方式主动通知客户端任务结果。

临时修正方案（仅测试用，不可用于生产） #

如果只是临时测试不想搭任务队列，可以修改代码避免任务绑定请求生命周期，同时捕获错误避免进入Express默认错误处理：

app.get('/start', asyncHandler(async (_req, res) => {
  res.json('ok...started process')
  // 不要await，直接异步执行，自己捕获错误处理
  heavyIO()
    .then(() => console.log(`FINISHED I/O at ${new Date().toISOString()}!`))
    .catch(err => console.error('IO task failed:', err))
}))

该方案依然存在任务丢失、内存泄漏、超时等问题，仅可用于本地测试。

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