常规的更新文章或者更新主题之类的方法就不写了。由于是托管在 GitHub 上的 hexo 博客，不像是一般部署在一台固定机器上的 WordPress 那样从哪里都可以 ssh 上去管理。因此有必要记录一下摸索出来的过程。

方法

主要是因为 hexo 实现 github blog 是通过 source/ 下一系列的 markdown 文件用于记录文章内容，再通过 hexo g 命令生成美观的静态页面在浏览器中显示，两者是缺一不可的：如果只有 markdown 文件，也不是不能读，但这样和读 README.md 没什么区别了，起不到博客的作用；如果只有静态页面文件，倒是像个博客了，但是如果要更新，改一次就累死人了。按照我的理解，前者相当于源码，后者相当于由源码编译出来的二进制文件，因此要两手抓，两手都要硬，通过两个分支来对整个 hexo github blog 进行管理就可以了。

在写完 markdown 文件之后，执行一下 hexo clean，把已经生成的静态页面文件都清理掉（据我理解实际上是把 public/ 删掉了，但不确定除此以外还有没有清理其它内容）。这个时候目录下的内容基本都是“源码”了，将这个状态下的整个目录 git push 到项目的某个次要分支。之后都是通过这个次要分支来维护每次更新，只要在 git clone 下来之后 git checkout 到这个分支就可以了。

维护完次要分支之后，就可以使用 hexo g 来生成静态页面文件了，这个过程视机器性能而定，快则几秒钟，慢则几分钟，在我的 VPS 上甚至有可能被 kill……在生成完静态页面文件之后，就可以直接部署到 GitHub 上了。前提是要有 hexo-deployer-git 这一个插件并且在配置文件里已经配置好 GitHub 的用户名和分支（这里需要用 master 分支），执行 hexo d 就可以直接部署上去了。这个过程的实质是把 public/ 里面的内容 push 到 master 分支了。

这样，静态页面文件通过 master 分支维护，访问者访问 foo.github.io 时访问的也是 master 分支的静态页面文件，而 markdown 文件则隐藏在次要分支的 source/ 中。

坑

• 主题目录文件丢失：如果是使用 next 之类的从 GitHub 上 clone 下来的主题，那么主题目录下就会有 .git 目录，而整个项目根目录也有一个 .git 目录，这就会导致在 push 到 GitHub 的时候会忽略掉整个主题目录的文件，下一次 clone 下来的时候主题目录就是空的了。解决方法：移除主题目录中的 .git* 目录/文件，避免出现嵌套 git 的情况。

• hexo d 将整个项目根目录 push 到 master 分支：这种情况一般是在不同的位置（包括不同机器，或者同一台机器的不同目录）clone 项目导致的。在项目根目录下会有 .deploy_git/，这个目录下的内容和 public/ 一样，在这种情况下会产生混乱。解决方法：在 hexo clean 之前把 .deploy_git/ 目录删除，余下步骤照常执行。

• 更新内容后成功部署，但刷新页面不更新：由于是静态页面，因此浏览器会使用缓存。解决方法：ctrl + F5 刷新即可。

假如说，如果你的老板给你的任务是一次又一次地访问竞争对手的网站，把对方商品的价格记录下来，而且要纯手工操作，恐怕你会想要把整个办公室都烧掉。

之所以现在网络爬虫的影响力如此巨大，就是因为网络爬虫可以被用于追踪客户的情绪和趋向、搜寻空缺的职位、监控房地产的交易，甚至是获取 UFC 的比赛结果。除此以外，还有很多意想不到的用途。

对于有这方面爱好的人来说，爬虫无疑是一个很好的工具。因此，我使用了 Scrapy 这个基于 Python 编写的开源网络爬虫框架。

鉴于我不太了解这个工具是否会对我的计算机造成伤害，我并没有将它搭建在我的主力机器上，而是搭建在了一台树莓派上面。

令人感到意外的是，Scrapy 在树莓派上面的性能并不差，或许这是 ARM 架构服务器的又一个成功例子？

我尝试 Google 了一下，但并没有得到令我满意的结果，仅仅找到了一篇相关的《Drupal 建站对比》。这篇文章的结论是，ARM 架构服务器性能比昂贵的 x86 架构服务器要更好。

从另一个角度来看，这种 web 服务可以看作是一个“被爬虫”服务，但和 Scrapy 对比起来，前者是基于 LAMP 技术栈，而后者则依赖于 Python，这就导致两者之间没有太多的可比性。

那我们该怎样做呢？只能在一些 VPS 上搭建服务来对比一下了。

什么是 ARM 架构处理器？

ARM 是目前世界上最流行的 CPU 架构。

但 ARM 架构处理器在很多人眼中的地位只是作为一个省钱又省电的选择，而不是跑在生产环境中的处理器的首选。

然而，诞生于英国剑桥的 ARM CPU，最初是用于极其昂贵的 Acorn Archimedes 计算机上的，这是当时世界上最强大的桌面计算机，甚至在很长一段时间内，它的运算速度甚至比最快的 386 还要快好几倍。

Acorn 公司和 Commodore、Atari 的理念类似，他们认为一家伟大的计算机公司就应该制造出伟大的计算机，让人感觉有点目光短浅。而比尔盖茨的想法则有所不同，他力图在更多不同种类和价格的 x86 机器上使用他的 DOS 系统。

拥有大量用户基数的平台会成为第三方开发者开发软件的平台，而软件资源丰富又会让你的计算机更受用户欢迎。

即使是苹果公司也几乎被打败。在 x86 芯片上投入大量的财力，最终，这些芯片被用于生产环境计算任务。

但 ARM 架构也并没有消失。基于 ARM 架构的芯片不仅运算速度快，同时也非常节能。因此诸如机顶盒、PDA、数码相机、MP3 播放器这些电子产品多数都会采用 ARM 架构的芯片，甚至在很多需要用电池或不配备大散热风扇的电子产品上，都可以见到 ARM 芯片的身影。

而 ARM 则脱离 Acorn 成为了一种特殊的商业模式，他们不生产实物芯片，仅仅是向芯片生产厂商出售相关的知识产权。

因此，这或多或少是 ARM 芯片被应用于如此之多的手机和平板电脑上的原因。当 Linux 被移植到这种架构的芯片上时，开源技术的大门就已经向它打开了，这才让我们今天得以在这些芯片上运行 web 爬虫程序。

服务器端的 ARM

诸如微软和 Cloudflare 这些大厂都在基础设施建设上花了重金，所以对于我们这些预算不高的用户来说，可以选择的余地并不多。

实际上，如果你的信用卡只够付每月数美元的 VPS 费用，一直以来只能考虑 Scaleway 这个高性价比的厂商。

但自从数个月前公有云巨头 AWS 推出了他们自研的 ARM 处理器 AWS Graviton 之后，选择似乎就丰富了一些。

我决定在其中选择一款 VPS 厂商，将它提供的 ARM 处理器和 x86 处理器作出对比。

深入了解

所以我们要对比的是什么指标呢？

Scaleway

Scaleway 自身的定位是“专为开发者设计”。我觉得这个定位很准确，对于开发和原型设计来说，Scaleway 提供的产品确实可以作为一个很好的沙盒环境。

Scaleway 提供了一个简洁的仪表盘页面，让用户可以快速地从主页进入 bash shell 界面。对于很多小企业、自由职业者或者技术顾问，如果想要运行 web 爬虫，这个产品毫无疑问是一个物美价廉的选择。

ARM 方面我们选择 ARM64-2GB 这一款服务器，每月只需要 3 欧元。它带有 4 个 Cavium ThunderX 核心，这是在 2014 年推出的第一款服务器级的 ARMv8 处理器。但现在看来它已经显得有点落后了，并逐渐被更新的 ThunderX2 取代。

x86 方面我们选择 1-S，每月的费用是 4 欧元。它拥有 2 个英特尔 Atom C3995 核心。英特尔的 Atom 系列处理器的特点是低功耗、单线程，最初是用在笔记本电脑上的，后来也被服务器所采用。

两者在处理器以外的条件都大致相同，都使用 2 GB 的内存、50 GB 的 SSD 存储以及 200 Mbit/s 的带宽。磁盘驱动器可能会有所不同，但由于我们运行的是 web 爬虫，基本都是在内存中完成操作，因此这方面的差异可以忽略不计。

为了避免我不能熟练使用包管理器的尴尬局面，两方的操作系统我都会选择使用 Debian 9。

Amazon Web Services（AWS）

当你还在注册 AWS 账号的时候，使用 Scaleway 的用户可能已经把提交信用卡信息、启动 VPS 实例、添加 sudo 用户、安装依赖包这一系列流程都完成了。AWS 的操作相对来说比较繁琐，甚至需要详细阅读手册才能知道你正在做什么。

当然这也是合理的，对于一些需求复杂或者特殊的企业用户，确实需要通过详细的配置来定制合适的使用方案。

我们所采用的 AWS Graviton 处理器是 AWS EC2（弹性计算云Elastic Compute Cloud）的一部分，我会以按需实例的方式来运行，这也是最贵但最简捷的方式。AWS 同时也提供竞价实例，这样可以用较低的价格运行实例，但实例的运行时间并不固定。如果实例需要长时间持续运行，还可以选择预留实例。

看，AWS 就是这么复杂……

我们分别选择 a1.medium 和 t2.small 两种型号的实例进行对比，两者都带有 2GB 内存。这个时候问题来了，这里提到的 vCPU 又是什么？两种型号的不同之处就在于此。

对于 a1.medium 型号的实例，vCPU 是 AWS Graviton 芯片提供的单个计算核心。这个芯片由被亚马逊在 2015 收购的以色列厂商 Annapurna Labs 研发，是 AWS 独有的单线程 64 位 ARMv8 内核。它的按需价格为每小时 0.0255 美元。

而 t2.small 型号实例使用英特尔至强系列芯片，但我不确定具体是其中的哪一款。它每个核心有两个线程，但我们并不能用到整个核心，甚至整个线程。

我们能用到的只是“20% 的基准性能，可以使用 CPU 积分突破这个基准”。这可能有一定的原因，但我没有弄懂。它的按需价格是每小时 0.023 美元。

在镜像库中没有 Debian 发行版的镜像，因此我选择了 Ubuntu 18.04。

瘪四与大头蛋爬取 Moz 排行榜前 500 的网站

要测试这些 VPS 的 CPU 性能，就该使用爬虫了。一个方法是对几个网站在尽可能短的时间里发出尽可能多的请求，但这种操作不太礼貌，我的做法是只向大量网站发出少数几个请求。

为此，我编写了 beavis.py（瘪四）这个爬虫程序（致敬我最喜欢的物理学家和制片人 Mike Judge）。这个程序会将 Moz 上排行前 500 的网站都爬取 3 层的深度，并计算 “wood” 和 “ass” 这两个单词在 HTML 文件中出现的次数。（LCTT 译注：beavis（瘪四）和 butt-head（大头蛋） 都是 Mike Judge 的动画片《瘪四与大头蛋》中的角色）

但我实际爬取的网站可能不足 500 个，因为我需要遵循网站的 robot.txt 协定，另外还有些网站需要提交 javascript 请求，也不一定会计算在内。但这已经是一个足以让 CPU 保持繁忙的爬虫任务了。

Python 的全局解释器锁机制会让我的程序只能用到一个 CPU 线程。为了测试多线程的性能，我需要启动多个独立的爬虫程序进程。

因此我还编写了 butthead.py，尽管大头蛋很粗鲁，它也总是比瘪四要略胜一筹。

我将整个爬虫任务拆分为多个部分，这可能会对爬取到的链接数量有一点轻微的影响。但无论如何，每次爬取都会有所不同，我们要关注的是爬取了多少个页面，以及耗时多长。

在 ARM 服务器上安装 Scrapy

安装 Scrapy 的过程与芯片的不同架构没有太大的关系，都是安装 pip 和相关的依赖包之后，再使用 pip 来安装 Scrapy。

据我观察，在使用 ARM 的机器上使用 pip 安装 Scrapy 确实耗时要长一点，我估计是由于需要从源码编译为二进制文件。

在 Scrapy 安装结束后，就可以通过 shell 来查看它的工作状态了。

在 Scaleway 的 ARM 机器上，Scrapy 安装完成后会无法正常运行，这似乎和 service_identity 模块有关。这个现象也会在树莓派上出现，但在 AWS Graviton 上不会出现。

对于这个问题，可以用这个命令来解决：

1

sudo pip3 install service_identity --force --upgrade

接下来就可以开始对比了。

单线程爬虫

Scrapy 的官方文档建议将爬虫程序的 CPU 使用率控制在 80% 到 90% 之间，在真实操作中并不容易，尤其是对于我自己写的代码。根据我的观察，实际的 CPU 使用率变动情况是一开始非常繁忙，随后稍微下降，接着又再次升高。

在爬取任务的最后，也就是大部分目标网站都已经被爬取了的这个阶段，会持续数分钟的时间。这让人有点失望，因为在这个阶段当中，任务的运行时长只和网站的大小有比较直接的关系，并不能以之衡量 CPU 的性能。

所以这并不是一次严谨的基准测试，只是我通过自己写的爬虫程序来观察实际的现象。

下面我们来看看最终的结果。首先是 Scaleway 的机器：

我使用了 top 工具来查看爬虫程序运行期间的 CPU 使用率。在任务刚开始的时候，两者的 CPU 使用率都达到了 100%，但 ThunderX 大部分时间都达到了 CPU 的极限，无法看出来 Atom 的性能会比 ThunderX 超出多少。

通过 top 工具，我还观察了它们的内存使用情况。随着爬取任务的进行，ARM 机器的内存使用率最终达到了 14.7%，而 x86 则最终是 15%。

从运行日志还可以看出来，当 CPU 使用率到达极限时，会有大量的超时页面产生，最终导致页面丢失。这也是合理出现的现象，因为 CPU 过于繁忙会无法完整地记录所有爬取到的页面。

如果仅仅是为了对比爬虫的速度，页面丢失并不是什么大问题。但在实际中，业务成果和爬虫数据的质量是息息相关的，因此必须为 CPU 留出一些用量，以防出现这种现象。

再来看看 AWS 这边：

为了方便比较，对于在 AWS 上跑的爬虫，我记录的指标和 Scaleway 上一致，但似乎没有达到预期的效果。这里我没有使用 top，而是使用了 AWS 提供的控制台来监控 CPU 的使用情况，从监控结果来看，我的爬虫程序并没有完全用到这两款服务器所提供的所有性能。

a1.medium 型号的机器尤为如此，在任务开始阶段，它的 CPU 使用率达到了峰值 45%，但随后一直在 20% 到 30% 之间。

让我有点感到意外的是，这个程序在 ARM 处理器上的运行速度相当慢，但却远未达到 Graviton CPU 能力的极限，而在 Intel Atom 处理器上则可以在某些时候达到 CPU 能力的极限。它们运行的代码是完全相同的，处理器的不同架构可能导致了对代码的不同处理方式。

个中原因无论是由于处理器本身的特性，还是二进制文件的编译，又或者是两者皆有，对我来说都是一个黑盒般的存在。我认为，既然在 AWS 机器上没有达到 CPU 处理能力的极限，那么只有在 Scaleway 机器上跑出来的性能数据是可以作为参考的。

t2.small 型号的机器性能让人费解。CPU 利用率大概 20%，最高才达到 35%，是因为手册中说的“20% 的基准性能，可以使用 CPU 积分突破这个基准”吗？但在控制台中可以看到 CPU 积分并没有被消耗。

为了确认这一点，我安装了 stress 这个软件，然后运行了一段时间，这个时候发现居然可以把 CPU 使用率提高到 100% 了。

显然，我需要调整一下它们的配置文件。我将 CONCURRENT_REQUESTS 参数设置为 5000，将 REACTOR_THREADPOOL_MAXSIZE 参数设置为 120，将爬虫任务的负载调得更大。

a1.medium 型号机器的 CPU 使用率在爬虫任务开始后 5 分钟飙升到了 100%，随后下降到 80% 并持续了 20 分钟，然后再次攀升到 96%，直到任务接近结束时再次下降。这大概就是我想要的效果了。

而 t2.small 型号机器在爬虫任务的前期就达到了 50%，并一直保持在这个水平直到任务接近结束。如果每个核心都有两个线程，那么 50% 的 CPU 使用率确实是单个线程可以达到的极限了。

现在我们看到它们的性能都差不多了。但至强处理器的线程持续跑满了 CPU，Graviton 处理器则只是有一段时间如此。可以认为 Graviton 略胜一筹。

然而，如果 CPU 积分耗尽了呢？这种情况下的对比可能更为公平。为了测试这种情况，我使用 stress 把所有的 CPU 积分用完，然后再次启动了爬虫任务。

在没有 CPU 积分的情况下，CPU 使用率在 27% 就到达极限不再上升了，同时又出现了丢失页面的现象。这么看来，它的性能比负载较低的时候更差。

多线程爬虫

将爬虫任务分散到不同的进程中，可以有效利用机器所提供的多个核心。

一开始，我将爬虫任务分布在 10 个不同的进程中并同时启动，结果发现比每个核心仅使用 1 个进程的时候还要慢。

经过尝试，我得到了一个比较好的方案。把爬虫任务分布在 10 个进程中，但每个核心只启动 1 个进程，在每个进程接近结束的时候，再从剩余的进程中选出 1 个进程启动起来。

如果还需要优化，还可以让运行时间越长的爬虫进程在启动顺序中排得越靠前，我也在尝试实现这个方法。

想要预估某个域名的页面量，一定程度上可以参考这个域名主页的链接数量。我用另一个程序来对这个数量进行了统计，然后按照降序排序。经过这样的预处理之后，只会额外增加 1 分钟左右的时间。

结果，爬虫运行的总耗时超过了两个小时！毕竟把链接最多的域名都堆在同一个进程中也存在一定的弊端。

针对这个问题，也可以通过调整各个进程爬取的域名数量来进行优化，又或者在排序之后再作一定的修改。不过这种优化可能有点复杂了。

因此，我还是用回了最初的方法，它的效果还是相当不错的：

毕竟，使用多个核心能够大大加快爬虫的速度。

我认为，如果让一个经验丰富的程序员来优化的话，一定能够更好地利用所有的计算核心。但对于开箱即用的 Scrapy 来说，想要提高性能，使用更快的线程似乎比使用更多核心要简单得多。

从数量来看，Atom 处理器在更短的时间内爬取到了更多的页面。但如果从性价比角度来看，ThunderX 又是稍稍领先的。不过总的来说差距不大。

爬取结果分析

在爬取了 38205 个页面之后，我们可以统计到在这些页面中 “ass” 出现了 24170435 次，而 “wood” 出现了 54368 次。

“wood” 的出现次数不少，但和 “ass” 比起来简直微不足道。

结论

从上面的数据来看，对于性能而言，CPU 的架构并没有它们的问世时间重要，2018 年生产的 AWS Graviton 是单线程情况下性能最佳的。

你当然可以说按核心来比，Xeon 仍然赢了。但是，你不但需要计算美元的变化，甚至还要计算线程数。

另外在性能方面 2017 年生产的 Atom 轻松击败了 2014 年生产的 ThunderX，而 ThunderX 则在性价比方面占优。当然，如果你使用 AWS 的机器的话，还是使用 Graviton 吧。

总之，ARM 架构的硬件是可以用来运行爬虫程序的，而且在性能和费用方面也相当有竞争力。

而这种差异是否足以让你将整个技术架构迁移到 ARM 上？这就是另一回事了。当然，如果你已经是 AWS 用户，并且你的代码有很强的可移植性，那么不妨尝试一下 a1 型号的实例。

希望 ARM 设备在不久的将来能够在公有云上大放异彩。

源代码

这是我第一次使用 Python 和 Scrapy 来做一个项目，所以我的代码写得可能不是很好，例如代码中使用全局变量就有点力不从心。

不过我仍然会在下面开源我的代码。

要运行这些代码，需要预先安装 Scrapy，并且需要 Moz 上排名前 500 的网站的 csv 文件。如果要运行 butthead.py，还需要安装 psutil 这个库。

beavis.py

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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99

import scrapy
from scrapy.spiders import CrawlSpider, Rule
from scrapy.linkextractors import LinkExtractor
from scrapy.crawler import CrawlerProcess

ass = 0
wood = 0
totalpages = 0

def getdomains():

  moz500file = open('top500.domains.05.18.csv')

  domains = []
  moz500csv = moz500file.readlines()

  del moz500csv[0]

  for csvline in moz500csv:
    leftquote = csvline.find('"')    
    rightquote = leftquote + csvline[leftquote + 1:].find('"')
    domains.append(csvline[leftquote + 1:rightquote])

  return domains

def getstartpages(domains):
  
  startpages = []
  
  for domain in domains:
    startpages.append('http://' + domain)
  
  return startpages
  
class AssWoodItem(scrapy.Item):
  ass = scrapy.Field()
  wood = scrapy.Field()
  url = scrapy.Field()
  
class AssWoodPipeline(object):
  def __init__(self):
    self.asswoodstats = []

  def process_item(self, item, spider):
    self.asswoodstats.append((item.get('url'), item.get('ass'), item.get('wood')))
    
  def close_spider(self, spider):
    asstally, woodtally = 0, 0
    
    for asswoodcount in self.asswoodstats:
      asstally += asswoodcount[1]
      woodtally += asswoodcount[2]
      
    global ass, wood, totalpages
    ass = asstally
    wood = woodtally
    totalpages = len(self.asswoodstats)

class BeavisSpider(CrawlSpider):
  name = "Beavis"
  allowed_domains = getdomains()
  start_urls = getstartpages(allowed_domains)
  #start_urls = [ 'http://medium.com' ]
  custom_settings = {
    'DEPTH_LIMIT': 3,
    'DOWNLOAD_DELAY': 3,
    'CONCURRENT_REQUESTS': 1500,
    'REACTOR_THREADPOOL_MAXSIZE': 60,
    'ITEM_PIPELINES': { '__main__.AssWoodPipeline': 10 },
    'LOG_LEVEL': 'INFO',
    'RETRY_ENABLED': False,
    'DOWNLOAD_TIMEOUT': 30,
    'COOKIES_ENABLED': False,
    'AJAXCRAWL_ENABLED': True
  }
    
  rules = ( Rule(LinkExtractor(), callback='parse_asswood'), )
  
  def parse_asswood(self, response):
    if isinstance(response, scrapy.http.TextResponse):
      item = AssWoodItem()
      item['ass'] = response.text.casefold().count('ass')
      item['wood'] = response.text.casefold().count('wood')
      item['url'] = response.url
      yield item


if __name__ == '__main__':

  process = CrawlerProcess({
      'USER_AGENT': 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)'
  })

  process.crawl(BeavisSpider)
  process.start()

  print('Uhh, that was, like, ' + str(totalpages) + ' pages crawled.')
  print('Uh huhuhuhuh. It said ass ' + str(ass) + ' times.')
  print('Uh huhuhuhuh. It said wood ' + str(wood) + ' times.')

butthead.py

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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135

import scrapy, time, psutil
from scrapy.spiders import CrawlSpider, Rule, Spider
from scrapy.linkextractors import LinkExtractor
from scrapy.crawler import CrawlerProcess
from multiprocessing import Process, Queue, cpu_count

ass = 0
wood = 0
totalpages = 0
linkcounttuples =[]

def getdomains():

  moz500file = open('top500.domains.05.18.csv')

  domains = []
  moz500csv = moz500file.readlines()

  del moz500csv[0]

  for csvline in moz500csv:
    leftquote = csvline.find('"')    
    rightquote = leftquote + csvline[leftquote + 1:].find('"')
    domains.append(csvline[leftquote + 1:rightquote])

  return domains

def getstartpages(domains):
  
  startpages = []
  
  for domain in domains:
    startpages.append('http://' + domain)
  
  return startpages
  
class AssWoodItem(scrapy.Item):
  ass = scrapy.Field()
  wood = scrapy.Field()
  url = scrapy.Field()
  
class AssWoodPipeline(object):
  def __init__(self):
    self.asswoodstats = []

  def process_item(self, item, spider):
    self.asswoodstats.append((item.get('url'), item.get('ass'), item.get('wood')))
    
  def close_spider(self, spider):
    asstally, woodtally = 0, 0
    
    for asswoodcount in self.asswoodstats:
      asstally += asswoodcount[1]
      woodtally += asswoodcount[2]
      
    global ass, wood, totalpages
    ass = asstally
    wood = woodtally
    totalpages = len(self.asswoodstats)
          

class ButtheadSpider(CrawlSpider):
  name = "Butthead"
  custom_settings = {
    'DEPTH_LIMIT': 3,
    'DOWNLOAD_DELAY': 3,
    'CONCURRENT_REQUESTS': 250,
    'REACTOR_THREADPOOL_MAXSIZE': 30,
    'ITEM_PIPELINES': { '__main__.AssWoodPipeline': 10 },
    'LOG_LEVEL': 'INFO',
    'RETRY_ENABLED': False,
    'DOWNLOAD_TIMEOUT': 30,
    'COOKIES_ENABLED': False,
    'AJAXCRAWL_ENABLED': True
  }
    
  rules = ( Rule(LinkExtractor(), callback='parse_asswood'), )
  
  
  def parse_asswood(self, response):
    if isinstance(response, scrapy.http.TextResponse):
      item = AssWoodItem()
      item['ass'] = response.text.casefold().count('ass')
      item['wood'] = response.text.casefold().count('wood')
      item['url'] = response.url
      yield item

def startButthead(domainslist, urlslist, asswoodqueue):
  crawlprocess = CrawlerProcess({
      'USER_AGENT': 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)'
  })

  crawlprocess.crawl(ButtheadSpider, allowed_domains = domainslist, start_urls = urlslist)
  crawlprocess.start()
  asswoodqueue.put( (ass, wood, totalpages) )
  

if __name__ == '__main__':
  asswoodqueue = Queue()
  domains=getdomains()
  startpages=getstartpages(domains)
  processlist =[]
  cores = cpu_count()
  
  for i in range(10):
    domainsublist = domains[i * 50:(i + 1) * 50]
    pagesublist = startpages[i * 50:(i + 1) * 50]
    p = Process(target = startButthead, args = (domainsublist, pagesublist, asswoodqueue))
    processlist.append(p)
  
  for i in range(cores):
    processlist[i].start()
    
  time.sleep(180)
  
  i = cores
  
  while i != 10:
    time.sleep(60)
    if psutil.cpu_percent() < 66.7:
      processlist[i].start()
      i += 1
  
  for i in range(10):
    processlist[i].join()
  
  for i in range(10):
    asswoodtuple = asswoodqueue.get()
    ass += asswoodtuple[0]
    wood += asswoodtuple[1]
    totalpages += asswoodtuple[2]

  print('Uhh, that was, like, ' + str(totalpages) + ' pages crawled.')
  print('Uh huhuhuhuh. It said ass ' + str(ass) + ' times.')
  print('Uh huhuhuhuh. It said wood ' + str(wood) + ' times.')

via: https://blog.dxmtechsupport.com.au/speed-test-x86-vs-arm-for-web-crawling-in-python/

让我们继续我们的 Bash 基础之旅，来近距离观察一下花括号，了解一下如何和何时使用它们。

在前面的 Bash 基础系列文章中，我们或多或少地使用了一些还没有讲到的符号。在之前文章的很多例子中，我们都使用到了括号，但并没有重点讲解关于括号的内容。

这个系列接下来的文章中，我们会研究括号们的用法：如何使用这些括号？将它们放在不同的位置会有什么不同的效果？除了圆括号、方括号、花括号以外，我们还会接触另外的将一些内容“包裹”起来的符号，例如单引号、双引号和反引号。

在这周，我们先来看看花括号 {}。

构造序列

花括号在之前的《点的含义》这篇文章中已经出现过了，当时我们只对点号 . 的用法作了介绍。但在构建一个序列的过程中，同样不可以缺少花括号。

我们使用

1

echo {0..10}

来顺序输出 0 到 10 这 11 个数。使用

1

echo {10..0}

可以将这 11 个数倒序输出。更进一步，可以使用

1

echo {10..0..2}

来跳过其中的奇数。

而

1

echo {z..a..2}

则从倒序输出字母表，并跳过其中的第奇数个字母。

以此类推。

还可以将两个序列进行组合：

1

echo {a..z}{a..z}

这个命令会将从 aa 到 zz 的所有双字母组合依次输出。

这是很有用的。在 Bash 中，定义一个数组的方法是在圆括号 () 中放置各个元素并使用空格隔开，就像这样：

1

month=("Jan" "Feb" "Mar" "Apr" "May" "Jun" "Jul" "Aug" "Sep" "Oct" "Nov" "Dec")

如果需要获取数组中的元素，就要使用方括号 [] 并在其中填入元素的索引：

1
2

$ echo ${month[3]} # 数组索引从 0 开始，因此 [3] 对应第 4 个元素
Apr

先不要过分关注这里用到的三种括号，我们等下会讲到。

注意，像上面这样，我们可以定义这样一个数组：

1

letter_combos=({a..z}{a..z})

其中 letter_combos 变量指向的数组依次包含了从 aa 到 zz 的所有双字母组合。

因此，还可以这样定义一个数组：

1

dec2bin=({0..1}{0..1}{0..1}{0..1}{0..1}{0..1}{0..1}{0..1})

在这里，dec2bin 变量指向的数组按照升序依次包含了所有 8 位的二进制数，也就是 00000000、00000001、00000010，……，11111111。这个数组可以作为一个十进制数到 8 位二进制数的转换器。例如将十进制数 25 转换为二进制数，可以这样执行：

1
2

$ echo ${dec2bin[25]}
00011001

对于进制转换，确实还有更好的方法，但这不失为一个有趣的方法。

参数展开

再看回前面的

1

echo ${month[3]}

在这里，花括号的作用就不是构造序列了，而是用于参数展开parameter expansion。顾名思义，参数展开就是将花括号中的变量展开为这个变量实际的内容。

我们继续使用上面的 month 数组来举例：

1

month=("Jan" "Feb" "Mar" "Apr" "May" "Jun" "Jul" "Aug" "Sep" "Oct" "Nov" "Dec")

注意，Bash 中的数组索引从 0 开始，因此 3 代表第 4 个元素 "Apr"。因此 echo ${month[3]} 在经过参数展开之后，相当于 echo "Apr"。

像上面这样将一个数组展开成它所有的元素，只是参数展开的其中一种用法。另外，还可以通过参数展开的方式读取一个字符串变量，并对其进行处理。

例如对于以下这个变量：

1

a="Too longgg"

如果执行：

1

echo ${a%gg}

可以输出 “too long”，也就是去掉了最后的两个 g。

在这里，

• ${...} 告诉 shell 展开花括号里的内容
• a 就是需要操作的变量
• % 告诉 shell 需要在展开字符串之后从字符串的末尾去掉某些内容
• gg 是被去掉的内容

这个特性在转换文件格式的时候会比较有用，我来举个例子：

ImageMagick 是一套可以用于操作图像文件的命令行工具，它有一个 convert 命令。这个 convert 命令的作用是可以为某个格式的图像文件制作一个另一格式的副本。

下面这个命令就是使用 convert 为 JPEG 格式图像 image.jpg 制作一个 PNG 格式的图像副本 image.png：

1

convert image.jpg image.png

在很多 Linux 发行版中都预装了 ImageMagick，如果没有预装，一般可以在发行版对应的软件管理器中找到。

继续来看，在对变量进行展开之后，就可以批量执行相类似的操作了：

1
2

i=image.jpg
convert $i ${i%jpg}png

这实际上是将变量 i 末尾的 "jpg" 去掉，然后加上 "png"，最终将整个命令拼接成 convert image.jpg image.png。

如果你觉得并不怎么样，可以想象一下有成百上千个图像文件需要进行这个操作，而仅仅运行：

1

for i in *.jpg; do convert $i ${i%jpg}png; done

就瞬间完成任务了。

如果需要去掉字符串开头的部分，就要将上面的 % 改成 # 了：

1
2
3

$ a="Hello World!"
$ echo Goodbye${a#Hello}
Goodbye World!

参数展开还有很多用法，但一般在写脚本的时候才会需要用到。在这个系列以后的文章中就继续提到。

合并输出

最后介绍一个花括号的用法，这个用法很简单，就是可以将多个命令的输出合并在一起。首先看下面这个命令：

1

echo "I found all these PNGs:"; find . -iname "*.png"; echo "Within this bunch of files:"; ls > PNGs.txt

以分号分隔开的几条命令都会执行，但只有最后的 ls 命令的结果输出会被重定向到 PNGs.txt 文件中。如果将这几条命令用花括号包裹起来，就像这样：

1

{ echo "I found all these PNGs:"; find . -iname "*.png"; echo "Within this bunch of files:"; ls; } > PNGs.txt

执行完毕后，可以看到 PNGs.txt 文件中会包含两次 echo 的内容、find 命令查找到的 PNG 文件以及最后的 ls 命令结果。

需要注意的是，花括号与命令之间需要有空格隔开。因为这里的花括号 { 和 } 是作为 shell 中的保留字，shell 会将这两个符号之间的输出内容组合到一起。

另外，各个命令之间要用分号 ; 分隔，否则命令无法正常运行。

下期预告

在后续的文章中，我会介绍其它“包裹”类符号的用法，敬请关注。

via: https://www.linux.com/blog/learn/2019/2/all-about-curly-braces-bash

你会希望某黑客J. Random Hacker假冒你的银行吗？

近年来，量子计算机quantum computer已经出现在大众的视野当中。量子计算机被认为是第六类计算机，这六类计算机包括：

1. 人力Humans：在人造的计算工具出现之前，人类只能使用人力去进行计算。而承担计算工作的人，只能被称为“计算者”。
2. 模拟计算工具Mechanical analogue：由人类制造的一些模拟计算过程的小工具，例如安提凯希拉装置Antikythera mechanism、星盘astrolabe、计算尺slide rule等等。
3. 机械工具Mechanical digital：在这一个类别中包括了运用到离散数学但未使用电子技术进行计算的工具，例如算盘abacus、Charles Babbage 的差分机Difference Engine等等。
4. 电子模拟计算工具Electronic analogue：这一个类别的计算机多数用于军事方面的用途，例如炸弹瞄准器、枪炮瞄准装置等等。
5. 电子计算机Electronic digital：我在这里会稍微冒险一点，我觉得 Colossus 是第一台电子计算机，[^1] ：这一类几乎包含现代所有的电子设备，从移动电话到超级计算机，都在这个类别当中。
6. 量子计算机Quantum computer：即将进入我们的生活，而且与之前的几类完全不同。

什么是量子计算？

量子计算Quantum computing的概念来源于量子力学quantum mechanics，使用的计算方式和我们平常使用的普通计算非常不同。如果想要深入理解，建议从参考维基百科上的定义开始。对我们来说，最重要的是理解这一点：量子计算机使用量子位qubit进行计算。在这样的前提下，对于很多数学算法和运算操作，量子计算机的计算速度会比普通计算机要快得多。

这里的“快得多”是按数量级来说的“快得多”。在某些情况下，一个计算任务如果由普通计算机来执行，可能要耗费几年或者几十年才能完成，但如果由量子计算机来执行，就只需要几秒钟。这样的速度甚至令人感到可怕。因为量子计算机会非常擅长信息的加密解密计算，即使在没有密钥的情况下，也能快速完成繁重的计算任务。

这意味着，如果拥有足够强大的量子计算机，那么你的所有信息都会被一览无遗，任何被加密的数据都可以被正确解密出来，甚至伪造数字签名也会成为可能。这确实是一个严重的问题。谁也不想被某个黑客冒充成自己在用的银行，更不希望自己在区块链上的交易被篡改得面目全非。

好消息

尽管上面的提到的问题非常可怕，但也不需要太担心。

首先，如果要实现上面提到的能力，一台可以操作大量量子位的量子计算机是必不可少的，而这个硬件上的要求就是一个很高的门槛。[^4] 目前普遍认为，规模大得足以有效破解经典加密算法的量子计算机在最近几年还不可能出现。

其次，除了攻击现有的加密算法需要大量的量子位以外，还需要很多量子位来保证容错性。

还有，尽管确实有一些理论上的模型阐述了量子计算机如何对一些现有的算法作出攻击，但是要让这样的理论模型实际运作起来的难度会比我们[^5] 想象中大得多。事实上，有一些攻击手段也是未被完全确认是可行的，又或者这些攻击手段还需要继续耗费很多年的改进才能到达如斯恐怖的程度。

最后，还有很多专业人士正在研究能够防御量子计算的算法（这样的算法也被称为“后量子算法post-quantum algorithms”）。如果这些防御算法经过测试以后投入使用，我们就可以使用这些算法进行加密，来对抗量子计算了。

总而言之，很多专家都认为，我们现有的加密方式在未来 5 年甚至未来 10 年内都是安全的，不需要过分担心。

也有坏消息

但我们也并不是高枕无忧了，以下两个问题就值得我们关注：

1. 人们在设计应用系统的时候仍然没有对量子计算作出太多的考量。如果设计的系统可能会使用 10 年以上，又或者数据加密和签名的时间跨度在 10 年以上，那么就必须考虑量子计算在未来会不会对系统造成不利的影响。
2. 新出现的防御量子计算的算法可能会是专有的。也就是说，如果基于这些防御量子计算的算法来设计系统，那么在系统落地的时候，可能会需要为此付费。尽管我是支持开源的，尤其是开源密码学，但我最担心的就是无法开源这方面的内容。而且最糟糕的是，在建立新的协议标准时（不管是事实标准还是通过标准组织建立的标准），无论是故意的，还是无意忽略，或者是没有好的开源替代品，他们都很可能使用专有算法而排除使用开源算法。

我们要怎样做？

幸运的是，针对上述两个问题，我们还是有应对措施的。首先，在整个系统的设计阶段，就需要考虑到它是否会受到量子计算的影响，并作出相应的规划。当然了，不需要现在就立即采取行动，因为当前的技术水平也没法实现有效的方案，但至少也要在加密方面保持敏捷性，以便在任何需要的时候为你的协议和系统更换更有效的加密算法。[^7]

其次是参与开源运动。尽可能鼓励密码学方面的有识之士团结起来，支持开放标准，并投入对非专有的防御量子计算的算法研究当中去。这一点也算是当务之急，因为号召更多的人重视起来并加入研究，比研究本身更为重要。

本文首发于《Alice, Eve, and Bob》，并在作者同意下重新发表。

[^1]: 我认为把它称为第一台电子可编程计算机是公平的。我知道有早期的非可编程的，也有些人声称是 ENIAC，但我没有足够的空间或精力在这里争论这件事。
[^2]: No。
[^3]: See 2. Don’t get me wrong, by the way—I grew up near Weston-super-Mare, and it’s got things going for it, but it’s not Mayfair.
[^4]: 如果量子物理学家说很难，那么在我看来，就很难。
[^5]: 而且我假设我们都不是量子物理学家或数学家。
[^6]: I’m definitely not.
[^7]: 而且不仅仅是出于量子计算的原因：我们现有的一些经典算法很可能会陷入其他非量子攻击，例如新的数学方法。

via: https://opensource.com/article/19/1/will-quantum-computing-break-security

这篇文章将了解一下 & 符号及它在 Linux 命令行中的各种用法。

如果阅读过我之前的三篇文章（1、2、3），你会觉得掌握连接各个命令之间的连接符号用法也是很重要的。实际上，命令的用法并不难，例如 mkdir、touch 和 find 也分别可以简单概括为“建立新目录”、“更新文件”和“在目录树中查找文件”而已。

但如果要理解

1

mkdir test_dir 2>/dev/null || touch images.txt && find . -iname "*jpg" > backup/dir/images.txt &

这一串命令的目的，以及为什么要这样写，就没有这么简单了。

关键之处就在于命令之间的连接符号。掌握了这些符号的用法，不仅可以让你更好理解整体的工作原理，还可以让你知道如何将不同的命令有效地结合起来，提高工作效率。

在这一篇文章和接下来的文章中，我会介绍如何使用 & 号和管道符号（|）在不同场景下的使用方法。

幕后工作

我来举一个简单的例子，看看如何使用 & 号将下面这个命令放到后台运行：

1

cp -R original/dir/ backup/dir/

这个命令的目的是将 original/dir/ 的内容递归地复制到 backup/dir/ 中。虽然看起来很简单，但是如果原目录里面的文件太大，在执行过程中终端就会一直被卡住。

所以，可以在命令的末尾加上一个 & 号，将这个任务放到后台去执行：

1

cp -R original/dir/ backup/dir/ &

任务被放到后台执行之后，就可以立即继续在同一个终端上工作了，甚至关闭终端也不影响这个任务的正常执行。需要注意的是，如果要求这个任务输出内容到标准输出中（例如 echo 或 ls），即使使用了 &，也会等待这些输出任务在前台运行完毕。

当使用 & 将一个进程放置到后台运行的时候，Bash 会提示这个进程的进程 ID。在 Linux 系统中运行的每一个进程都有一个唯一的进程 ID，你可以使用进程 ID 来暂停、恢复或者终止对应的进程，因此进程 ID 是非常重要的。

这个时候，只要你还停留在启动进程的终端当中，就可以使用以下几个命令来对管理后台进程：

• jobs 命令可以显示当前终端正在运行的进程，包括前台运行和后台运行的进程。它对每个正在执行中的进程任务分配了一个序号（这个序号不是进程 ID），可以使用这些序号来引用各个进程任务。

  1 2 3

  $ jobs [1]- Running cp -i -R original/dir/* backup/dir/ & [2]+ Running find . -iname "*jpg" > backup/dir/images.txt &

• fg 命令可以将后台运行的进程任务放到前台运行，这样可以比较方便地进行交互。根据 jobs 命令提供的进程任务序号，再在前面加上 % 符号，就可以把相应的进程任务放到前台运行。

  1 2	$ fg %1 # 将上面序号为 1 的 cp 任务放到前台运行 cp -i -R original/dir/* backup/dir/

  如果这个进程任务是暂停状态，fg 命令会将它启动起来。

• 使用 ctrl+z 组合键可以将前台运行的任务暂停，仅仅是暂停，而不是将任务终止。当使用 fg 或者 bg 命令将任务重新启动起来的时候，任务会从被暂停的位置开始执行。但 sleep 命令是一个特例，sleep 任务被暂停的时间会计算在 sleep 时间之内。因为 sleep 命令依据的是系统时钟的时间，而不是实际运行的时间。也就是说，如果运行了 sleep 30，然后将任务暂停 30 秒以上，那么任务恢复执行的时候会立即终止并退出。

• bg 命令会将任务放置到后台执行，如果任务是暂停状态，也会被启动起来。

  1 2	$ bg %1 [1]+ cp -i -R original/dir/* backup/dir/ &

如上所述，以上几个命令只能在同一个终端里才能使用。如果启动进程任务的终端被关闭了，或者切换到了另一个终端，以上几个命令就无法使用了。

如果要在另一个终端管理后台进程，就需要其它工具了。例如可以使用 kill 命令从另一个终端终止某个进程：

1

kill -s STOP <PID>

这里的 PID 就是使用 & 将进程放到后台时 Bash 显示的那个进程 ID。如果你当时没有把进程 ID 记录下来，也可以使用 ps 命令（代表 process）来获取所有正在运行的进程的进程 ID，就像这样：

1

ps | grep cp

执行以后会显示出包含 cp 字符串的所有进程，例如上面例子中的 cp 进程。同时还会显示出对应的进程 ID：

1
2

$ ps | grep cp
14444 pts/3 00:00:13 cp

在这个例子中，进程 ID 是 14444，因此可以使用以下命令来暂停这个后台进程：

1

kill -s STOP 14444

注意，这里的 STOP 等同于前面提到的 ctrl+z 组合键的效果，也就是仅仅把进程暂停掉。

如果想要把暂停了的进程启动起来，可以对进程发出 CONT 信号：

1

kill -s CONT 14444

这个给出一个可以向进程发出的常用信号列表。如果想要终止一个进程，可以发送 TERM 信号：

1

kill -s TERM 14444

如果进程不响应 TERM 信号并拒绝退出，还可以发送 KILL 信号强制终止进程：

1

kill -s KILL 14444

强制终止进程可能会有一定的风险，但如果遇到进程无节制消耗资源的情况，这样的信号还是能够派上用场的。

另外，如果你不确定进程 ID 是否正确，可以在 ps 命令中加上 x 参数：

1
2
3
4

$ ps x| grep cp
14444 pts/3 D 0:14 cp -i -R original/dir/Hols_2014.mp4
  original/dir/Hols_2015.mp4 original/dir/Hols_2016.mp4
  original/dir/Hols_2017.mp4 original/dir/Hols_2018.mp4 backup/dir/

这样就可以看到是不是你需要的进程 ID 了。

最后介绍一个将 ps 和 grep 结合到一起的命令：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

$ pgrep cp
8
18
19
26
33
40
47
54
61
72
88
96
136
339
6680
13735
14444

pgrep 可以直接将带有字符串 cp 的进程的进程 ID 显示出来。

可以加上一些参数让它的输出更清晰：

1
2

$ pgrep -lx cp
14444 cp

在这里，-l 参数会让 pgrep 将进程的名称显示出来，-x 参数则是让 pgrep 完全匹配 cp 这个命令。如果还想了解这个命令的更多细节，可以尝试运行 pgrep -ax。

总结

在命令的末尾加上 & 可以让我们理解前台进程和后台进程的概念，以及如何管理这些进程。

在 UNIX/Linux 术语中，在后台运行的进程被称为守护进程daemon。如果你曾经听说过这个词，那你现在应该知道它的意义了。

和其它符号一样，& 在命令行中还有很多别的用法。在下一篇文章中，我会更详细地介绍。

via: https://www.linux.com/blog/learn/2019/2/and-ampersand-and-linux