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了，所有写在它后面的代码都不执行

效果

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

异步IO