电竞比分网-中国电竞赛事及体育赛事平台

分享

Nodejs優(yōu)缺點,使用場景

 instl 2020-01-22

一. NodeJS的特點

我們先來看看NodeJS官網(wǎng)上的介紹:

Node.js is a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

其特點為:

  1. 它是一個Javascript運行環(huán)境

  2. 依賴于Chrome V8引擎進(jìn)行代碼解釋

  3. 事件驅(qū)動

  4. 非阻塞I/O

  5. 輕量、可伸縮,適于實時數(shù)據(jù)交互應(yīng)用

  6. 單進(jìn)程,單線程

二. NodeJS帶來的對系統(tǒng)瓶頸的解決方案

它的出現(xiàn)確實能為我們解決現(xiàn)實當(dāng)中系統(tǒng)瓶頸提供了新的思路和方案,下面我們看看它能解決什么問題。

  1. 并發(fā)連接

舉個例子,想象一個場景,我們在銀行排隊辦理業(yè)務(wù),我們看看下面兩個模型。

(1)系統(tǒng)線程模型:

系統(tǒng)線程模型

這種模型的問題顯而易見,服務(wù)端只有一個線程,并發(fā)請求(用戶)到達(dá)只能處理一個,其余的要先等待,這就是阻塞,正在享受服務(wù)的請求阻塞后面的請求了。

(2)多線程、線程池模型:

多線程、線程池模型

這個模型已經(jīng)比上一個有所進(jìn)步,它調(diào)節(jié)服務(wù)端線程的數(shù)量來提高對并發(fā)請求的接收和響應(yīng),但并發(fā)量高的時候,請求仍然需要等待,它有個更嚴(yán)重的問題。到代碼層面上來講,我們看看客戶端請求與服務(wù)端通訊的過程:

客戶端請求與服務(wù)端通訊的過程

服務(wù)端與客戶端每建立一個連接,都要為這個連接分配一套配套的資源,主要體現(xiàn)為系統(tǒng)內(nèi)存資源,以PHP為例,維護(hù)一個連接可能需要20M的內(nèi)存。這就是為什么一般并發(fā)量一大,就需要多開服務(wù)器。

那么NodeJS是怎么解決這個問題的呢?我們來看另外一個模型,想象一下我們在快餐店點餐吃飯的場景。

(3)異步、事件驅(qū)動模型

異步、事件驅(qū)動模型

我們同樣是要發(fā)起請求,等待服務(wù)器端響應(yīng);但是與銀行例子不同的是,這次我們點完餐后拿到了一個號碼,拿到號碼,我們往往會在位置上等待,而在我們后面的請求會繼續(xù)得到處理,同樣是拿了一個號碼然后到一旁等待,接待員能一直進(jìn)行處理。

等到飯菜做號了,會喊號碼,我們拿到了自己的飯菜,進(jìn)行后續(xù)的處理(吃飯)。這個喊號碼的動作在NodeJS中叫做回調(diào)(Callback),能在事件(燒菜,I/O)處理完成后繼續(xù)執(zhí)行后面的邏輯(吃飯),這體現(xiàn)了NodeJS的顯著特點,異步機制、事件驅(qū)動整個過程沒有阻塞新用戶的連接(點餐),也不需要維護(hù)已經(jīng)點餐的用戶與廚師的連接。

基于這樣的機制,理論上陸續(xù)有用戶請求連接,NodeJS都可以進(jìn)行響應(yīng),因此NodeJS能支持比Java、PHP程序更高的并發(fā)量雖然維護(hù)事件隊列也需要成本,再由于NodeJS是單線程,事件隊列越長,得到響應(yīng)的時間就越長,并發(fā)量上去還是會力不從心。

總結(jié)一下NodeJS是怎么解決并發(fā)連接這個問題的:更改連接到服務(wù)器的方式,每個連接發(fā)射(emit)一個在NodeJS引擎進(jìn)程中運行的事件(Event),放進(jìn)事件隊列當(dāng)中,而不是為每個連接生成一個新的OS線程(并為其分配一些配套內(nèi)存)。

  1. I/O阻塞

NodeJS解決的另外一個問題是I/O阻塞,看看這樣的業(yè)務(wù)場景:需要從多個數(shù)據(jù)源拉取數(shù)據(jù),然后進(jìn)行處理。

(1)串行獲取數(shù)據(jù),這是我們一般的解決方案,以PHP為例I/O阻塞-PHP為例

假如獲取profile和timeline操作各需要1S,那么串行獲取就需要2S。

(2)NodeJS非阻塞I/O,發(fā)射/監(jiān)聽事件來控制執(zhí)行過程

非I/O阻塞-PHP為例

NodeJS遇到I/O事件會創(chuàng)建一個線程去執(zhí)行,然后主線程會繼續(xù)往下執(zhí)行的,因此,拿profile的動作觸發(fā)一個I/O事件,馬上就會執(zhí)行拿timeline的動作,兩個動作并行執(zhí)行,假如各需要1S,那么總的時間也就是1S。它們的I/O操作執(zhí)行完成后,發(fā)射一個事件,profile和timeline,事件代理接收后繼續(xù)往下執(zhí)行后面的邏輯,這就是NodeJS非阻塞I/O的特點。

總結(jié)一下:Java、PHP也有辦法實現(xiàn)并行請求(子線程),但NodeJS通過回調(diào)函數(shù)(Callback)和異步機制會做得很自然。

三. NodeJS的優(yōu)缺點

優(yōu)點:1. 高并發(fā)(最重要的優(yōu)點)

  1. 適合I/O密集型應(yīng)用

缺點:1. 不適合CPU密集型應(yīng)用;CPU密集型應(yīng)用給Node帶來的挑戰(zhàn)主要是:由于JavaScript單線程的原因,如果有長時間運行的計算(比如大循環(huán)),將會導(dǎo)致CPU時間片不能釋放,使得后續(xù)I/O無法發(fā)起;

解決方案:分解大型運算任務(wù)為多個小任務(wù),使得運算能夠適時釋放,不阻塞I/O調(diào)用的發(fā)起;

  1. 只支持單核CPU,不能充分利用CPU

  2. 可靠性低,一旦代碼某個環(huán)節(jié)崩潰,整個系統(tǒng)都崩潰

原因:單進(jìn)程,單線程

解決方案:(1)Nnigx反向代理,負(fù)載均衡,開多個進(jìn)程,綁定多個端口;

(2)開多個進(jìn)程監(jiān)聽同一個端口,使用cluster模塊;

  1. 開源組件庫質(zhì)量參差不齊,更新快,向下不兼容

  2. Debug不方便,錯誤沒有stack trace

四. 適合NodeJS的場景

  1. RESTful API

這是NodeJS最理想的應(yīng)用場景,可以處理數(shù)萬條連接,本身沒有太多的邏輯,只需要請求API,組織數(shù)據(jù)進(jìn)行返回即可。它本質(zhì)上只是從某個數(shù)據(jù)庫中查找一些值并將它們組成一個響應(yīng)。由于響應(yīng)是少量文本,入站請求也是少量的文本,因此流量不高,一臺機器甚至也可以處理最繁忙的公司的API需求。

  1. 統(tǒng)一Web應(yīng)用的UI層

目前MVC的架構(gòu),在某種意義上來說,Web開發(fā)有兩個UI層,一個是在瀏覽器里面我們最終看到的,另一個在server端,負(fù)責(zé)生成和拼接頁面。

不討論這種架構(gòu)是好是壞,但是有另外一種實踐,面向服務(wù)的架構(gòu),更好的做前后端的依賴分離。如果所有的關(guān)鍵業(yè)務(wù)邏輯都封裝成REST調(diào)用,就意味著在上層只需要考慮如何用這些REST接口構(gòu)建具體的應(yīng)用。那些后端程序員們根本不操心具體數(shù)據(jù)是如何從一個頁面?zhèn)鬟f到另一個頁面的,他們也不用管用戶數(shù)據(jù)更新是通過Ajax異步獲取的還是通過刷新頁面。

  1. 大量Ajax請求的應(yīng)用

例如個性化應(yīng)用,每個用戶看到的頁面都不一樣,緩存失效,需要在頁面加載的時候發(fā)起Ajax請求,NodeJS能響應(yīng)大量的并發(fā)請求?! 】偠灾?,NodeJS適合運用在高并發(fā)、I/O密集、少量業(yè)務(wù)邏輯的場景。

五. 結(jié)尾

其實NodeJS能實現(xiàn)幾乎一切的應(yīng)用,我們考慮的點只是適不適合用它來做。

NodeJs的優(yōu)勢:現(xiàn)在的很多的服務(wù)器端的語言(PHP,JAVA,ASP.net),有什么問題呢,現(xiàn)在的服務(wù)器端的語言在用戶訪問服務(wù)器時,為每個用戶鏈接創(chuàng)建了一個線程,但每個線程大約要耗費2M的內(nèi)存,如果一個8G內(nèi)存的服務(wù)器,也就能鏈接4000個左右的用戶,如果用戶的鏈接數(shù)較大,就必須增加服務(wù)器的數(shù)量,而且現(xiàn)在用戶的鏈接方式有很多(如app,網(wǎng)頁同時訪問),這就又涉及到服務(wù)器共享的問題,所以服務(wù)器怎么支持最大的同時鏈接用戶量就成了一個問題;NodeJS修改了客戶端到服務(wù)器端的鏈接方法,解決了這個問題,他不在為每個客戶端創(chuàng)建一個新的線程,而是為每個客戶端鏈接出發(fā)一個NodeJs內(nèi)部進(jìn)行處理的事件,所以NodeJS具備同時處理多達(dá)幾萬個用戶的客戶端鏈接的能力;NodeJS適合開發(fā)的應(yīng)用程序:當(dāng)應(yīng)用程序需要處理大量并發(fā)的輸入/輸出,而在向客戶端發(fā)出響應(yīng)之前,應(yīng)用程序內(nèi)部并不需要進(jìn)行非常復(fù)雜的處理的時候,我們應(yīng)該考慮使用NodeJs來進(jìn)行應(yīng)用程序的開發(fā),例如:1、聊天服務(wù)器:如果聊天的人很多,用戶的與服務(wù)器之間的并發(fā)鏈接量很大,但是服務(wù)器端的數(shù)據(jù)處理并不復(fù)雜;2、綜合類服務(wù)網(wǎng)站和電子商務(wù)網(wǎng)站的服務(wù)器:在這類網(wǎng)站中的服務(wù)器端,往往可能每秒存內(nèi)可以接受多達(dá)上千條的數(shù)據(jù)并且需要將這些數(shù)據(jù)寫入數(shù)據(jù)庫中,NodeJs可以通過其隊列機制將這些數(shù)據(jù)迅速寫入緩存區(qū)中,然后再通過每一個單獨的處理從緩存區(qū)中取出這些數(shù)據(jù)并將其寫入數(shù)據(jù)庫中,如果是其他的服務(wù)器(如Apache服務(wù)器或Tomcat服務(wù)器)的話,由于這些服務(wù)器采用的是阻塞型I/O機制,因此每條數(shù)據(jù)寫入到數(shù)據(jù)庫中都要等待一段時間(等上一條寫完,才能寫下一條),但是NodeJs使用的是非阻塞的I/O機制,因此可以實現(xiàn)這些數(shù)據(jù)到數(shù)據(jù)庫中的寫入,而不必再為每條數(shù)據(jù)的寫入而等待一段時間

    本站是提供個人知識管理的網(wǎng)絡(luò)存儲空間,所有內(nèi)容均由用戶發(fā)布,不代表本站觀點。請注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購買等信息,謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點擊一鍵舉報。
    轉(zhuǎn)藏 分享 獻(xiàn)花(0

    0條評論

    發(fā)表

    請遵守用戶 評論公約

    類似文章 更多