Question

我正在使用golang来实现一个简单的事件驱动的worker。就像这样：

  go func() {
        for {
            select {
            case data := <-ch:
                time.Sleep(1)
                someGlobalMap[data.key] = data.value 
            }
        }
    }()

主要功能将创建几个goroutine ，每个人都会做这样的事情：

ch <- data
fmt.Println(someGlobalMap[data.key])

正如你所看到的那样，因为我的工作人员需要一些时间来完成工作，所以我的主要功能无效。我如何正确控制这个工作流程？

Answer 1

编辑：我可能误解了你的问题，我看到你提到主要会启动许多制作人 goroutines。我认为这是很多消费者 goroutines和一个生产者。在这里留下答案，以防它对寻找该模式的其他人有用，尽管这些要点仍适用于您的案例。

因此，如果我正确理解您的用例，您不能指望在通道上发送并立即读取结果。您不知道工作人员何时处理该发送，您需要在goroutines之间进行通信，这需要通过通道完成。假设只是调用一个带有返回值的函数在你的场景中不起作用，如果你真的需要发送给一个worker，然后阻塞直到你得到结果，你可以发送一个通道作为数据结构的一部分，并阻止 - 发送后收到，即：

resCh := make(chan Result)
ch <- Data{key, value, resCh}
res := <- resCh

但是你应该尝试将工作分解为独立步骤的管道，请参阅我在原始答案中链接到的博客文章。

原始答案我认为这是一个单一的制作人 - 多个消费者/工人模式：

这是Go的goroutines和channel语义非常适合的常见模式。您需要记住以下几点：

主要功能不会自动等待goroutines完成。如果主要内容没有其他任何内容可做，则程序退出并且您没有结果。
您使用的全局映射不是线程安全的。您需要通过互斥锁同步访问，但有一种更好的方法 - 使用输出通道获取已经同步的结果。
您可以在频道上使用for..range，并且可以安全地在多个goroutine之间共享频道。正如我们所看到的，这使得这种模式非常优雅。

游乐场：https://play.golang.org/p/WqyZfwldqp

有关Go管道和并发模式的更多信息，请介绍错误处理，及早取消等。https://blog.golang.org/pipelines

您提到的用例的注释代码：

// could be a command-line flag, a config, etc.
const numGoros = 10

// Data is a similar data structure to the one mentioned in the question.
type Data struct {
    key   string
    value int
}

func main() {
    var wg sync.WaitGroup

    // create the input channel that sends work to the goroutines
    inch := make(chan Data)
    // create the output channel that sends results back to the main function
    outch := make(chan Data)

    // the WaitGroup keeps track of pending goroutines, you can add numGoros
    // right away if you know how many will be started, otherwise do .Add(1)
    // each time before starting a worker goroutine.
    wg.Add(numGoros)
    for i := 0; i < numGoros; i++ {
        // because it uses a closure, it could've used inch and outch automaticaly,
        // but if the func gets bigger you may want to extract it to a named function,
        // and I wanted to show the directed channel types: within that function, you
        // can only receive from inch, and only send (and close) to outch.
        //
        // It also receives the index i, just for fun so it can set the goroutines'
        // index as key in the results, to show that it was processed by different
        // goroutines. Also, big gotcha: do not capture a for-loop iteration variable
        // in a closure, pass it as argument, otherwise it very likely won't do what
        // you expect.
        go func(i int, inch <-chan Data, outch chan<- Data) {
            // make sure WaitGroup.Done is called on exit, so Wait unblocks
            // eventually.
            defer wg.Done()

            // range over a channel gets the next value to process, safe to share
            // concurrently between all goroutines. It exits the for loop once
            // the channel is closed and drained, so wg.Done will be called once
            // ch is closed.
            for data := range inch {
                // process the data...
                time.Sleep(10 * time.Millisecond)
                outch <- Data{strconv.Itoa(i), data.value}
            }
        }(i, inch, outch)
    }

    // start the goroutine that prints the results, use a separate WaitGroup to track
    // it (could also have used a "done" channel but the for-loop would be more complex, with a select).
    var wgResults sync.WaitGroup
    wgResults.Add(1)
    go func(ch <-chan Data) {
        defer wgResults.Done()

        // to prove it processed everything, keep a counter and print it on exit
        var n int
        for data := range ch {
            fmt.Println(data.key, data.value)
            n++
        }

        // for fun, try commenting out the wgResults.Wait() call at the end, the output
        // will likely miss this line.
        fmt.Println(">>> Processed: ", n)
    }(outch)

    // send work, wherever that comes from...
    for i := 0; i < 1000; i++ {
        inch <- Data{"main", i}
    }

    // when there's no more work to send, close the inch, so the goroutines will begin
    // draining it and exit once all values have been processed.
    close(inch)

    // wait for all goroutines to exit
    wg.Wait()

    // at this point, no more results will be written to outch, close it to signal
    // to the results goroutine that it can terminate.
    close(outch)

    // and wait for the results goroutine to actually exit, otherwise the program would
    // possibly terminate without printing the last few values.
    wgResults.Wait()
}

在现实生活场景中，如果事先不知道工作量，那么通道内的关闭可能来自例如：一个SIGINT信号。只需确保在关闭频道后没有代码路径可以发送工作，因为这会引起恐慌。

golang中的事件驱动模式

1 个答案: