【译】系统设计入门之面试题解答 —— 设计一个网页爬虫

时间  2019-11-17
标签 系统 设计 入门 面试 解答 一个 网页 爬虫 栏目 快乐工作 繁體版
原文   原文链接

设计一个网页爬虫

注意：这个文档中的连接会直接指向系统设计主题索引中的有关部分，以免重复的内容。你能够参考连接的相关内容，来了解其总的要点、方案的权衡取舍以及可选的替代方案。前端

第一步：简述用例与约束条件

把全部须要的东西汇集在一块儿，审视问题。不停的提问，以致于咱们能够明确使用场景和约束。讨论假设。react

咱们将在没有面试官明确说明问题的状况下，本身定义一些用例以及限制条件。android

用例

咱们把问题限定在仅处理如下用例的范围中

  • 服务 抓取一系列连接：
    • 生成包含搜索词的网页倒排索引
    • 生成页面的标题和摘要信息
      • 页面标题和摘要都是静态的，它们不会根据搜索词改变
  • 用户 输入搜索词后，能够看到相关的搜索结果列表，列表每一项都包含由网页爬虫生成的页面标题及摘要
    • 只给该用例绘制出概要组件和交互说明，无需讨论细节
  • 服务 具备高可用性

无需考虑

  • 搜索分析
  • 个性化搜索结果
  • 页面排名

限制条件与假设

提出假设

  • 搜索流量分布不均
    • 有些搜索词很是热门，有些则很是冷门
  • 只支持匿名用户
  • 用户很快就能看到搜索结果
  • 网页爬虫不该该陷入死循环
    • 当爬虫路径包含环的时候，将会陷入死循环
  • 抓取 10 亿个连接
    • 要按期从新抓取页面以确保新鲜度
    • 平均每周从新抓取一次，网站越热门，那么从新抓取的频率越高
      • 每个月抓取 40 亿个连接
    • 每一个页面的平均存储大小：500 KB
      • 简单起见，从新抓取的页面算做新页面
  • 每个月搜索量 1000 亿次

用更传统的系统来练习 —— 不要使用 solr 、nutch 之类的现成系统。 ios

计算用量

若是你须要进行粗略的用量计算，请向你的面试官说明。git

  • 每个月存储 2 PB 页面
    • 每个月抓取 40 亿个页面，每一个页面 500 KB
    • 三年存储 72 PB 页面
  • 每秒 1600 次写请求
  • 每秒 40000 次搜索请求

简便换算指南：程序员

  • 一个月有 250 万秒
  • 每秒 1 个请求，即每个月 250 万个请求
  • 每秒 40 个请求，即每个月 1 亿个请求
  • 每秒 400 个请求，即每个月 10 亿个请求

第二步： 概要设计

列出全部重要组件以规划概要设计。 github

Imgur
Imgur

第三步：设计核心组件

对每个核心组件进行详细深刻的分析。web

用例：爬虫服务抓取一系列网页

假设咱们有一个初始列表 links_to_crawl（待抓取连接），它最初基于网站总体的知名度来排序。固然若是这个假设不合理，咱们可使用 Yahoo、DMOZ 等知名门户网站做为种子连接来进行扩散 。 面试

咱们将用表 crawled_links （已抓取连接 ）来记录已经处理过的连接以及相应的页面签名。 redis

咱们能够将 links_to_crawl 和 crawled_links 记录在键-值型 NoSQL 数据库中。对于 crawled_links 中已排序的连接，咱们可使用 Redis 的有序集合来维护网页连接的排名。咱们应当在 选择 SQL 仍是 NoSQL 的问题上，讨论有关使用场景以及利弊 。

  • 爬虫服务按照如下流程循环处理每个页面连接：
    • 选取排名最靠前的待抓取连接
      • 在 NoSQL 数据库的 crawled_links 中，检查待抓取页面的签名是否与某个已抓取页面的签名类似
        • 若存在，则下降该页面连接的优先级
          • 这样作能够避免陷入死循环
          • 继续（进入下一次循环）
        • 若不存在，则抓取该连接
          • 在倒排索引服务任务队列中，新增一个生成倒排索引任务。
          • 在文档服务任务队列中，新增一个生成静态标题和摘要的任务。
          • 生成页面签名
          • 在 NoSQL 数据库的 links_to_crawl 中删除该连接
          • 在 NoSQL 数据库的 crawled_links 中插入该连接以及页面签名

向面试官了解你须要写多少代码。

PagesDataStore 是爬虫服务中的一个抽象类，它使用 NoSQL 数据库进行存储。

class PagesDataStore(object):

    def __init__(self, db);
        self.db = db
        ...

    def add_link_to_crawl(self, url):
        """将指定连接加入 `links_to_crawl`。"""
        ...

    def remove_link_to_crawl(self, url):
        """从 `links_to_crawl` 中删除指定连接。"""
        ...

    def reduce_priority_link_to_crawl(self, url)
        """在 `links_to_crawl` 中下降一个连接的优先级以免死循环。"""
        ...

    def extract_max_priority_page(self):
        """返回 `links_to_crawl` 中优先级最高的连接。"""
        ...

    def insert_crawled_link(self, url, signature):
        """将指定连接加入 `crawled_links`。"""
        ...

    def crawled_similar(self, signature):
        """判断待抓取页面的签名是否与某个已抓取页面的签名类似。"""
        ...复制代码

Page 是爬虫服务的一个抽象类，它封装了网页对象，由页面连接、页面内容、子连接和页面签名构成。

class Page(object):

    def __init__(self, url, contents, child_urls, signature):
        self.url = url
        self.contents = contents
        self.child_urls = child_urls
        self.signature = signature复制代码

Crawler 是爬虫服务的主类，由Page 和 PagesDataStore 组成。

class Crawler(object):

    def __init__(self, data_store, reverse_index_queue, doc_index_queue):
        self.data_store = data_store
        self.reverse_index_queue = reverse_index_queue
        self.doc_index_queue = doc_index_queue

    def create_signature(self, page):
        """基于页面连接与内容生成签名。"""
        ...

    def crawl_page(self, page):
        for url in page.child_urls:
            self.data_store.add_link_to_crawl(url)
        page.signature = self.create_signature(page)
        self.data_store.remove_link_to_crawl(page.url)
        self.data_store.insert_crawled_link(page.url, page.signature)

    def crawl(self):
        while True:
            page = self.data_store.extract_max_priority_page()
            if page is None:
                break
            if self.data_store.crawled_similar(page.signature):
                self.data_store.reduce_priority_link_to_crawl(page.url)
            else:
                self.crawl_page(page)复制代码

处理重复内容

咱们要谨防网页爬虫陷入死循环，这一般会发生在爬虫路径中存在环的状况。

向面试官了解你须要写多少代码.

删除重复连接：

  • 假设数据量较小，咱们能够用相似于 sort | unique 的方法。（译注： 先排序，后去重）
  • 假设有 10 亿条数据，咱们应该使用 MapReduce 来输出只出现 1 次的记录。
class RemoveDuplicateUrls(MRJob):

    def mapper(self, _, line):
        yield line, 1

    def reducer(self, key, values):
        total = sum(values)
        if total == 1:
            yield key, total复制代码

比起处理重复内容，检测重复内容更为复杂。咱们能够基于网页内容生成签名，而后对比二者签名的类似度。可能会用到的算法有 Jaccard index 以及 cosine similarity。

抓取结果更新策略

要按期从新抓取页面以确保新鲜度。抓取结果应该有个 timestamp 字段记录上一次页面抓取时间。每隔一段时间，好比说 1 周，全部页面都须要更新一次。对于热门网站或是内容频繁更新的网站，爬虫抓取间隔能够缩短。

尽管咱们不会深刻网页数据分析的细节，咱们仍然要作一些数据挖掘工做来肯定一个页面的平均更新时间，而且根据相关的统计数据来决定爬虫的从新抓取频率。

固然咱们也应该根据站长提供的 Robots.txt 来控制爬虫的抓取频率。

用例：用户输入搜索词后，能够看到相关的搜索结果列表，列表每一项都包含由网页爬虫生成的页面标题及摘要

  • 客户端向运行反向代理的 Web 服务器发送一个请求
  • Web 服务器 发送请求到 Query API 服务器
  • 查询 API 服务将会作这些事情：
    • 解析查询参数
      • 删除 HTML 标记
      • 将文本分割成词组 （译注： 分词处理）
      • 修正错别字
      • 规范化大小写
      • 将搜索词转换为布尔运算
    • 使用倒排索引服务来查找匹配查询的文档
      • 倒排索引服务对匹配到的结果进行排名，而后返回最符合的结果
    • 使用文档服务返回文章标题与摘要

咱们使用 REST API 与客户端通讯：

$ curl https://search.com/api/v1/search?query=hello+world复制代码

响应内容:

{
    "title": "foo's title",
    "snippet": "foo's snippet",
    "link": "https://foo.com",
},
{
    "title": "bar's title",
    "snippet": "bar's snippet",
    "link": "https://bar.com",
},
{
    "title": "baz's title",
    "snippet": "baz's snippet",
    "link": "https://baz.com",
},复制代码

对于服务器内部通讯，咱们可使用 远程过程调用协议（RPC）

第四步：架构扩展

根据限制条件，找到并解决瓶颈。

Imgur
Imgur

重要提示：不要直接从最初设计跳到最终设计！

如今你要 1) 基准测试、负载测试。2) 分析、描述性能瓶颈。3) 在解决瓶颈问题的同时，评估替代方案、权衡利弊。4) 重复以上步骤。请阅读设计一个系统，并将其扩大到为数以百万计的 AWS 用户服务 来了解如何逐步扩大初始设计。

讨论初始设计可能遇到的瓶颈及相关解决方案是很重要的。例如加上一套配备多台 Web 服务器的负载均衡器是否可以解决问题？CDN呢？主从复制呢？它们各自的替代方案和须要权衡的利弊又有哪些呢？

咱们将会介绍一些组件来完成设计，并解决架构规模扩张问题。内置的负载均衡器将不作讨论以节省篇幅。

为了不重复讨论，请参考系统设计主题索引相关部分来了解其要点、方案的权衡取舍以及替代方案。

有些搜索词很是热门，有些则很是冷门。热门的搜索词能够经过诸如 Redis 或者 Memcached 之类的内存缓存来缩短响应时间，避免倒排索引服务以及文档服务过载。内存缓存一样适用于流量分布不均匀以及流量短时高峰问题。从内存中读取 1 MB 连续数据大约须要 250 微秒，而从 SSD 读取一样大小的数据要花费 4 倍的时间，从机械硬盘读取须要花费 80 倍以上的时间。1

如下是优化爬虫服务的其余建议：

  • 为了处理数据大小问题以及网络请求负载，倒排索引服务和文档服务可能须要大量应用数据分片和数据复制。
  • DNS 查询可能会成为瓶颈，爬虫服务最好专门维护一套按期更新的 DNS 查询服务。
  • 借助于链接池，即同时维持多个开放网络链接，能够提高爬虫服务的性能并减小内存使用量。
    • 改用 UDP 协议一样能够提高性能
  • 网络爬虫受带宽影响较大，请确保带宽足够维持高吞吐量。

其它要点

是否深刻这些额外的主题，取决于你的问题范围和剩下的时间。

SQL 扩展模式

NoSQL

缓存

异步与微服务

通讯

安全性

请参阅安全。

延迟数值

请参阅每一个程序员都应该知道的延迟数。

持续探讨

  • 持续进行基准测试并监控你的系统，以解决他们提出的瓶颈问题。
  • 架构扩展是一个迭代的过程。

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、React、前端、后端、产品、设计 等领域，想要查看更多优质译文请持续关注 掘金翻译计划。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程