温暖工人的Go-worker模式

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

我找到了一个worker的示例，它允许我根据最大队列和最大例程限制来加速上下文并将任务分配给它们：

然而，这种模式不允许我从上下文返回结果并反馈它。我还使用一个web服务器，因此web处理程序必须接收结果并做出相应的响应

是否有一个我应该/可以遵循的特定/更好的模式，或者有一种方法可以适应工作人员的例子

---

首先，我想我可以创建一个ResultQueue，在这里结果被推后并由web处理程序使用。不过，我不认为队列的排序是可靠的。

解决方案非常简单（我肯定把它复杂化了）。不确定这到底有多有效，但怀疑它是否太糟糕。我们仍然欢迎关于更好模式的建议：

在作业定义中，声明用于反馈结果的通道：

type Job struct {
    Request string
    Params  []string
    Result chan Result
}

在worker内部，而不仅仅是返回退出，通过通道传递result结构：

job.Result <- Result{
    Response: result.String(),
    Headers:  []string{},
}

disatcher.jobQueue <- job
result := <- job.Result

---

job.Result请共享一些实际代码。您可以使用该示例，从结果频道接收结果，并对其进行排序。@mh cbon代码在该行中。不管怎样，我都解决了这个问题。答案贴在下面。。。