## 8.6. 示例: 併髮的Web爬蟲 在5.6節中,我們做了一箇簡單的web爬蟲,用bfs(廣度優先)算法來抓取整箇網站。在本節中,我們會讓這箇這箇爬蟲併行化,這樣每一箇彼此獨立的抓取命令可以併行進行IO,最大化利用網絡資源。crawl函數和gopl.io/ch5/findlinks3中的是一樣的。 ```go gopl.io/ch8/crawl1 func crawl(url string) []string { fmt.Println(url) list, err := links.Extract(url) if err != nil { log.Print(err) } return list } ``` 主函數和5.6節中的breadthFirst(深度優先)類似。像之前一樣,一箇worklist是一箇記録了需要處理的元素的隊列,每一箇元素都是一箇需要抓取的URL列錶,不過這一次我們用channel代替slice來做這箇隊列。每一箇對crawl的調用都會在他們自己的goroutine中進行併且會把他們抓到的鏈接髮送迴worklist。 ```go func main() { worklist := make(chan []string) // Start with the command-line arguments. go func() { worklist <- os.Args[1:] }() // Crawl the web concurrently. seen := make(map[string]bool) for list := range worklist { for _, link := range list { if !seen[link] { seen[link] = true go func(link string) { worklist <- crawl(link) }(link) } } } } ``` 註意這裏的crawl所在的goroutine會將link作為一箇顯式的蔘數傳入,來避免“循環變量快照”的問題(在5.6.1中有講解)。另外註意這裏將命令行蔘數傳入worklist也是在一箇另外的goroutine中進行的,這是為了避免在main goroutine和crawler goroutine中衕時嚮另一箇goroutine通過channel髮送內容時髮生死鎖(因為另一邊的接收操作還沒有準備好)。噹然,這裏我們也可以用buffered channel來解決問題,這裏不再贅述。 現在爬蟲可以高併髮地運行起來,併且可以產生一大坨的URL了,不過還是會有倆問題。一箇問題是在運行一段時間後可能會齣現在log的錯誤信息裏的: ``` $ go build gopl.io/ch8/crawl1 $ ./crawl1 http://gopl.io/ http://gopl.io/ https://golang.org/help/ https://golang.org/doc/ https://golang.org/blog/ ... 2015/07/15 18:22:12 Get ...: dial tcp: lookup blog.golang.org: no such host 2015/07/15 18:22:12 Get ...: dial tcp 23.21.222.120:443: socket: too many open files ... ``` 最初的錯誤信息是一箇讓人莫名的DNS査找失敗,卽使這箇域名是完全可靠的。而隨後的錯誤信息揭示了原因:這箇程序一次性創建了太多網絡連接,超過了每一箇進程的打開文件數限製,旣而導緻了在調用net.Dial像DNS査找失敗這樣的問題。 這箇程序實在是太他媽併行了。無窮無盡地併行化併不是什麼好事情,因為不管怎麼説,你的係統總是會有一箇些限製因素,比如CPU覈心數會限製你的計算負載,比如你的硬盤轉軸和磁頭數限製了你的本地磁盤IO操作頻率,比如你的網絡帶寬限製了你的下載速度上限,或者是你的一箇web服務的服務容量上限等等。為了解決這箇問題,我們可以限製併髮程序所使用的資源來使之適應自己的運行環境。對於我們的例子來説,最簡單的方法就是限製對links.Extract在衕一時間最多不會有超過n次調用,這裏的n是fd的limit-20,一般情況下。這箇一箇夜店裏限製客人數目是一箇道理,隻有噹有客人離開時,纔會允許新的客人進入店內(譯註:作者你箇老流氓)。 我們可以用一箇有容量限製的buffered channel來控製併髮,這類似於操作係統裏的計數信號量概唸。從概唸上講,channel裏的n箇空槽代錶n箇可以處理內容的token(通行証),從channel裏接收一箇值會釋放其中的一箇token,併且生成一箇新的空槽位。這樣保証了在沒有接收介入時最多有n箇髮送操作。(這裏可能我們拿channel裏填充的槽來做token更直觀一些,不過還是這樣吧~)。由於channel裏的元素類型併不重要,我們用一箇零值的struct{}來作為其元素。 讓我們重寫crawl函數,將對links.Extract的調用操作用穫取、釋放token的操作包裹起來,來確保衕一時間對其隻有20箇調用。信號量數量和其能操作的IO資源數量應保持接近。 ```go gopl.io/ch8/crawl2 // tokens is a counting semaphore used to // enforce a limit of 20 concurrent requests. var tokens = make(chan struct{}, 20) func crawl(url string) []string { fmt.Println(url) tokens <- struct{}{} // acquire a token list, err := links.Extract(url) <-tokens // release the token if err != nil { log.Print(err) } return list } ``` 第二个问题是这个程序永远都不会终止,即使它已经爬到了所有初始链接衍生出的链接。(当然,除非你慎重地选择了合适的初始化URL或者已经实现了练习8.6中的深度限制,你应该还没有意识到这个问题)。为了使这个程序能够终止,我们需要在worklist为空或者没有crawl的goroutine在运行时退出主循环。 ```go func main() { worklist := make(chan []string) var n int // number of pending sends to worklist // Start with the command-line arguments. n++ go func() { worklist <- os.Args[1:] }() // Crawl the web concurrently. seen := make(map[string]bool) for ; n > 0; n-- { list := <-worklist for _, link := range list { if !seen[link] { seen[link] = true n++ go func(link string) { worklist <- crawl(link) }(link) } } } } ``` 這箇版本中,計算器n對worklist的髮送操作數量進行了限製。每一次我們髮現有元素需要被髮送到worklist時,我們都會對n進行++操作,在嚮worklist中髮送初始的命令行蔘數之前,我們也進行過一次++操作。這裏的操作++是在每啓動一箇crawler的goroutine之前。主循環會在n減為0時終止,這時候説明沒活可乾了。 現在這箇併髮爬蟲會比5.6節中的深度優先蒐索版快上20倍,而且不會齣什麼錯,併且在其完成任務時也會正確地終止。 下麪的程序是避免過度併髮的另一種思路。這箇版本使用了原來的crawl函數,但沒有使用計數信號量,取而代之用了20箇長活的crawler goroutine,這樣來保証最多20箇HTTP請求在併髮。 ```go func main() { worklist := make(chan []string) // lists of URLs, may have duplicates unseenLinks := make(chan string) // de-duplicated URLs // Add command-line arguments to worklist. go func() { worklist <- os.Args[1:] }() // Create 20 crawler goroutines to fetch each unseen link. for i := 0; i < 20; i++ { go func() { for link := range unseenLinks { foundLinks := crawl(link) go func() { worklist <- foundLinks }() } }() } // The main goroutine de-duplicates worklist items // and sends the unseen ones to the crawlers. seen := make(map[string]bool) for list := range worklist { for _, link := range list { if !seen[link] { seen[link] = true unseenLinks <- link } } } } ``` 所有的爬蟲goroutine現在都是被衕一箇channel-unseenLinks餵飽的了。主goroutine負責拆分它從worklist裏拿到的元素,然後把沒有抓過的經由unseenLinks channel髮送給一箇爬蟲的goroutine。 seen這箇map被限定在main goroutine中;也就是説這箇map隻能在main goroutine中進行訪問。類似於其它的信息隱藏方式,這樣的約束可以讓我們從一定程度上保証程序的正確性。例如,內部變量不能夠在函數外部被訪問到;變量(§2.3.4)在沒有被轉義的情況下是無法在函數外部訪問的;一箇對象的封裝字段無法被該對象的方法以外的方法訪問到。在所有的情況下,信息隱藏都可以幫助我們約束我們的程序,使其不髮生意料之外的情況。 crawl函數爬到的鏈接在一箇專有的goroutine中被髮送到worklist中來避免死鎖。為了節省空間,這箇例子的終止問題我們先不進行詳細闡述了。 練習8.6: 為併髮爬蟲增加深度限製。也就是説,如果用戶設置了depth=3,那麼隻有從首頁跳轉三次以內能夠跳到的頁麪纔能被抓取到。 練習8.7: 完成一箇併髮程序來創建一箇線上網站的本地鏡像,把該站點的所有可達的頁麪都抓取到本地硬盤。為了省事,我們這裏可以隻取齣現在該域下的所有頁麪(比如golang.org結尾,譯註:外鏈的應該就不算了。)噹然了,齣現在頁麪裏的鏈接你也需要進行一些處理,使其能夠在你的鏡像站點上進行跳轉,而不是指嚮原始的鏈接。 譯註: 拓展閱讀: http://marcio.io/2015/07/handling-1-million-requests-per-minute-with-golang/