golang 执行长时间的任务的最佳实践是什么？

30s 接口早 timeout 了

1. 你的 server 并发能力一定远超你的模型生成能力。

@fffq 不是有长连接吗，keep-alive

先看你们显卡顶不顶得住 1 3 吧

@zhengfan2016 #3
http 的 keep-alive 和你一次请求是否超时没有任何关系，你需要对 http server 对框架设置自定义的超时时间，对服务上层的负载均衡做自定义超时时间，如果还有 cdn 还得去 cdn 看看是否能设置最大超时时间

因为 comfyUI 也是第二点逻辑, 因此我的想法是:
golang 这块两个进程: 1. 给前端提供服务(创建任务, 轮询结果); 2. 后台执行任务.

非最佳实践：

1.触发式请求用常规 http request
2.耗时任务用异步协程处理，结果用 websocket 或 sse 推送给前端。

2 ，但不用搞 redis 那么麻烦，轻量化一点用 SQLite 就行了（比如 goqite ）

1 3 的问题是对中断推理支持不好。最好能弄个 websocket ，POST /task 创建任务，/task/:id 和客户端长通信，实时返回推理状态或者下发新指令（例如中断）。

asynq 吧。当普通任务写就好了。也够轻

靠 http 接口的超时 如果你套了 nginx nginx 那边超时也得跟着设置 很麻烦的 不如 redis 然后前端轮询各种都随你

方案 2 ，如果是自己的小玩具 无脑等待就好了， 一般生图这种都是任务状态 被动触发的

websocket 之类的长连接推送进度。进页面查询自己的 taskID ，根据 id 和后端建立 websocket 连接获取实时进度

肯定 1 啊，web 框架对每个 controller 调用不还是用的 go 协程。你 controller 等待生成时是直接 io 卡死在那，go 的调度器会自动处理的。你费那么大劲用 redis 或 channel 根本没任何必要（除非有什么持久化或者生成一半要取消之类的需求）

你唯一要考虑的就是调用请求的客户端还有你 web 服务器前的网关的最大超时时间

2

每个 user agent 每层 gateway 都可能有自己的 timeout ，不像 2 这样 你还要相信别的很多东西

搞成异步的，完成了之后主动推送一个事件，然后提供图片 URL 。

你不考虑用户因为网络波动导致直接断开连接吗？那不是一切重来。

这首先是一个接口设计问题

小 demo 就同步，怎么简单怎么来。我写 demo 不爱用 web ，直接命令行跑起来就算。
生产环境必须异步。
1 ，负载能力决定了任务需要队列，耗时包含了排队时间，不可能一定是 30s 的。任务的逻辑超时时间取决于业务决策并且可能天天变化。
2 ，技术上一个链接的超时时间取决于链路中多个组件的设置。客户端、代理、网关、应用。。。远不如短连接+异步来得简洁稳固。
3 ，API 和 task 资源池解耦，甚至我们 API 和调度也解耦了。这样 API 的可靠性增加，task 计算池的弹性增加。
4 ，对服务失效有更高的状态恢复能力。
5 ，接口层 task 状态可推可拉，对客户端也挺灵活挺友好。
6 ，整个系统的吞吐量瓶颈几乎只剩一个：task 计算池了。API 和调度都很难形成瓶颈了。

如果任务比较多，就搞一个异步任务中心，这种长时间的多个异步任务交给它来执行，异步任务中心执行完了在通知你的 Go 程序，比如用 Go 写个 task cron 异步执行系统或找个开源的

redis 队列是什么? 你是搞 php 的?