Moon's blog

write the code, change the world.

一个事件驱动的图片爬虫

起因

  1. 无聊的时候会翻出去看看国外的漫画,然而一页一页加载总是会很慢,偶尔还需要多刷新几次才能显示出来,非常影响体验。于是就写了个脚本去抓某一个漫画下所有的图片,这样跑一遍脚本,就能在本地看图片了。

  2. 为了偷懒,第一个版本用的单线程模型,几百张图片串行请求,真的慢。

  3. 实际工作中一直没什么机会用到异步IO,正好拿来练练手。

分析

并发的下载图片,有多线程和事件驱动两套方案。

多线程的实现方式,例如一部漫画有300张图,我不可能开300个Thread,系统受不了。比较实际的做法是使用一个容量为N的ThreadPool,那么,同时就只能发出N个请求,然后所有线程Block等待,其实效率也不高

然而事件驱动的方式就不一样了,我可以一口气把所有请求发出去,当有请求完成时,就调用事先定义的回调Handle,实现了300张图片的并行下载。

先上图看看效果

从图中就可以看出,所有的请求都发出去之后,才陆续有响应结果乱序到达。这就是典型的异步IO的情景。

基于EventMachine的异步图片爬虫

EventMachine是ruby社区知名的事件驱动库,类似于Netty、NodeJS

通过 EM.run{}就可以开始一个事件循环

以下是关键代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
#img_info = [{file_name: '1.jpg', url:'xxx'}...]

def getImg(img_info)
EM.run{ #开启事件循环
multi = EventMachine::MultiRequest.new #request容器
@img_info_copy = img_info.dup
img_info.each do |info|
file_name = File.join(@dir, info[:file_name])
if FileTest::exist?(file_name)
@img_info_copy.delete(info)
puts "#{file_name} skip".blue
next
end
puts "#{file_name} start".green
req = EventMachine::HttpRequest.new(info[:url]).get #创建request
multi.add "#{file_name}",req
req.callback { #成功回调
File.open(file_name, 'w') { |file| file.write(req.response) }
@img_info_copy.delete(info)
puts "#{file_name} done".green
}
req.errback { #失败回调
puts "#{file_name} fail".red
}
end
multi.callback do #所有request都完成后的回调
if @img_info_copy.size == 0 #如果没有图片下载失败
EM.stop
else #递归调用,重新下载的图片
puts "Total fails: #{@img_info_copy.size}, solving...".red
getImg @img_info_copy.dup
end
end
}
end

遇到的小坑

1
EM.run {}之后,主线程就block了,所有写在它后面的代码都不执行

效果

通过这次的优化,下载一部两三百页漫画的时间从之前单线程版本的二十多分钟,变成了现在的两分钟左右!