dubbo底層之Netty

背景

1. Java線程：由開始的單線程，到經過new Thread()建立的多線程，再到現現在的線程池，Java多線程編程的效率和性能有了很大的提高
2. Reactor模型：基於事件驅動，適合處理海量I/O事件

　　　　1）  單線程模型，全部的IO操做都在一個NIO線程上完成

　　　　存在性能和可靠性上的問題

　　　　2）  多線程模型，有一組NIO線程處理IO操做

　　　　有一個專門的NIO線程-Acceptor線程用於監聽服務端，接收客戶端的TCP鏈接請求；

　　　　有一個NIO線程池，負責消息的讀取、發送、編碼、解碼；

　　　　一個NIO線程能負責N條鏈路，一條鏈路只能由一個線程負責（防止發生併發操做問題）

　　　　3）  主從多線程模型

　　　　添加主線程池用於處理客戶端的鏈接請求，一旦鏈路創建成功（通過握手、認證等過程），就將鏈路註冊到從線程池的IO線程上，由IO線程負責後續的IO操做

Netty線程模型

　　1.線程模型分類

　　　　1）  服務端線程模型，相似於Reactor的多線程模型

　　　　2）  客戶端線程模型：由客戶端建立SocketChannel，發起鏈接，線程池判斷鏈接結果，若是鏈接成功，則監聽讀操做位，不然監聽鏈接操做位，一旦鏈接成功就監聽讀操做位

　　2.Reactor線程NioEventLoop

　　　　1）  做爲服務端Acceptor線程，處理客戶端的鏈接請求

　　　　2）  做爲客戶端的connector，註冊監聽鏈接操做位，判斷異步鏈接結果

　　　　3）  做爲IO線程，監聽讀操做位，負責從SorcketChannel中讀取報文

　　　　4）  做爲IO線程，監聽寫操做位，負責向SocketChannel寫入報文發送給對方

　　　　5）  做爲定時線程，執行定時任務（鏈路空閒檢測，心跳檢測）

　　　　6）  做爲線程執行器，能夠執行普通的任務線程

　　3.NioEventLoop設計原理

　　　　1）  串行化設計理念：NioEventLoop線程池中有若干個NioEventLoop線程，每個NioEventLoop線程串行執行Handler鏈；每當有一個客戶端接入，從線程池中獲取一個可用的NioEventLoop線程，當數組到達上限以後，從0開始（負載均衡）；每一個客戶端鏈接一個線程，這樣保證了數據的安全性（避免多個線程同時訪問）

　　　　2）  定時任務和時間輪算法：客戶端鏈接超時，鏈路空閒檢測

　　　　Netty的定時任務調度就是基於時間輪調度算法，首先查看任務隊列中是否有超時的定時任務或者普通任務，有則執行（按照時間片原則分配運行時間），沒有就等待定時任務中延遲最小的任務（即即將第一個超時的任務）的延遲時間，而後將掃描定時任務，將超時的定時任務加入任務隊列，在任務執行時，Netty每執行64個定時任務就檢測一次是否達到執行時間上限，達到則退出，若是沒有執行完就放到下次輪詢時再處理。

　　　　3）  Netty是個異步高性能NIO框架，不是業務處理容器，不須要也不該該提供業務容器和業務線程，，只須要提供和管理NIO線程，關於業務層模型由用戶本身集成。

Netty結構

 

PS：圖中有一點修正一下，SocketChannel是創建在客戶端與服務端之間的，EventLoopGroup線程池中的一個線程與SocketChannel綁定，在服務端後續的線程處理以前，須要從SocketChannel中讀取參數，在處理以後，須要向SocketChannel中寫入處理結果。

Dubbo通訊層（利用Netty）的實現過程