为了账号安全,请及时绑定邮箱和手机立即绑定

温暖工人的Go工人模式

温暖工人的Go工人模式

Go
饮歌长啸 2023-07-31 16:03:28
我正在解决一个问题,我有一组“热情的工人”。这意味着它们被维护在内存中,维护自己的上下文并且是可调用的。我一直在研究各种 Go Worker 实现,但都依赖于闭包或返回结果的简单计算函数。我找到了一个工作人员的示例,它可以让我启动上下文并根据最大队列和最大例程限制将任务分配给它们: https: //github.com/cahitbeyaz/job-worker/blob/master/main.go #L131然而,这种模式不允许我从上下文返回结果并将其反馈回来。我还使用 Web 服务器,因此 Web 处理程序必须接收结果并做出相应响应。是否有我应该/可以遵循的特定/更好的模式,或者我可以适应工作人员示例的方法?附言。起初我以为我可以创建一个 ResultQueue,其中结果被推回并由 Web 处理程序使用。不过,我认为队列的顺序不可靠。
查看完整描述

1 回答

?
红颜莎娜

TA贡献1842条经验 获得超12个赞

解决方案非常简单(我确实把它复杂化了)。不确定这实际上有多有效,但怀疑它并不太糟糕。仍然欢迎提出更好模式的建议:


在作业定义中声明一个通道来反馈结果:


type Job struct {

    Request string

    Params  []string

    Result chan Result

}

在你的工作进程中,而不是仅仅返回返回值,而是通过通道传递结果结构:


job.Result <- Result{

    Response: result.String(),

    Headers:  []string{},

}

现在,在 Web 处理程序中,只需等待通道即可:


disatcher.jobQueue <- job

result := <- job.Result

愚蠢的我。不知道为什么要花2个小时的努力。:-p 经验教训:Go 并发性非常强大。只是别想太多。


查看完整回答
反对 回复 2023-07-31
  • 1 回答
  • 0 关注
  • 104 浏览
慕课专栏
更多

添加回答

举报

0/150
提交
取消
意见反馈 帮助中心 APP下载
官方微信