目标是尽快完成这4个任务，下面是一些可能的示例方法。
样品可能途径
多步骤1：刮所有页面和存储HTML作为.txt文件。在将所有HTML存储为文本后，运行一个单独的模块来解析/清除/保留数据。
多步骤2：刮/解析/清理数据，并存储在.txt文件。运行一个单独的模块将数据插入到数据库中。
单步：刮/解析/清洁/坚持所有在一个步骤中的数据。
假设：
我还没有用node.js进行足够的测试来建立最佳实践，但对于优化这些任务的任何见解都将不胜感激。
很明显，有一些没有答案的问题（一个典型页面有多少html，你的解析有多少，请求/响应延迟，正在使用什么框架来解析数据等），但是一个高最佳实践/关键考虑将是有益的。谢谢。
有了这样的问题，您只能预见什么才能真正控制瓶颈的某些方面。所以，你从一个聪明但不复杂的实现开始，并花费相当长的时间来弄清楚如何衡量你的性能以及瓶颈在哪里。
然后，根据瓶颈位置的知识，您提出了一个建议的设计更改，实施该更改并查看您在整体吞吐量方面的差异有多大。然后你再次测量仪器，再次测量，看看你的新瓶颈在哪里，想出一个关于如何击败瓶颈，执行，测量，理论，迭代等的新理论......
你真的不想要过度设计或过度复杂的第一个实现，因为在你认为真正的瓶颈将在哪里很容易出错。
所以，我可能会用这样的设计开始了：
创建一个Node.js的过程，它不是绝对没有，但下载的网页，并将其写入到磁盘中。异步I/O在任何地方都不会使用，并且可以配置一次同时有多少个同时下载的页面。不要解析，只需将原始数据写入磁盘即可。你会想找到一些非常快速的方式来存储哪个URL是哪个文件。这可能与将信息附加到文本文件中一样简单，或者可能是数据库写入，但想法是您只希望它速度很快。
然后，创建另一个Node.js的过程，反复地从盘劫掠的文件，分析它们，清理数据，并一直持续到您的SQL数据库。
运行本身的第一node.js的过程，并让它运行，直到它收集或者1000个网页或15分钟（以先到者为准）来衡量你多少产量是最初能。在运行时，请记下计算机上的CPU利用率和网络利用率。如果您已经处于第一个node.js过程可能需要的位置，那么您已完成第一个node.js过程。如果你想让它变得更快，那么你需要弄清楚你的瓶颈在哪里。如果你是CPU绑定的（对于这个I/O任务不太可能），那么你可以对这些node.js进程进行集群和运行，为每个进程提供一组要获取的URL和一个单独的地方来编写他们收集的数据。很可能你是I/O绑定的。这可能是因为您没有完全饱和现有的网络连接（node.js流程花费太多时间等待I/O），或者您已经饱和了网络连接，现在它已成为瓶颈。你将不得不弄清楚它是哪一个。如果您添加更多同步网页抓取并且性能不会增加或甚至下降，那么您可能已经饱和了您的网络连接。您还需要注意node.js中的文件I/O子系统饱和，该文件使用限制线程池来实现异步I/O。
对于第二个node.js进程，您遵循类似的过程。给它1,000个网页，看看它可以多快处理它们。由于您确实有I/O读取磁盘文件并写入数据库，因此您一次需要解析多个页面，以便在读取或写入一个页面时最大限度地利用CPU出。您可以编写一个node.js进程来同时处理多个分析项目，也可以将一个node.js进程集群化。如果您的服务器中有多个CPU，那么您将希望至少拥有与CPU一样多的进程。与URL提取器进程不同，解析代码可能会被严格优化以加快速度。但是，像其他性能问题一样，不要试图过度优化代码，直到知道自己受CPU限制，并且它阻碍了你。
然后，如果你的SQL数据库可以在另一台电脑，或至少使用另一个磁盘，这可能是一件好事，因为它从您的其他磁盘写入那里分离出来的磁盘写入。
你在哪里最初几个步骤后去将完全取决于你的前几个步骤学习什么。衡量瓶颈所在的能力和设计快速实验以测试瓶颈理论的能力对于快速发展并且不会浪费开发时间来优化错误非常重要。
仅供参考，一些家庭互联网连接ISP可能掀起一番报警与你的数据请求的数量和速度。从一个ISP到另一个ISP，他们对这些信息的处理方式可能会有很大差异。我认为大多数人最终都有能力限制你的连接，以保护共享同一管道的其他人的服务质量，但我不知道他/她是否会这样做。
这听起来像是一个非常有趣的项目，试图优化和充分利用的。它将成为一个中等到高级软件课程的最终项目。
如果您使用的是node.js，那么您肯定会想要获得多个CPU，因此您可能需要对node.js进行集群或将解析和其他工作分载到子进程。在初始实施时，需要进行大量测量，以确定您的瓶颈在哪里，以及您在首次实施后应该改进哪些方向。这通常是事先不能完全预测的事情。做一些工作，测量，适应，再次测量，再次适应。你的绩效评估过程也同样重要。 – jfriend00