大佬们帮我看看这个异步任务怎么设计

能支持 2 个点就稳妥了:
1 要标记好处理和未处理, 这样就能断点续传, 坏了还能接着整
2 要支持重入, 也就是就算把 1 点中的所有标记重置为未处理, 系统可以重新跑一遍, 但是也不会有额外的副作用

@shoaly 感谢大佬的提醒，断点续传这个没考虑，要加进去，像你 2 中说的，感觉像这种 `while(job = jobs.shift()) run(job)` “系统”了

嗯.... while(true) 这种循坏 还不够, 可以升级成
go woker(job_channel)
go woker(job_channel)
go woker(job_channel)
go woker(job_channel)

waitgroup.Wait()

@shoaly 看来还是单独弄个合成视频的应用部署比较靠谱

脚本执行没错
主要是看你的状态传递是什么需求,是否可以延迟获取状态

@wangyzj 就是传递进度，还有最后成功、失败这些，状态传递给前端通过 websocket 或者轮询几下

你这个合成视频就是一个任务，你把任务存到数据库，然后服务启动的时候轮询这些任务，将未完成的任务继续跑不就行么，我理解的不知道对不对

问下哈， 处理视频合成 的任务， 一般都比比较 耗费内存吧 ， 你的这个任务会不会 超出内存限制然后被杀掉 ？

@ksice 大佬说的对啊，感觉这种方式要简单些，高

@flyingfz 多谢提醒，我需要去摸索摸索，不过 ffmpeg 应该有限制资源使用的参数

写一个新的服务，扫描数据库，或者队列找没有完成的任务，或者新的任务，失败了在重试，完成之后标记下状态。
http 接收到任务之后就写到数据库，或者队列里面。

@wzwwzw 就这样搞了