这样的架构图是不是更准确的描述scheduler版本？

Question

1. request和work chan 都是chan，run里面的slice其实是为了方便调度器select做的“缓存”，其实维护的“队列”本意应该是维护channel，对吧？
2. engine中创建worker，给每个worker的输入链接为workchan（创建一个chan类型的engine.Request），有多少个worker就创建多少个workchan，这些workchan，当有request来的时候，就将request注入到workChan中，这也就是为什么workerChan是一个chan chan engine.Request的类型，因为他接收的类型是 chan request。
3. 当有request从worker获取的时候，scheduler将从request chan收到的request，再将request从worker chan发到worker去执行。

这样通过scheduler的调度器（goroutine）通过request和workchan，两个slices进行了异步调控。
以上是我对本章scheduler版本的spider的总结

有一个疑问：
我看到很多这样的用法

go func(){
	for{
	...
	}
}()

在goroutine里面有一个for的循环，这样的写法是一个特定的语法吗？还是这是带有channel的goroutine的常用模式？

Answer 1

ccmouse 2020-10-10 19:19:27

这个总结的图画的太好了！你下面的这些理解都是正确的。对，本意其实是不想在select处阻塞，所以一旦select触发尽快把收到的值处理掉。然而我又不能发给其他channel，这样会引起select处阻塞，因此放入队列是一个自然的选择。

goroutine里面一个无条件for循环，的确是常用的写法。for后面什么都不跟，是go的语法，代表无限循环。一般来说，goroutine会不断从channel读数据，就造成了这样的for循环。因为channel读数据是阻塞的，所以没有数据的话，就不会占用资源。