一个事件驱动的图片爬虫

起因

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

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

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

分析

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

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

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

先上图看看效果

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

基于EventMachine的异步图片爬虫

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

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

以下是关键代码

  #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

遇到的小坑

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

效果

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