Home PageArticleRepositoryAbout Me

不要阻塞事件循环（或者工作池）

avatarplhDigital nomad

你应该阅读这个指引？

若果你在写一些比一个简短的命令行脚本更复杂的，阅读这个应该能帮你写高效，安全的应用。 这个文章是为节点服务器编写的，但是这个概念通用复杂node app,

TL;DR

nodejs运行js核心在事件循环（初始化和回调），并且提供一个事件池子来处理昂贵的任务，像I/O。nodejs节点很好扩展，一些更好的像apache，Nodejs便于扩展的秘密是在于它使用少量的线程来处理许多客户端。如果ndoe能处理一些线程，那么它可以将更多的系统时间和内存花费在客户端上，线程的时间开销（内存，上下文切换）。但是因为node只有少量线程，你必须构建你的线程明智的使用他们。 下面是保持节点服务器速度的一个很好的经验法则：在任何给定时间与每个客户端关联的工作“很小”时，节点速度很快。 这适用于事件循环回调和工作池中的任务。

为什么我应该避免组设事件循环和他的事件池。

node用少量线程处理许多客户端，在nodejs这里有两类线程，一个是事件线程（主轮询，主线程。事件线程等待。。）和一个池。 如果一个线程持有长时间来执行回调（事件循环）或者一个任务（worker），我们叫他‘blocked’,当一个线程在客户端阻塞时候，他不能处理请求来自其他用户。这为事件轮询和工作池提供两个动机：

  • 1.性能：如果你认识到表现的太重，这个吞吐量对于你的服务器已经沦陷。
  • 2.保密：如果这可能，输入一个线程，他可能会阻塞，恶意用户可能会提交恶意提交。使你的线程阻塞，将他们保持在他们的其他客户端，这将会是一个防御措施。

一个node快速复查

node用事件驱动成就。它有一个用于协调的事件循环和一个用于昂贵任务的工作者池。

什么样的代码在事件循环中运行。

当循环开始的时候，node 应用第一次完成一个初始化阶段，正在require模块和注册回调事件，通过执行适当的回调来回应客户端请求。这个回调同步执行，并且也许会异步注册请求，来在他完成后继续处理。这个回调为了这些异步请求将会被执行在事件循环。

事件循环也将满足其回调（网络 I/O）发出的不阻塞异步请求

总之，这个事件循环为事件执行js回调注册，并且它也是为了满足不阻塞异步请求（网络I/O）的响应.

代码运行在事件池发生了什么。

node的工作池是在libuv实现的，这个其中公开了一般任务提交API。 node用事件池来处理昂贵的任务。这个包括了I/O为每一次系统操作，但不提供一个不阻塞版本，以及特别需要CPU密集型任务的I / O。

这有node模块API，这些使用事件池

  • 1.I/O集合
    • 1.DNS：dns.loopup(), dns.loopupService()
    • 2.文件系统：所有的我呢见系统API除了fs.FSWatcher()和这些明确同步的使用libuv线程池。
  • 2.CPU集合
    • 1.Crypto: crypto.pbkdf2(), crypto.randomBytes(), crypto.randomFill().
    • 2.Zlib: 所有的zlib除了这些显示同步的 APIs 以外，他们都是用libuv线程池。

在许多node应用，这些APIs是一个位移资源任务，为了线程池。应用和模块使用C++，所以可以提交其他任务到任务池。 为了完整性，我们提示这些，当你调用这中一个APIS来自一个回调的事件循环的时候，

Node是如何决定哪一段代码接下来运行。

抽象来说，事件循环，和事件池主要队列。

事实上，事件循环不是真实的住队列。相反，它有一个手机文件描述，它要求操作系统去描述。

这对应用设计意味着什么

在一个单线程每一个客户端系统，像Apache，每一个挂起的客户端都被分配了自己的线程。如果一个线程处理一个一个客户端阻塞，这个操作系统将要打断它并给另一个客户端一个回合。这个操作系统因此确认，客户端，需要一个小的工作。 因为node处理许多客户端线程，如果一个线程阻塞处理一个客户请求，

不要阻塞事件循环

这个事件循环警示每个客户端连接和编排，这意味着，如果事件循环花了太多，所有当前和新的客户端不会的到回应。 你也应该确认你永不阻塞事件循环，换一句话说，每个你js调用应该快速完成。当然这也应用了你等待。 一个好的方式去确认这是一个理由，关于这个计算复杂，关于回调，如果你调用的回调无论其参数如何都需要采取一定数量的步骤，如果你调用带了一些不一样的数字，部署，取决于他的参数，那么你应该思考，关于多久参数给到你， 例子1：一个恒定的回调。

app.get('/constant-time',(req,res)=>{
  res.sendStatus(200);
});

例子2：一个O(n)回调，这个回调将会快速运行，n小运行快，大n运行慢.

app.get('/countToN', (req, res) => {
  const n = req.query.n;

  // n iterations before giving someone else a turn
  for (let i = 0; i < n; i += 1) {
    console.log(`Iter ${i}`);
  }
  res.sendStatus(200);
});

例子3：为了一个2层嵌套O(n^2)回调。这个回调将会运行的更快，对于一个小n，但为一个大的n，他将会运行的更慢，相对于前一个O(n)....ps：这看起来不太可能。

app.get('/countToN2', (req, res) => {
  const n = req.query.n;
  // n iterations before giving someone else a turn
  console.time('cost time');
  for (let i = 0; i < n; i += 1) {
    for (let j = 0; j < n; j += 1) {
      console.log(`Iter ${i}.${j}`);
    }
  }
  console.timeEnd('cost time');
  res.sendStatus(200);
});

你应该如何小心？？？

node用google v8引擎来运行js，这对于很多一般操作，很快！但对于如下正则和JSON除外。下面讨论： 然而，对于复杂任务你应该考虑限制输入和拒绝太长的输入。这是应为，甚至你的回调有大的复杂的，，通过限制输入，你确保回调不能超过最长最快的情况。你可以评估坏损花费的回调，并且在不在你的接受范围内。

阻塞事件循环：REDOS

一般方式来阻塞事件循环。 避免脆弱的正则。 一个正则表达式匹配一个输入字符串。我们一般考虑正则匹配作为请求一个单一输入长度，许多情况，一个单一输入只需要一次。不幸的是，在许多情况下正则匹配需要的时间呈指数上升。这会阻塞事件循环。 一个容易受到攻击的正则匹配式。

  • 1.避免嵌套量词，node正则引擎能处理一些更快(a+)*。但也容易受到攻击，
  • 2.避免OR’s,像(a|a)*,重复，这有些时候很快，
  • 3.避免使用反向引用，
  • 4.如果你在做一个简单的字符串匹配，用indexOf，或者本地当量。这会更便宜，

如果你不确认是否使用正则表达式。

一个重复操作的例子： 这是一个例子，一个容易受到攻击的正则暴露他的服务器给重复操作：

app.get('/redos-me', (req, res) => {
  const filePath = req.query.filePath;

  // REDOS
  if (filePath.match(/(\/.+)+$/)) {
    console.log('valid path');
  } else {
    console.log('invalid path');
  }
  res.sendStatus(200);
});

这个脆弱的正则在这个例子是不好的，方式去检测一个地址是否合法，在linux系统里面。它匹配字符串用/做分割。这是危险的，因为它违反规则一，这是一个双重嵌套。 如果一个客户端请求参数是/////..../\n由100个/跟随，这个事件循环将会一直循环，阻塞事件循环。这个客户端的重复操作攻击会导致其他客户端也得不到服务器响应。 因为这个原因，你应该保持怀疑态度使用复杂的正则表达式。

反-重复操作 资源

这里有许多工具来检测正则是否安全，像

  • safe-regex
  • rxxr2.然而，不会捕获所有的容易受到攻击的正则匹配。 其他接近这个用的不同的正则引擎。你应该用node-re2模块。这个使用google的快速RE2正则表达式引擎。但要警告，这个检测不是100%兼容node正则，所以检测表达式，你用node-re2模块去处理正则，但是特别注意不是所有的正则都支持ndoe-re2. 如果你正在尝试匹配一些明白你的，像url匹配，或者地址匹配，那么用一些正则库吧，像ip-regex，

阻塞事件循环，ndoejs核心模块。

  • Encryption
  • Compression
  • File system
  • Child process

这些api很贵，因为他们设计大量计算，这些api用于脚本很方便，但是不适用于服务器上下文。如果你执行他们。在事件循环。他们会花费更多事件，更阻塞。 在服务器，你应该不用如下同步API

阻塞事件循环：JSON DOS

JSON.parse和JSON.stringify是其他潜在的昂贵操作。如果你的服务器操纵JSON对象，尤其是来自客户端的对象，应该谨慎处理，字符串大小。

复杂计算不阻塞事件循环。

支持你想要做复杂的计算，用js来做。而不阻塞事件驯化吗。你有两个选择，区分和卸载。

区分：

你因该，区分你的计算，这样，每个运行事件循环，快速运行，以便于不阻塞其他事件，在JavaScript这很容以来保存状态，在正在运行的任务，在闭包中，如下例子： 简单的例子，支持你想要计算平均数字，从1~n。 例子1：不区分平均值，花费O(n)

for (let i = 0;  i< n;i++){
  sum += il;
  let avg = sum / n;
  console.log('avg: '+ avg);
}

卸载

如果你需要做一些复杂的不好的事。这是因为区分只用事件循环。并且你将不得益于多个核心。记住，这个事件循环应该编排客户请求。将事件循环工作迁移至工作池。

如何卸载

你有两个选项

  • 你可以使用node工作池，通过发展C++.在老版本的node，建立你的c++，使用NAN，并且在新的版本使用N-API，node
  • 你可以创建和管理你的工作池，大多数直接了当的方式是使用子进程和聚。

你不应该简单为每个客户端创建子进程.你应该接受客户端请求更快，比你能够创建和管理子进程，并且你的服务器能创建和管理儿子，并且你服务器也能成为，

卸载的下行

卸载方法的缺点是它会以通信成本的形式招致开销。只有事件循环允许来见命名空间。来自己的应用。来自工作者，你不能操作一个js对象，在事件循环中的命名空间，相反，你有一个必须序列化和反序列化。所有

不要阻塞工作池

Node 有一个工作池，如果你有用卸载范例讨论如下，你也许有一个分离的计算工作池适用相同的原则。在另一个例子，让我们假设，k是一个更小的客户，你也许能同时处理，这是个保持node单线程的。

为了避免这个，你应该尝试小变量。在一系列任务来提交工作池，当这个接近，你应该知道I/O请求的相对成本。并避免提交你期望的请求。 这两个例子应该说明任务时间可能的变化。 变体示例：长时间运行的文件系统读取 支持你的系统必须读取文件，为了处理一些客户请求。在咨询后，node的文件系统API，你选择使用fs.readFile()，为了简化。然而fs.readFile()是当前的，不区分，它提交单一的fs.read()任务跨越。如果你阅读短文件，为一些用户，并且长文件为其他的，fs.readFile()也能介绍信号变量在任务长度，来损害时间池吞吐量。 为一些坏脚本，支持一些攻击，方便你的服务器读取一些随意的文件，

©Copyright2017-2023plh-blog.netlify.app