温暖工人的Go工人模式

我正在解决一个问题,我有一组“热情的工人”。这意味着它们被维护在内存中,维护自己的上下文并且是可调用的。我一直在研究各种 Go Worker 实现,但都依赖于闭包或返回结果的简单计算函数。

我找到了一个工作人员的示例,它可以让我启动上下文并根据最大队列和最大例程限制将任务分配给它们: https: //github.com/cahitbeyaz/job-worker/blob/master/main.go #L131

然而,这种模式不允许我从上下文返回结果并将其反馈回来。我还使用 Web 服务器,因此 Web 处理程序必须接收结果并做出相应响应。

是否有我应该/可以遵循的特定/更好的模式,或者我可以适应工作人员示例的方法?

附言。起初我以为我可以创建一个 ResultQueue,其中结果被推回并由 Web 处理程序使用。不过,我认为队列的顺序不可靠。


饮歌长啸
浏览 113回答 1
1回答

红颜莎娜

解决方案非常简单(我确实把它复杂化了)。不确定这实际上有多有效,但怀疑它并不太糟糕。仍然欢迎提出更好模式的建议:在作业定义中声明一个通道来反馈结果:type Job struct {&nbsp; &nbsp; Request string&nbsp; &nbsp; Params&nbsp; []string&nbsp; &nbsp; Result chan Result}在你的工作进程中,而不是仅仅返回返回值,而是通过通道传递结果结构:job.Result <- Result{&nbsp; &nbsp; Response: result.String(),&nbsp; &nbsp; Headers:&nbsp; []string{},}现在,在 Web 处理程序中,只需等待通道即可:disatcher.jobQueue <- jobresult := <- job.Result愚蠢的我。不知道为什么要花2个小时的努力。:-p 经验教训:Go 并发性非常强大。只是别想太多。
打开App,查看更多内容
随时随地看视频慕课网APP

相关分类

Go