Netty源碼分析--Reactor模型（二）

      這一節和我一塊兒開始正式的去研究Netty源碼。在研究以前，我想先介紹一下Reactor模型。

      我先分享兩篇文獻，你們能夠自行下載學習。  連接：https://pan.baidu.com/s/1Utym7AS8DHCxrh5aNOD2Ew  提取碼：18u3 

      下面主要是對文獻中一些內容和重要的圖片進行說明：

      一、Each handler may be started in its own thread， 這種方式在客戶端負載增長的時候，有很嚴重的性能問題。

      

         

•       serversocket的accept方法，阻塞等待client鏈接，直到client鏈接成功。
•       線程從socket inputstream  outputstream讀寫數據，會進入阻塞狀態，直到所有數據讀寫完。
•       即便沒有數據的讀寫，仍然會佔用一個線程，浪費資源。

    二、對上面的模型進行優化， 採用事件驅動的模式，有事件發生的時候纔會觸發：

          

       Reactor爲單個線程，既要處理客戶端的accept事件，又要負責發送請求處處理器中。因爲只有單個線程，因此處理器中的業務須要可以快速處理完。

    三、再次進行改進，加入線程池

       

         這樣Reactor線程處理完鏈接以後，將請求放在線程池中進行處理，不會受到Handler的阻塞。

        四、使用多個Reactor

        

       mainReactor負責監聽鏈接，accept鏈接給subReactor處理，爲何要單獨分一個Reactor來處理監聽呢？由於像TCP這樣須要通過3次握手才能創建鏈接，這個創建鏈接的過程也是要耗時間和資源的，單獨分一個Reactor來處理，能夠提升性能。mainReactor僅僅只負責處理客戶端鏈接，subReactor負責後面的數據的讀寫。

      在解決了什麼是Reactor模式後，咱們來看看Reactor模式是由什麼模塊構成。圖是一種比較簡潔形象的表現方式，於是先上一張圖來表達各個模塊的名稱和他們之間的關係：

      

           上面的圖由五大角色構成，下面進行解釋：

•  Handle(句柄或描述符)：本質上是一種資源，由操做系統提供的，該資源用於表示一個個的事件，好比說文件描述符，或是針對網絡編程中的Socket描述符，事件既能夠來自於外部，又能夠來自於內部，外部事件好比客戶端的鏈接請求，客戶端數據的讀寫等等；內部事件好比操做系統產生的定時器事件，它本質上就是一個文件描述符。簡單來講，Handle就是事件產生的發源地。
• Synchronous Event Demultiplexer（同步事件分離器）：它自己是一個系統調用，用於等待事件的發生（一個或多個）。調用方在調用它的時候會一直阻塞，一直阻塞到同步分離器上有事件產生，對於Linux來講，同步事件分離器指的就是經常使用的I/O多路複用器，好比說select、poll、epoll等，在Java NIO 領域中，同步事件分離器的組件就是Selector； 對應的阻塞方法就是select()
• Event Hander （事件處理器）：自己由多個回調方法組成，這些回調方法構成了於應用相關的對於某個事件的反饋機制，Netty相比於Java的NIO來講，在事件處理器的這個角色上進行了一個升級，它爲咱們開發者指定了大量的回調方法，供咱們在特定時間產生的時候實現相應的回調方法進行業務邏輯的處理。
• Concrete Event Handler（具體事件處理器）：是事件處理器的時間，本質上是咱們所編寫的一個個的處理器的實現
• Initiation Dispatcher （初始分發器）：實際上就是Reactor的角色，它自己定義了一些規範，這些規範用戶控制事件的調度方式，同時又提供了應用事件處理器的註冊、刪除等設施，它自己是整個事件處理器的核心所在，會經過同步事件分離器來等待事件的發生，一旦事件發生，首先會分離出一個事件，而後調用事件處理器，最後調用相關的回調方法來處理這些事件。