1. 程式人生 > >NIO中的易筋經

NIO中的易筋經

負責 如果 系統 電腦下載 開始 無法 謝謝 可能 相關

匠心零度 轉載請註明原創出處,謝謝!

前言

技術分享圖片

《易筋經》。天下武功出少林,而易筋經是少林寺的鎮寺之寶。學好了易筋經就可以輕易地學好其它武功,只不過很少人學到了它的全部精髓。遊坦之只是碰巧學了一點點就變成了武林高手,從中可以看出易筋經的威力的確很大。

之前已經寫過三篇NIO文章,NIO相關基礎篇一、NIO相關基礎篇二、NIO相關基礎篇三,今天我們來提下NIO中的易筋經Reactor模型

說明

不會說故事的程序員不是好廚子,下面就來聽聽故事吧。

故事改編與網絡。

以A地公眾號:匠心零度菜館為例,以客人就餐為例。
我們服務對象以桌(一桌>=1)為最小單位

故事一:

公眾號:匠心零度

菜館剛剛成立,客人還不是特別多的時候。
來一桌客人就餐,一個服務員去服務,然後客人會看菜單,點菜。 服務員將菜單給後廚。
來二桌客人就餐,二個服務員去服務……
……
來五桌客人就餐,五個服務員去服務……

公眾號:匠心零度菜館越來越忙,人越來越多,零度老板開始著急了:
缺乏彈性伸縮能力,當顧客越來越多,並行增加之後,服務員與顧客人數關系1:1關系。
現在人員太貴,再請人就攢不到錢了,當顧客到達一定之後零度就承擔不了聘用那麽的工作人員了,要不然公眾號:匠心零度菜館會垮掉了。

零度思來想去:
算了下成本,零度決定只聘用十個服務員。
這樣當顧客越來越多,並行增加之後,服務員與顧客人數關系10:N(N大於等於10)關系。

這樣公眾號:匠心零度菜館也不會因為聘用人員太多而承擔不起。

那麽又有什麽問題呢? 如果某桌客人點菜非常慢,導致有些桌客人會一直等很久,當體驗不好的時候可能
有些桌的可以立馬走了,有些桌的客人以後不來了。

雖然錢省下來了,但是也沒有掙到,零度又開始想辦法了,看看下面的故事二吧。

故事二:

哈哈哈哈,零度之前是幹編程的,知道很多事情需要拆拆拆(特別在中國要是拆房子,那不得了啊,發啦!!!)
上面的事情由於所有的事情都是一個服務器從頭負責到尾,而有很多時候,顧客在交流討論的時候,服務員其實
沒啥事情幹的,就在那裏等著(能不能讓等的時候去做其他事情呢,充分利用起來呢???)。

零度思來想去:
終於發現了一個新的方法,那就是:

當客人點菜的時候,服務員就可以去招呼其他客人了,等客人點好了菜,直接招呼一聲"服務員",
馬上就有個服務員過去服務。之後零度進行了一次裁員,只留了一個服務員!
這樣公眾號:匠心零度菜館生意越來越好,又出現了二個問題:
就算該服務員在怎麽忙,也無法應對成百上千桌的客人了。
一個服務員如果請假或者有事情怎麽辦?(經常說服務不要出現單點,這樣也一樣啊!!!)
雖然錢省下來了,但是該掙的錢沒有掙到,零度又開始想辦法了,看看下面的故事三吧。

故事三:

零度決定公眾號:匠心零度菜館再聘二名服務員,現在有三名服務員了,零度給他們劃分是
一個負責填寫各各桌的菜單,另外二名負責端菜(上菜的忙些),接下來的生意都很好,也忙的過來,請假了,另外二個相互配合下
臨時處理也來得及,由於這樣,生意越來越好,有一次被不三不四的人進來了,搞的公眾號:匠心零度菜館事情很大。
如果服務員還要檢查人員,那麽又忙不開了。
零度又開始思考了,看看下面的故事四吧。

故事四:

零度聘了一個保安,需要檢查下是否為不三不四人員,如果不是,把他交給服務員讓服務員帶入,之後服務員帶入
繼續由客人直接招呼一聲"服務員"點菜好了,之後由其他服務員端菜……生意很好。

已經到了一個公眾號:匠心零度菜館忙不過來了 (到達上限了,那麽要擴了,開分店……)

故事N:

零度,反正以前幹編程的,自己開發了一個app,客人過來之前就已經網上下單,零度專門找了一個人負責這塊,當app有
新訂單的時候會有聲音提醒,那個負責人告訴後廚,這樣當沒有提醒的時候,該負責人可以去幫忙照顧店裏的客人……
編不下去了…………

Reactor模型介紹

本文最重要的參考文獻是Doug Lea大神的"Scalable IO in Java”,搜索公眾號【匠心零度】或者掃描最下方二維碼進行關註,回復:nio ,獲取該資料,建議電腦下載,下文中的截圖也是截取自中。

傳統的BIO編程、偽異步I/O編程

技術分享圖片

BIO主要的問題在於每當有一個新的客戶端請求接入時,服務端必須創建一個新的線程來處理這條鏈路,在需要滿足高性能、高並發的場景是沒法應用的(大量創建新的線程會嚴重影響服務器性能,使用線程池也是存在問題,如果發生大量並發請求,超過最大數量的線程就只能等待,會一直阻塞)

單線程模型

技術分享圖片

單線程模型會存在如果鏈接太多,性能可能無法滿足,而且如果nio線程出現意外啥的會影響這個系統不可用。

多線程模型

技術分享圖片

多線程模型一般場景都滿足了,但是在特別高的並發,以及一些非常消耗性能的驗證等,會存在一些不足之處。

主從多線程模型

技術分享圖片

主從多線程模型,通過mainReactor線程、subReactor線程繼續拆分,mainReactor線程負責一些客戶端TCP連接請求預處理(驗證等),subReactor線程處理真正的IO。

參考:
http://daimojingdeyu.iteye.com/blog/828696

結束語

本人水平有限,難免會有一些理解偏差的地方,如果發現,歡迎各位積極指出,感謝!!!


如果讀完覺得有收獲的話,歡迎點贊、關註、加公眾號【匠心零度】,查閱更多精彩歷史!!!
技術分享圖片

NIO中的易筋經