站長資訊網
最全最豐富的資訊網站

聊聊Node中的異步實現與事件驅動

本篇文章帶大家了解一下Node中的異步實現與事件驅動,希望對大家有所幫助!

聊聊Node中的異步實現與事件驅動

node.js極速入門課程:進入學習

Node的特點

計算機中的一些任務一般可以劃分為兩個類別,一個類別叫做IO密集型,一個叫做計算密集型;對于計算密集型的任務,只能不斷榨干CPU的性能,但是對于IO密集型的任務來說,理想情況下卻并不需要,只需要通知IO設備進行處理,過一段時間再來拿去數據就好了。【相關教程推薦:nodejs視頻教程 、編程視頻】

對于某些場景有一些互不相關的任務需要完成,現行的主流方法有如下兩種:

  • 多線程并行完成:多線程的代價在于創建線程和執行線程上下文切換的開銷較大。另外,在復雜的業務中,多線程編程經常面臨鎖、狀態同步等問題;
  • 單線程順序執行:易于表達,但串行執行的缺點在于性能,任意一個略慢的任務都會導致后續代碼被組設

node在兩者之前給出了它的方案:利用單線程,遠離多線程死鎖、狀態同步等問題;利用異步IO,讓單線程遠離阻塞,以更好地使用CPU

聊聊Node中的異步實現與事件驅動

Node是如何實現異步的

剛才講了node在多任務處理的方案,但是node內部想要實現卻并不容易,下面介紹操作系統的幾個概念,方面后續大家更好理解,后面再講一講異步的實現以及node的事件循環機制:

阻塞IO與非阻塞IO

  • 阻塞IO:應用層面發起IO調用之后,就一直等待數據,等操作系統內核層面完成所有操作后,調用才結束;

操作系統中一切皆文件,輸入輸出設備同樣被抽象為了文件,內核在執行IO操作時,通過文件描述符進行管理

  • 非阻塞IO:差別為調用后立即返回一個文件描述符,并不等待,這時候CPU的時間片就可以用來處理其他事務,之后可以通過這個文件描述符進行結果的獲取;

非阻塞IO存在的一些問題:雖然其讓CPU的利用率提高了,但是由于立即返回的是一個文件描述符,我們并不知道IO操作什么時候完成,為了確認狀態變更,我們只能作輪詢操作

不同的輪詢方法

  • read :最原始、性能最低的一種,通過重復檢查IO狀態來完成完整數據的獲取
  • select:通過對文件描述符上的事件狀態來進行判斷,相對來說消耗更少;缺點就是它采用了一個1024長度的數組來存儲狀態,所以它最多可以同時檢查1024個文件描述符
  • poll:由于select的限制,poll改進為鏈表的存儲方式,其他的基本都一致;但是當文件描述符較多的時候,它的性能還是非常低下的
  • eopll:該方案是linux下效率最高的IO事件通知機制,在進入輪詢的時候如果沒有檢查IO事件,將會進行休眠,直到事件發生將它喚醒
  • kqueue:與epoll類似,不過僅在FreeBSD系統下存在

盡管epoll利用了事件來降低對CPU的耗用,但休眠期間CPU幾乎是閑置的;我們期待的異步IO應該是應用程序發起非阻塞調用,無須通過遍歷或事件喚醒等方式輪詢,可以直接處理下一個任務,只需IO完成后通過信號或者回調將數據傳遞給應用程序即可。

linux下還有中AIO方式就是通過信號或回調來傳遞數據的,不過只有Linux有,并且有限制無法利用系統緩存

node中對于異步IO的實現

先說結論,node對異步IO的實現是通過多線程實現的。可能會混淆的地方就是node內部雖然是多線程的,但是我們程序員開發的JavaScript代碼卻僅僅是運行在單線程上的。

node通過部分線程進行阻塞IO或者非阻塞IO加上輪詢技術來完成數據獲取,讓一個線程進行計算處理,通過線程之間的通信將IO得到的數據進行傳遞,這就輕松實現了異步IO的模擬。

聊聊Node中的異步實現與事件驅動

除了異步IO,計算機中的其他資源也適用,因為linux中一切皆文件,磁盤、硬件、套接字等幾乎所有計算機資源都被抽象為了文件,接下來介紹對計算機資源的調用都以IO為例子。

事件循環

在進程啟動時,node便會創建一個類似與while(true)的循環,每執行一次循環體的過程我們成為Tick

下方為node中事件循環流程圖:

聊聊Node中的異步實現與事件驅動

很簡單的一張圖,簡單解釋一下:就是每次都從IO觀察者里面獲取執行完成的事件(是個請求對象,簡單理解就是包含了請求中產生的一些數據),然后沒有回調函數的話就繼續取出下一個事件(請求對象),有回調就執行回調函數

異步IO細節

聊聊Node中的異步實現與事件驅動

注:不同平臺有不同的細節實現,這張圖隱藏了相關平臺兼容細節,比如windows下使用IOCP中的PostQueuedCompletionStatus()提交執行狀態,通過GetQueuedCompletionStatus獲取執行完成的請求,并且IOCP內部實現了線程池的細節,而linux等平臺通過eopll實現這個過程,并在libuv下自實現了線程池

setTimtoutsetInterval

除了IO等計算機資源需要異步調用之外,node本身還存在一些與異步IO無關的一些其他異步API

  • setTimeout
  • setInterval
  • setImmediate
  • process.nextTick

該小節先講解前面兩個api

它們的實現原理與異步IO比較類似,只是不需要IO線程池的參與

  • setTimtoutsetInterval創建的定時器會被插入到定時器觀察者內部的一個紅黑樹中
  • 每次tick執行的時候,會從該紅黑樹中迭代取出定時器對象,檢查是否超過定時時間
  • 如果超過,就將這個事件(請求對象)推入到事件隊列中,在事件循環中執行其中的回調函數

紅黑樹:這里簡單提一下,就是一種特殊化的平衡二叉樹,可以自平衡,查找效率基本上就是該二叉樹的深度了

O(log2n)O(log_2n)

你有考慮過這個問題嗎,為什么定時器不需要線程池的參與了呢,如果你理解了之前章節對于異步IO實現原理的話,相信你應該能解釋出來,這里簡單說說原因來加深記憶:

node中的IO線程池是用來調用IO并等待數據返回(看具體實現)的一種方式,它使JavaScript單線程得以異步調用IO,并且不需要等待IO執行完成(因為是IO線程池做了),并且能獲取到最終的數據(通過觀察者模式:IO觀察者從線程池獲取執行完成的事件,事件循環機制執行后續的回調函數)

上述這段話可能有點簡略,如果你還不明白,可以看下之前的那幾種圖~

process.nextTicksetImmediate

這兩個函數都是代表立即異步執行一個函數,那為什么不用setTimeout(() => { ... }, 0)來完成呢?

  • 定時器精度不夠
  • 定時器使用紅黑樹來創建定時器對象和迭代操作,浪費性能
  • process.nextTick更加輕量

輕量具體來說:我們在每次調用process.nextTick的時候,只會將回調函數放入隊列中,在下一輪Tick時取出執行。定時器中采用紅黑樹的方式時

O(log2n)O(log_2n)

nextTick

O(1)O(1)

process.nextTicksetImmediate又有什么區別呢?畢竟它們都是將回調函數立即異步執行

  • process.nextTick的回調執行優先級高于setImmediate
  • process.nextTick的回調函數保存在一個數組中,每輪事件循環下全部執行,setImmediate的結果則是保存在鏈表中,每輪循環按序執行第一個回調

注意:之所以process.nextTick的回調執行優先級高于setImmediate,因為事件循環對觀察者的檢查是有順序的,process.nextTick屬于idle觀察者,setImmediate屬于check觀察者。iedl觀察者 > IO 觀察者 > check觀察者

高性能服務器

對于網絡套接字的處理,node也應用到了異步IO,網絡套接字上偵聽到的請求都會形成事件交給IO觀察者,事件循環會不停地處理這些網絡IO事件,如果我們在JavaScrpt層面上有傳入對應的回調函數,這些回調函數就會在事件循環中執行(處理這些網絡請求)

常見的服務器模型:

  • 同步式
  • 每進程–>每請求
  • 每線程–>每請求

node采用的是事件驅動的方式處理這些請求,無需對每個請求創建額外的對應線程,可以省略掉創建線程和銷毀線程的開銷,同時操作系統的調度任務因為線程較少(只有node內部實現的一些線程)上下文切換的代價很低。

經典問題–雪崩問題的解決:

問題描述:服務器在剛啟動時,緩存無數據,如果訪問量巨大,同一條SQL會被發送到數據庫中反復查詢,影響性能。

解決方案:

const proxy = new events.EventEmitter(); let status = "ready"; // 狀態鎖,避免反復查詢  const select = function(callback) {     proxy.once("selected", callback);  // 綁定一個只執行一次名為selected的事件     if(status === "ready") {         status = "pending";         // sql         db.select("SQL", (res) => {             proxy.emit("selected", res); // 觸發事件,返回查詢數據             status = "ready";         })     } }
登錄后復制

使用once將所有請求的回調都壓入了事件隊列中,利用其只執行一次就會將監視器移除的特點,保證每一個回調函數只會被執行一次。對于相同的SQL語句,保證在同一個查詢開始到結束的過程中永遠只有一次。新到來的相同調用只需在隊列中等待數據就緒即可,一旦查詢到結果,得到的結果就可以被這些調用共同使用。

贊(0)
分享到: 更多 (0)
網站地圖   滬ICP備18035694號-2    滬公網安備31011702889846號
国产成人精品久久一区二区三区| 精品少妇一区二区三区在线| 国产精品香蕉在线| 午夜精品视频在线观看| 中文字幕日韩精品无码内射| 尤物国精品午夜福利视频| 日韩av在线播放| 国产精品成人自拍| 精品国产乱码久久久久久郑州公司| 精品9E精品视频在线观看| 漂亮人妻被黑人久久精品| 麻豆精品久久久一区二区| 97国产精品视频| 久久精品无码专区免费| 精品少妇人妻av无码专区| 日韩一区精品视频一区二区| 国产亚洲精品精品精品| 国产精品林美惠子在线播放| 欧美日韩久久久精品A片| 国内精品自线在拍2020不卡| 亚洲精品国产精品国自产网站| 精品一区二区三区无码免费视频| 久久99精品久久久久久久野外| 奇米精品一区二区三区在线观看 | 国产精品久久久久国产A级| 国产一区二区精品尤物| 精品久久久久久久久久中文字幕 | 国产精品久久久久三级| 国产精品青草久久| 日韩精品一区二区三区中文3d | 午夜国产精品免费观看| 亚洲精品中文字幕无乱码麻豆| 亚洲精品在线播放视频| 2021精品国产品免费观看| 91情国产l精品国产亚洲区| 182tv精品视频在线播放| 亚洲欧洲国产经精品香蕉网| 亚洲午夜国产精品无卡| 99久热任我爽精品视频| 亚洲国产精品无码久久九九大片| 中文字幕乱码亚洲精品一区|