前言

以下内容是看500 lines or less中 A Web Crawler With asyncio Coroutines这个章节后做的一些记录。

一个最简单的爬虫

一个非常简单的get请求，爬取获取xkcd.com，

import socket


def crawl():
    sock = socket.socket()
    sock.connect(('xkcd.com', 80))
    request = 'GET / HTTP/1.0\r\nHost: xkcd.com\r\n\r\n'
    sock.send(request.encode('ascii'))
    response = b''
    chunk = sock.recv(4096)
    while chunk:
        response += chunk
        chunk = sock.recv(4096)

    print(response)

一个很简单的小的获取页面的方法，甚至说不上是爬虫。在单线程的情况下，这个方法一次只能爬取一个页面，因为socket的connect 和recv两个方法都是阻塞的。一般再配合上多线程使用，多线程再配合上线程池，爬取速度也不慢。

但是，这就满足了吗？线程这玩意还是蛮昂贵的，多线程搞爬虫总不算那么回事。

异步爬虫

简单的Event loop

import socket

sock = socket.socket()
sock.setblocking(False)
try:
    sock.connect(('xkcd.com', 80))
except BlockingIOError:  # nonblocking的情况下，会抛出这个异常，无视掉就好
    pass
request = 'GET / HTTP/1.0\r\nHost: xkcd.com\r\n\r\n'
encoded = request.encode('ascii')
while True:
    try:
        # 尝试去发送，如果连接还没连接就会抛错，直到连接成功并发送成功，再break出去
        sock.send(encoded)
        break  # Done.
    except OSError as e:
        pass

这边我们使用了非阻塞的socket。在C里边，socket会使用errno和EINPROGRESS来判断连接是否完成，但是python呢，我们只能用while True去一遍遍的查看，直到发送成功了再退出。

上边的方法完全就是扯淡，因为需要不停的遍历，跟最开始阻塞的没啥区别。因此我们引入了Python3.4的DefaultSelector。它提供了select相关的api，可以注册相应的IO事件，在事件完成之后回调。

import socket
from selectors import DefaultSelector, EVENT_WRITE

selector = DefaultSelector()

sock = socket.socket()
sock.setblocking(False)
try:
    sock.connect(('xkcd.com', 80))
except BlockingIOError:  # nonblocking的情况下，会抛出这个异常，无视掉就好
    pass


def connected():
    selector.unregister(sock.fileno())
    print("connected")


selector.register(sock.fileno(), EVENT_WRITE, connected)

上边例子就是注册了EVENT_WRITE事件，selector.register方法告诉selector我们在等待EVENT_WRITE的状态。并把connected方法作为data传了进去。

为了在socket达到预定的状态时，回调connected方法，我们需要一个循环来获取。

def loop():
    while True:
        events = selector.select()
        for event_key, event_mask in events:
            callback = event_key.data
            callback()

可以理解为，在socket变为可写状态后，会自动加到一个队列里边去，而我们需要做的，就是不断从队列里边读取出来，并做相应的处理。

至此，我们完成了一个简单的事件循环。可以想象，如要要爬取多个页面，只需要不停的注册到selector里边，再配合loop方法，可以高效率的处理网络请求。

配以回调的异步爬虫

首先，我们需要两个set，分别保存需要爬取的url以及一个已经见过的url（用来去重）

urls_todo = set(["/"])
seen_urls = set(["/"])

在爬取的过程中，会涉及到很多回调。在连接完成时，我们要回调connected方法，然后发送一个GET请求过去。然后开始等待响应，同样的，这里也需要注册一个回调。为了更方便的管理回调，我们设计一个Fetcher类。

class Fetcher:
    def __init__(self, url):
        self.response = b''  # Empty array of bytes.
        self.url = url
        self.sock = None

这个类传入一个url，并调用fetch方法启动，完成后，响应会写在response中。

   # Method on Fetcher class.
    def fetch(self):
        self.sock = socket.socket()
        self.sock.setblocking(False)
        try:
            self.sock.connect(('xkcd.com', 80))
        except BlockingIOError:
            pass

        # Register next callback.
        selector.register(self.sock.fileno(),
                          EVENT_WRITE,
                          self.connected)

首先，建立一个非阻塞的socket，注册下connected方法。然后，会有一个event loop去处理并回调。

fetcher = Fetcher('/1/')
fetcher.fetch()

while True:
    events = selector.select()
    for event_key, event_mask in events:
        callback = event_key.data
        callback(event_key, event_mask)

如上，在连接建立后，便能从selector.select()中获取到已经连接的socket，获取其回调，并执行。

    # Method on Fetcher class.
    def connected(self, key, mask):
        print('connected!')
        selector.unregister(key.fd)
        request = 'GET {} HTTP/1.0\r\nHost: xkcd.com\r\n\r\n'.format(self.url)
        self.sock.send(request.encode('ascii'))

        # Register the next callback.
        selector.register(key.fd,
                          EVENT_READ,
                          self.read_response)

一般我们在send之前要先检查请求体的大小，看看是否可以一次性发送。但我们这发送的内容确实少，就免了这步了。在最后，注册EVENT_READ，event loop会在socket可读或者已经关闭的时候调用read_response方法。

    # Method on Fetcher class.
    def read_response(self, key, mask):
        global stopped

        chunk = self.sock.recv(4096)  # 4k chunk size.
        if chunk:
            self.response += chunk
        else:
            selector.unregister(key.fd)  # Done reading.
            links = self.parse_links()

            # Python set-logic:
            for link in links.difference(seen_urls):
                urls_todo.add(link)
                Fetcher(link).fetch()  # <- New Fetcher.

            seen_urls.update(links)
            urls_todo.remove(self.url)
            if not urls_todo:
                stopped = True

这里我们做了两件事，如果socket中还有没读取完的数据，就读出来加到response中，然后控制权交回给event loop，当然，这种情况下socket依旧是可读状态，会再次调用该回调方法。另外，如果对方已经发送完毕，socket被关闭了，且socket.recv方法已经读不出新的数据了（已经读取完毕），我们便可以对已经保存下来的response做一些处理了。这边做的就是简单的去了个重，然后挨个建立新的fetcher并开始抓取。

另外，我们加了个全局变量stopped来控制event loop。

stopped = False

def loop():
    while not stopped:
        events = selector.select()
        for event_key, event_mask in events:
            callback = event_key.data
            callback()

整个程序会在所有页面爬取完成后结束。

简单的回调异步爬虫到这似乎告一段落了，但是似乎还有哪里不太好。基于回调的方式一直是比较反人类，不友好的。设想一下，如果我们的异步爬虫在parse部分报了错

Traceback (most recent call last):
  File "loop-with-callbacks.py", line 111, in <module>
    loop()
  File "loop-with-callbacks.py", line 106, in loop
    callback(event_key, event_mask)
  File "loop-with-callbacks.py", line 51, in read_response
    links = self.parse_links()
  File "loop-with-callbacks.py", line 67, in parse_links
    raise Exception('parse error')
Exception: parse error

光看这个error trace，谁能直接看出来是哪个页面出了错呢？基于回调的方式实现的异步爬虫有一个致命的缺点，那就是非常难debug，非常难以理解。

Coroutines

Python 3.4引入了一个叫asyncio，以及一个aiohttp的包，我们可以很简洁的重构之前的代码。

    @asyncio.coroutine
    def fetch(self, url):
        response = yield from self.session.get(url)
        body = yield from response.read()

coroutine是这么一个概念，它就是一个子程序，在执行的过程中，可以在子程序内部终端，然后转而去执行别的子程序，在适当的时候再接回来执行。python中有很多可以做协程的包。在Python3.4的时候引入了一个基于generators、Future以及yield from语法实现的标准协程库，叫asyncio，

为了更好的理解，接下来将会手把手用generator实现一个协程。

python generators是如何工作的

在讨论生成器之前，先看下一般的python方法是如何工作的。

>>> def foo():
...     bar()
...
>>> def bar():
...     pass

一般的，python解释器（一个C的程序）会调用PyEval_EvalFrameEx去逐帧执行。

>>> import dis
>>> dis.dis(foo)
  2           0 LOAD_GLOBAL              0 (bar)
              3 CALL_FUNCTION            0 (0 positional, 0 keyword pair)
              6 POP_TOP
              7 LOAD_CONST               0 (None)
             10 RETURN_VALUE

这是foo方法的字节码，foo把bar方法加载到栈中，并调用，而后pop出值，加载None到栈中，最后返回None。

当PyEval_EvalFrameEx遇到CALL_FUNCTION时，他会创建一个新的Python stack frame，然后PyEval_EvalFrameEx递归的去调用新的frame。

这边有个很有意思的点，python帧栈是分配在堆内存中的，这个帧栈也是指一个很普通的栈结构，这意味着我们可以在方法之外去操作这个栈，在方法之外，我们也可以很方便的去操作其中的某一帧。

>>> import inspect
>>> frame = None
>>> def foo():
...     bar()
...
>>> def bar():
...     global frame
...     frame = inspect.currentframe()
...
>>> foo()
>>> # The frame was executing the code for 'bar'.
>>> frame.f_code.co_name
'bar'
>>> # Its back pointer refers to the frame for 'foo'.
>>> caller_frame = frame.f_back
>>> caller_frame.f_code.co_name
'foo'

接下来我们来看生成器方法。

>>> def gen_fn():
...     result = yield 1
...     print('result of yield: {}'.format(result))
...     result2 = yield 2
...     print('result of 2nd yield: {}'.format(result2))
...     return 'done'
...     

当解释器看到yield时，它会知道gen_fn方法是一个生成器方法，然后会给他打一个标记

>>> # The generator flag is bit position 5.
>>> generator_bit = 1 << 5
>>> bool(gen_fn.__code__.co_flags & generator_bit)
True

然后，在调用生成器方法时，解释器通过这个标记发现这不是一个普通的方法，于是乎，创建了一个生成器。

>>> gen = gen_fn()
>>> type(gen)
<class 'generator'>

每个生成器对象都指向同样额代码，但是分别拥有自己的帧。这个帧并不在任何真正的栈上，二十在堆内存中等待被使用。

这个帧有个“最后个指令”的指针，指向他最近一次执行的命令。最一开始，这个指针的值是-1，意味着生成器没有开始。

>>> gen.gi_frame.f_lasti
-1

当我们调用了send后，生成器首次执行到yield，然后暂停，返回一个

>>> gen.send(None)
1

现在生成器对象的指令指针的位置离已开有隔了3字节，完成了编译好的56字节python代码的一部分。

>>> gen.gi_frame.f_lasti
3
>>> len(gen.gi_code.co_code)
56

生成器能在任何时候被唤醒，因为它的帧并不在栈中，而是在堆上。它在调用层级中的位置并不固定，不需要执行先入后出的顺序。

接着我们发送一个hello过去，hello就成了yield表达式的值。

>>> gen.send('hello')
result of yield: hello
2

这时候，在这个帧中包含了本地变量result

>>> gen.gi_frame.f_locals
{'result': 'hello'}

其他由gen_fn产生的生成器也拥有自己的栈帧以及自己的本地变量。

当再一次调用send方法，生成器到达第二个yield，并抛出StopIteration

>>> gen.send('goodbye')
result of 2nd yield: goodbye
Traceback (most recent call last):
  File "<input>", line 1, in <module>
StopIteration: done

基于生成器的协程

如我们上边说的，一个生成器可以暂停，然后在任何我们想要的地方继续执行，并接受一个值，返回一个值，用来做协程再好不过。

接下来，我们要建立一个简易版的“asyncio”。

首先需要一个future对象，我们希望的future是这么一个存在：一个生成器在暂停的时候yield一个future，然后在future获取到值（set_result）的时候继续这个生成器。

class Future:
    def __init__(self):
        self.result = None
        self._callbacks = []

    def add_done_callback(self, fn):
        self._callbacks.append(fn)

    def set_result(self, result):
        self.result = result
        for fn in self._callbacks:
            fn(self)

future初始化时会是一个"pending"状态，在调用了set_result方法后继续执行生成器。

接下来我们要用future来改造fetch方法。原本的方法如下：

class Fetcher:
    def fetch(self):
        self.sock = socket.socket()
        self.sock.setblocking(False)
        try:
            self.sock.connect(('xkcd.com', 80))
        except BlockingIOError:
            pass
        selector.register(self.sock.fileno(),
                          EVENT_WRITE,
                          self.connected)

    def connected(self, key, mask):
        print('connected!')
        # And so on....

原本的方法会先创建连接，注册一个connected的回调，然后会在连接创建后回调。我们用future和生成器对其改造。

    def fetch(self):
        sock = socket.socket()
        sock.setblocking(False)
        try:
            sock.connect(('xkcd.com', 80))
        except BlockingIOError:
            pass

        f = Future()

        def on_connected():
            f.set_result(None)

        selector.register(sock.fileno(),
                          EVENT_WRITE,
                          on_connected)
        yield f
        selector.unregister(sock.fileno())
        print('connected!')

因为包含了yield，该fetch方法是一个生成器。另外我们创建了一个future，并把它yield出来。我们希望这个生成器暂停，一直到连接创建成功后再继续，那么谁来做继续生成器的操作呢？我们引入了Task对象。

class Task:
    def __init__(self, coro):
        self.coro = coro
        f = Future()
        f.set_result(None)
        self.step(f)

    def step(self, future):
        try:
            next_future = self.coro.send(future.result)
        except StopIteration:
            return

        next_future.add_done_callback(self.step)

# Begin fetching http://xkcd.com/353/
fetcher = Fetcher('/353/')
Task(fetcher.fetch())

loop()

在给fetch生成的生成器发送None后，fetch生成器启动，然后yield一个future，也就是Task中的next_future。当socket连接创建成功后，事件循环会调用on_connected方法，然后触发future中的回调，也就是step方法，从而继续fetch生成器。

用yield from来重构协程

在socket连接王城后，我们可以继续发送get请求以及获取响应，这些都可以在同一个生成器方法中实现。

    def fetch(self):
        # ... connection logic from above, then:
        sock.send(request.encode('ascii'))

        while True:
            f = Future()

            def on_readable():
                f.set_result(sock.recv(4096))

            selector.register(sock.fileno(),
                              EVENT_READ,
                              on_readable)
            chunk = yield f
            selector.unregister(sock.fileno())
            if chunk:
                self.response += chunk
            else:
                # Done reading.
                break

这个方法显得很长，因为我们把发的过程，分段收的过程都放在同一个方法中了，显得很乱，用yield from语法可以让方法看上去美观很多。

这边我们廷议两个常用的方法，一个是read方法，可以获取一定大小的数据，另一个是read_all方法，可以获取全部数据。

def read(sock):
    f = Future()

    def on_readable():
        f.set_result(sock.recv(4096))

    selector.register(sock.fileno(), EVENT_READ, on_readable)
    chunk = yield f  # Read one chunk.
    selector.unregister(sock.fileno())
    return chunk
    

def read_all(sock):
    response = []
    # Read whole response.
    chunk = yield from read(sock)
    while chunk:
        response.append(chunk)
        chunk = yield from read(sock)

    return b''.join(response)

以及使用这两个方法重构fetch

class Fetcher:
    def fetch(self):
         # ... connection logic from above, then:
        sock.send(request.encode('ascii'))
        self.response = yield from read_all(sock)

总结一下，我们上边实现了最最最简单版本的future和task，并且也知道了为什么asyncio在并发I/O上会比多线程版本有更好的性能，以及比回调版本更加清晰易懂。当然，这只是最简单的基础版，真正标准库中的asyncio实现了更多的东西，也更容易去写。

对于一个熟悉asyncio的人来说，实现上边的功能会更加简单。

    @asyncio.coroutine
    def fetch(self, url):
        response = yield from self.session.get(url)
        body = yield from response.read()

接下来，真正回到主题，实现一个异步的爬虫。

爬虫

接下来我们要用asyncio来实现一个异步的爬虫。

首先描述下这个爬虫会做哪些事。首先爬虫爬取第一个页面，并解析其中的链接，加入到队列中，再继续爬取队列中的链接。另外还需要考虑以下几点：限制并发数量，让服务器和客户端压力不至于太大；在爬取完一个页面后，立马从队列中获取下个要爬去的页面；但队列中剩余url数量小于并发数量时，一部分worker需要先暂停，等到有足够数量url后继续；在全部爬取完成后退出。

想象下，如果是一个多线程爬虫，我们会如何去做？可能我们会使用一个标准库的队列，然后把url都丢到队列中去，然后记录下任务的数量；当线程完成爬取后，调用task_done方法。主线程使用Queue.join()方法阻塞，直到所有的worker都结束。

协程爬虫也是类似的，使用的是asyncio中的queue

try:
    from asyncio import JoinableQueue as Queue
except ImportError:
    # In Python 3.5, asyncio.JoinableQueue is
    # merged into Queue.
    from asyncio import Queue

另外，我们会有一个crawler的类，并有crawl方法，然后在事件驱动中启动crawl

loop = asyncio.get_event_loop()

crawler = crawling.Crawler('http://xkcd.com',
                           max_redirect=10)

loop.run_until_complete(crawler.crawl())

爬虫最开始输入起始url和最大重定向数，以元祖的方式存在，并放到队列中

class Crawler:
    def __init__(self, root_url, max_redirect):
        self.max_tasks = 10
        self.max_redirect = max_redirect
        self.q = Queue()
        self.seen_urls = set()

        # aiohttp's ClientSession does connection pooling and
        # HTTP keep-alives for us.
        self.session = aiohttp.ClientSession(loop=loop)

        # Put (URL, max_redirect) in the queue.
        self.q.put((root_url, self.max_redirect))

现在在队列中未完成的任务数只有一个，我们用事件驱动方式启动

loop.run_until_complete(crawler.crawl())

crawl方法会启动workers，类似与多线程中的主线程，会用join方法阻塞，直到所有任务完成。

    @asyncio.coroutine
    def crawl(self):
        """Run the crawler until all work is done."""
        workers = [asyncio.Task(self.work())
                   for _ in range(self.max_tasks)]

        # When all work is done, exit.
        yield from self.q.join()
        for w in workers:
            w.cancel()

worker会从队列中获取url，爬取，解析。每个worker都会运行worker方法。

    @asyncio.coroutine
    def work(self):
        while True:
            url, max_redirect = yield from self.q.get()

            # Download page and add new links to self.q.
            yield from self.fetch(url, max_redirect)
            self.q.task_done()

python看到work方法包含yield from，会返回一个生成器。所以在crawl方法中，调用self.work方法诗词，并没有真正执行方法，而是创建了十个生成器。并且每个生成器都包装为一个Task。一个Task会获取生成器yield出的future，并用send的方式驱动生成器，以及触发future（和我们之前的future类似）。

worker用以下方式去从队列中获取url

    url, max_redirect = yield from self.q.get()

queue的get方法本身也是一个协程：如果队列为空会暂停，直到有新的任务进入队列。

每当一个任务完成，都会调用task_done方法，该方法会把queue内部的未完成任务数减一。当所有的页面都爬取完毕，队列中任务为零，join方法继续执行，crawl方法也会继续，然后关闭所有的worker。

接下来说说重定向。重定向可能导致A页面指向B，又重定向到C的情况，形成一条链 A—>B —>C，而这个B或者C可能使我们曾经访问过的。aiohttp会自动重定向，这样我们可能爬到重复的页面。因此，我们需要禁止自动重定向，并手动重定向并去重。

  @asyncio.coroutine
    def fetch(self, url, max_redirect):
        # Handle redirects ourselves.
        response = yield from self.session.get(
            url, allow_redirects=False)

        try:
            if is_redirect(response):
                if max_redirect > 0:
                    next_url = response.headers['location']
                    if next_url in self.seen_urls:
                        # We have been down this path before.
                        return

                    # Remember we have seen this URL.
                    self.seen_urls.add(next_url)

                    # Follow the redirect. One less redirect remains.
                    self.q.put_nowait((next_url, max_redirect - 1))
             else:
                 links = yield from self.parse_links(response)
                 # Python set-logic:
                 for link in links.difference(self.seen_urls):
                    self.q.put_nowait((link, self.max_redirect))
                self.seen_urls.update(links)
        finally:
            # Return connection to pool.
            yield from response.release()

如果是多线程版本，上述代码会变得异常复杂，需要考虑线程安全的问题：A线程判断url没爬过，不在seen_urls中，正准备把url插入seen_urls中，B线程也刚好爬到了相同链接，同样判断url没爬过，也加入到seen_urls中，导致一个url出现了两次，解决这个问题可能需要引入锁之类的，而协程代码就简单许多，无需考虑线程安全的问题。

当fetch方法发现了新的链接，加入到seen_urls中，并加入到queue中，queue会把其内部维护的未完成任务数加一，然后继续执行主协程，join方法也会因为还有任务没完成会继续阻塞。如果没有新的链接，且queue也已经为空，最后一次调用task_done后，队列内部维护的计数器变为零，join方法不再阻塞。

class Queue:
    def __init__(self):
        self._join_future = Future()
        self._unfinished_tasks = 0
        # ... other initialization ...

    def put_nowait(self, item):
        self._unfinished_tasks += 1
        # ... store the item ...

    def task_done(self):
        self._unfinished_tasks -= 1
        if self._unfinished_tasks == 0:
            self._join_future.set_result(None)

    @asyncio.coroutine
    def join(self):
        if self._unfinished_tasks > 0:
            yield from self._join_future

之前被join阻塞的主协程继续执行，并最终结束。

整个协程起始于crawl

loop.run_until_complete(self.crawler.crawl())

crawl是个生成器，为了驱动这个生成器，asyncio用task来包装了一下

class EventLoop:
    def run_until_complete(self, coro):
        """Run until the coroutine is done."""
        task = Task(coro)
        task.add_done_callback(stop_callback)
        try:
            self.run_forever()
        except StopError:
            pass

class StopError(BaseException):
    """Raised to stop the event loop."""

def stop_callback(future):
    raise StopError

当一个task完成，会抛出StopError，作为event loop的一个退出信号。

那么，具体什么是task呢？看add_done_callback方法有点像我们之前说的future。确实，它就是future的子类。

class Task(Future):
    """A coroutine wrapped in a Future."""

一般情况下，future会在被调用set_result的时候被激活，而task会在协程退出的时候激活。

    # Method of class Task.
    def step(self, future):
        try:
            next_future = self.coro.send(future.result)
        except CancelledError:
            self.cancelled = True
            return
        except StopIteration as exc:

            # Task resolves itself with coro's return
            # value.
            self.set_result(exc.value)
            return

        next_future.add_done_callback(self.step)

task.add_done_callback(stop_callback)就意味着将会在task完成的时候调用stop_callback，抛出StopError，致使整个循环结束。

结论

其实讲了那么多，感觉跟爬虫确实没什么关系，大多是跟作者走了一遍asyncio协程的一些思想。仔细读了好几遍，结果写下来还是不伦不类的，既不像翻译也不像是总结，自己水平还是次了点。