為什么不要在nodejs中阻塞event loop

本篇內(nèi)容主要講解“為什么不要在nodejs中阻塞event loop”，感興趣的朋友不妨來看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“為什么不要在nodejs中阻塞event loop”吧!

簡(jiǎn)介

我們知道event loop是nodejs中事件處理的基礎(chǔ)，event loop中主要運(yùn)行的初始化和callback事件。除了event loop之外，nodejs中還有Worker Pool用來處理一些耗時(shí)的操作，比如I/O操作。

nodejs高效運(yùn)行的秘訣就是使用異步IO從而可以使用少量的線程來處理大量的客戶端請(qǐng)求。

而同時(shí)，因?yàn)槭褂昧松倭康木€程，所以我們?cè)诰帉憂odejs程序的時(shí)候，一定要特別小心。

event loop和worker pool

在nodejs中有兩種類型的線程。第一類線程就是Event Loop也可以被稱為主線程，第二類就是一個(gè)Worker Pool中的n個(gè)Workers線程。

如果這兩種線程執(zhí)行callback花費(fèi)了太多的時(shí)間，那么我們就可以認(rèn)為這兩個(gè)線程被阻塞了。

線程阻塞第一方面會(huì)影響程序的性能，因?yàn)槟承┚€程被阻塞，就會(huì)導(dǎo)致系統(tǒng)資源的占用。因?yàn)榭偟馁Y源是有限的，這樣就會(huì)導(dǎo)致處理其他業(yè)務(wù)的資源變少，從而影響程序的總體性能。

第二方面，如果經(jīng)常會(huì)有線程阻塞的情況，很有可能被惡意攻擊者發(fā)起DOS攻擊，導(dǎo)致正常業(yè)務(wù)無法進(jìn)行。

nodejs使用的是事件驅(qū)動(dòng)的框架，Event Loop主要用來處理為各種事件注冊(cè)的callback，同時(shí)也負(fù)責(zé)處理非阻塞的異步請(qǐng)求，比如網(wǎng)絡(luò)I/O。

而由libuv實(shí)現(xiàn)的Worker Pool主要對(duì)外暴露了提交task的API，從而用來處理一些比較昂貴的task任務(wù)。這些任務(wù)包括CPU密集性操作和一些阻塞型IO操作。

而nodejs本身就有很多模塊使用的是Worker Pool。

比如IO密集型操作：

DNS模塊中的dns.lookup(), dns.lookupService()。

和除了fs.FSWatcher()和 顯式同步的文件系統(tǒng)的API之外，其他多有的File system模塊都是使用的Worker Pool。

CPU密集型操作：

Crypto模塊：crypto.pbkdf2(), crypto.scrypt(), crypto.randomBytes(), crypto.randomFill(), crypto.generateKeyPair()。

Zlib模塊：除了顯示同步的API之外，其他的API都是用的是worker pool。

一般來說使用Worker Pool的模塊就是這些了，除此之外，你還可以使用nodejs的C++ add-on來自行提交任務(wù)到Worker Pool。

event loop和worker pool中的queue

在之前的文件中，我們講到了event loop中使用queue來存儲(chǔ)event的callback，實(shí)際上這種描述是不準(zhǔn)確的。

event loop實(shí)際上維護(hù)的是一個(gè)文件描述符集合。這些文件描述符使用的是操作系統(tǒng)內(nèi)核的 epoll (Linux), kqueue (OSX), event ports (Solaris), 或者 IOCP (Windows)來對(duì)事件進(jìn)行監(jiān)聽。

當(dāng)操作系統(tǒng)檢測(cè)到事件準(zhǔn)備好之后，event loop就會(huì)調(diào)用event所綁定的callback事件，最終執(zhí)行callback。

相反的，worker pool就真的是保存了要執(zhí)行的任務(wù)隊(duì)列，這些任務(wù)隊(duì)列中的任務(wù)由各個(gè)worker來執(zhí)行。當(dāng)執(zhí)行完畢之后，Woker將會(huì)通知Event Loop該任務(wù)已經(jīng)執(zhí)行完畢。

阻塞event loop

因?yàn)閚odejs中的線程有限，如果某個(gè)線程被阻塞，就可能會(huì)影響到整個(gè)應(yīng)用程序的執(zhí)行，所以我們?cè)诔绦蛟O(shè)計(jì)的過程中，一定要小心的考慮event loop和worker pool，避免阻塞他們。

event loop主要關(guān)注的是用戶的連接和響應(yīng)用戶的請(qǐng)求，如果event loop被阻塞，那么用戶的請(qǐng)求將會(huì)得不到及時(shí)響應(yīng)。

因?yàn)閑vent loop主要執(zhí)行的是callback，所以，我們的callback執(zhí)行時(shí)間一定要短。

event loop的時(shí)間復(fù)雜度

時(shí)間復(fù)雜度一般用在判斷一個(gè)算法的運(yùn)行速度上，這里我們也可以借助時(shí)間復(fù)雜度這個(gè)概念來分析一下event loop中的callback。

如果所有的callback中的時(shí)間復(fù)雜度都是一個(gè)常量的話，那么我們可以保證所有的callback都可以很公平的被執(zhí)行。

但是如果有些callback的時(shí)間復(fù)雜度是變化的，那么就需要我們仔細(xì)考慮了。

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

先看一個(gè)常量時(shí)間復(fù)雜度的情況，上面的例子中我們直接設(shè)置了respose的status，是一個(gè)常量時(shí)間操作。

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

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

  res.sendStatus(200);
});

上面的例子是一個(gè)O(n)的時(shí)間復(fù)雜度，根據(jù)request中傳入的n的不同，我們可以得到不同的執(zhí)行時(shí)間。

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

  // n^2 iterations before giving someone else a turn
  for (let i = 0; i < n; i++) {
    for (let j = 0; j < n; j++) {
      console.log(`Iter ${i}.${j}`);
    }
  }

  res.sendStatus(200);
});

上面的例子是一個(gè)O(n^2)的時(shí)間復(fù)雜度。

這種情況應(yīng)該怎么處理呢？首先我們需要估算出系統(tǒng)能夠承受的響應(yīng)極限值，并且設(shè)定用戶傳入的參數(shù)極限值，如果用戶傳入的數(shù)據(jù)太長(zhǎng)，超出了我們的處理范圍，則可以直接從用戶輸入端進(jìn)行限制，從而保證我們的程序的正常運(yùn)行。

Event Loop中不推薦使用的Node.js核心模塊

在nodejs中的核心模塊中，有一些方法是同步的阻塞API，使用起來開銷比較大，比如壓縮，加密，同步IO，子進(jìn)程等等。

這些API的目的是供我們?cè)赗EPL環(huán)境中使用的，我們不應(yīng)該直接在服務(wù)器端程序中使用他們。

有哪些不推薦在server端使用的API呢？

• Encryption: crypto.randomBytes (同步版本) crypto.randomFillSync crypto.pbkdf2Sync

• Compression: zlib.inflateSync zlib.deflateSync

• File system: 不要使用fs的同步API

• Child process: child_process.spawnSync child_process.execSync child_process.execFileSync

partitioning 或者 offloading

為了不阻塞event loop，同時(shí)給其他event一些運(yùn)行機(jī)會(huì)，我們實(shí)際上有兩種解決辦法，那就是partitioning和offloading。

partitioning就是分而治之，把一個(gè)長(zhǎng)的任務(wù)，分成幾塊，每次執(zhí)行一塊，同時(shí)給其他的event一些運(yùn)行時(shí)間，從而不再阻塞event loop。

舉個(gè)例子：

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

比如我們要計(jì)算n個(gè)數(shù)的平均數(shù)。上面的例子中我們的時(shí)間復(fù)雜度是O(n)。

function asyncAvg(n, avgCB) {
  // Save ongoing sum in JS closure.
  var sum = 0;
  function help(i, cb) {
    sum += i;
    if (i == n) {
      cb(sum);
      return;
    }

    // "Asynchronous recursion".
    // Schedule next operation asynchronously.
    setImmediate(help.bind(null, i+1, cb));
  }

  // Start the helper, with CB to call avgCB.
  help(1, function(sum){
      var avg = sum/n;
      avgCB(avg);
  });
}

asyncAvg(n, function(avg){
  console.log('avg of 1-n: ' + avg);
});

這里我們用到了setImmediate，將sum的任務(wù)分解成一步一步的。雖然asyncAvg需要執(zhí)行很多次，但是每一次的event loop都可以保證不被阻塞。

partitioning雖然邏輯簡(jiǎn)單，但是對(duì)于一些大型的計(jì)算任務(wù)來說，并不合適。并且partitioning本身還是運(yùn)行在event loop中的，它并沒有享受到多核系統(tǒng)帶來的優(yōu)勢(shì)。

這個(gè)時(shí)候我們就需要將任務(wù)offloading到worker Pool中。

使用Worker Pool有兩種方式，第一種就是使用nodejs自帶的Worker Pool，我們可以自行開發(fā)C++ addon或者node-webworker-threads。

第二種方式就是自行創(chuàng)建Worker Pool，我們可以使用Child Process 或者 Cluster來實(shí)現(xiàn)。

當(dāng)然offloading也有缺點(diǎn)，它的最大缺點(diǎn)就是和Event Loop的交互損失。

V8引擎的限制

nodejs是運(yùn)行在V8引擎上的，通常來說V8引擎已經(jīng)足夠優(yōu)秀足夠快了，但是還是存在兩個(gè)例外，那就是正則表達(dá)式和JSON操作。

REDOS正則表達(dá)式DOS攻擊

正則表達(dá)式有什么問題呢？正則表達(dá)式有一個(gè)悲觀回溯的問題。

什么是悲觀回溯呢？

我們舉個(gè)例子，假如大家對(duì)正則表達(dá)式已經(jīng)很熟悉了。

假如我們使用/^(x*)y$/ 來和字符串xxxxxxy來進(jìn)行匹配。

匹配之后第一個(gè)分組（也就是括號(hào)里面的匹配值）是xxxxxx。

如果我們把正則表達(dá)式改寫為 /^(x*)xy$/ 再來和字符串xxxxxxy來進(jìn)行匹配。 匹配的結(jié)果就是xxxxx。

這個(gè)過程是怎么樣的呢？

首先(x*)會(huì)盡可能的匹配更多的x，知道遇到字符y。 這時(shí)候(x*)已經(jīng)匹配了6個(gè)x。

接著正則表達(dá)式繼續(xù)執(zhí)行(x*)之后的xy，發(fā)現(xiàn)不能匹配，這時(shí)候(x*)需要從已經(jīng)匹配的6個(gè)x中，吐出一個(gè)x，然后重新執(zhí)行正則表達(dá)式中的xy，發(fā)現(xiàn)能夠匹配，正則表達(dá)式結(jié)束。

這個(gè)過程就是一個(gè)回溯的過程。

如果正則表達(dá)式寫的不好，那么就有可能會(huì)出現(xiàn)悲觀回溯。

還是上面的例子，但是這次我們用/^(x*)y$/ 來和字符串xxxxxx來進(jìn)行匹配。

按照上面的流程，我們知道正則表達(dá)式需要進(jìn)行6次回溯，最后匹配失敗。

考慮一些極端的情況，可能會(huì)導(dǎo)致回溯一個(gè)非常大的次數(shù)，從而導(dǎo)致CPU占用率飆升。

我們稱正則表達(dá)式的DOS攻擊為REDOS。

舉個(gè)nodejs中REDOS的例子：

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

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

  res.sendStatus(200);
});

上面的callback中，我們本意是想匹配 /a/b/c這樣的路徑。但是如果用戶輸入filePath=///.../\n，假如有100個(gè)/,最后跟著換行符。

那么將會(huì)導(dǎo)致正則表達(dá)式的悲觀回溯。因?yàn)?code>.表示的是匹配除換行符 \n 之外的任何單字符。但是我們只到最后才發(fā)現(xiàn)不能夠匹配，所以產(chǎn)生了REDOS攻擊。

如何避免REDOS攻擊呢？

一方面有一些現(xiàn)成的正則表達(dá)式模塊，我們可以直接使用，比如safe-regex，rxxr2和node-re2等。

一方面可以到www.regexlib.com網(wǎng)站上查找要使用的正則表達(dá)式規(guī)則，這些規(guī)則是經(jīng)過驗(yàn)證的，可以減少自己編寫正則表達(dá)式的失誤。

JSON DOS攻擊

通常我們會(huì)使用JSON.parse 和 JSON.stringify 這兩個(gè)JSON常用的操作，但是這兩個(gè)操作的時(shí)間是和輸入的JSON長(zhǎng)度相關(guān)的。

舉個(gè)例子：

var obj = { a: 1 };
var niter = 20;

var before, str, pos, res, took;

for (var i = 0; i < niter; i++) {
  obj = { obj1: obj, obj2: obj }; // Doubles in size each iter
}

before = process.hrtime();
str = JSON.stringify(obj);
took = process.hrtime(before);
console.log('JSON.stringify took ' + took);

before = process.hrtime();
pos = str.indexOf('nomatch');
took = process.hrtime(before);
console.log('Pure indexof took ' + took);

before = process.hrtime();
res = JSON.parse(str);
took = process.hrtime(before);
console.log('JSON.parse took ' + took);

上面的例子中我們對(duì)obj進(jìn)行解析操作，當(dāng)然這個(gè)obj比較簡(jiǎn)單，如果用戶傳入了一個(gè)超大的json文件，那么就會(huì)導(dǎo)致event loop的阻塞。

解決辦法就是限制用戶的輸入長(zhǎng)度?；蛘呤褂卯惒降腏SON API：比如JSONStream和Big-Friendly JSON。

阻塞Worker Pool

nodejs的理念就是用最小的線程來處理最大的客戶連接。上面我們也講過了要把復(fù)雜的操作放到Worker Pool中來借助線程池的優(yōu)勢(shì)來運(yùn)行。

但是線程池中的線程個(gè)數(shù)也是有限的。如果某一個(gè)線程執(zhí)行了一個(gè)long run task，那么就等于線程池中少了一個(gè)worker線程。

惡意攻擊者實(shí)際上是可以抓住系統(tǒng)的這個(gè)弱點(diǎn)，來實(shí)施DOS攻擊。

所以對(duì)Worker Pool中l(wèi)ong run task的最優(yōu)解決辦法就是partitioning。從而讓所有的任務(wù)都有平等的執(zhí)行機(jī)會(huì)。

當(dāng)然，如果你可以很清楚的區(qū)分short task和long run task，那么我們實(shí)際上可以分別構(gòu)造不同的worker Pool來分別為不同的task任務(wù)類型服務(wù)。

到此，相信大家對(duì)“為什么不要在nodejs中阻塞event loop”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！