我的扒图工具开发过程（二）

上一节我们已经完成了基本功能的扒图工具了，但下载整个网站图片，单靠一个for循环跑不现实，看来要多开几个进程同时进行下载。第一个进程从for 0 to 500, 第二个进程从for 501 to 1000, 如此类推，要下完5000个系列图片要开10个进程下载。

我们将一个进程看成一个工人的话，那么我们就要请10个工人工作，这10个工人都要处理以下三个任务：

• 根据某系列图片首页网址https://xxxx.com/xxx/${id}.html，获取其内容，分析该系列图片的最大页数，并根据规律得到该系列图片的所有网页地址：https://xxxx.com/xxx/${id}.html~https://xxxx.com/xxx/${id}_${total}.html
• 获取这些网页内容，取得其图片地址
• 下载这些图片

每个任务又要有ErrorHandling的处理，每个进程的 任务就相对复杂了。就像一个手工作坊，以加大产量就要请大量工人，而且每个工人任务复杂，培养不容易。那么我们有什么可以改进的呢？

福特的流水线革命给了我灵感，如果将手工作坊改造成流水线，每个工人只负责一项任务，完成任务后，将输出交给流水线，另一个工人接收到处理完后，再交给流水线，这样每个工人处理的任务就会变得单一，代码逻辑就会变得简单，错误处理也就相对容易得多了。

那么扒图工具2.0改进就进行流水线改进，这个流水线叫做MQ (消息队列)。

待选流水线有以下几款：

• RocketMQ
• RabbitMQ
• ActiveMQ
• Redis
• Kafka
• ZeroMQ
  最后综合各方面考虑因素，RabbitMQ凭着高可靠性，以及丰富帮忙文档胜出。虽然在吞吐效率方面比不上Kafka，但由于我的需求重点在可靠性方面及易上手方面，因此吞吐效率在这种需求下无优势。

MQ主要有两种基本方式:

• Topic
  简单来说，广播式，发出去后只要subscript同一频道的都可以收到信息，信息发出后就会丢弃，不管是否有接收者收到。
• Queue
  简单来说，队列式，发出去后只会有一个接收者抢到该信息，接收者处理完后才确定是否要丢弃。如果无接收者，该信息会一直保留在队列 。

此次改进为验证式改进，使用单一Qeueu方式处理信息。改进后流程如下图

下一节，将上详细代码。