dubbo系列--dubbo線程模型

在netty中的兩種線程：boss線程、work線程

1 boss線程

做用：

• accept客戶端的鏈接

• 將接收到的鏈接註冊到一個worker線程上

個數：

一般狀況下，服務端每綁定一個端口，開啓一個boss線程

2 worker線程

做用：

處理註冊在其身上的鏈接connection上的各類io事件

個數：

默認是：核數+1

注意：

• 一個worker線程能夠註冊多個connection

• 一個connection只能註冊在一個worker線程上

dubbo的事件派發策略和線程池

一、dubbo基於netty。有5種派發策略：

• all：（默認），全部消息都派發到線程池，包括請求，響應，鏈接事件，斷開事件，心跳等。 即worker線程接收到事件後，將該事件提交到業務線程池中，本身再去處理其餘事。

• direct：worker線程接收到事件後，由worker執行到底。

• message：只有請求響應消息派發到線程池，其它鏈接斷開事件，心跳等消息，直接在 IO線程上執行

• execution：只請求消息派發到線程池，不含響應（客戶端線程池），響應和其它鏈接斷開事件，心跳等消息，直接在 IO 線程上執行

• connection：在 IO 線程上，將鏈接斷開事件放入隊列，有序逐個執行，其它消息派發到線程池。

• 
  

二、業務線程池：

• fixed：固定大小線程池，啓動時創建線程，不關閉，一直持有。(默認)

  • coresize：200

  • maxsize：200

  • 隊列：SynchronousQueue

  • 回絕策略：AbortPolicyWithReport - 打印線程信息jstack，以後拋出異常

• 
   

• cached：緩存線程池，空閒一分鐘自動刪除，須要時重建。

•  

• 
  

• limited：可伸縮線程池，但池中的線程數只會增加不會收縮。只增加不收縮的目的是爲了不收縮時忽然來了大流量引發的性能問題。

• 
  

服務端

兩種線程池：

• io線程池：netty的boss和worker線程池。

  • boss：創建connection

  • worker：處理註冊在其身上的鏈接connection上的各類io事件

• 業務線程池：

• fixedThreadPool()：「DubboServerHandler-10.10.10.11:20880」

• 見「 dubbo的事件派發策略和線程池」

  • 與worker配合處理各類請求

 

客戶端

兩種線程池：

• io線程池：netty的boss和worker線程池

  • 同上

• 業務線程池：

• cachedThreadPool：「DubboClientHandler-10.10.10.10:20880」

  • 與worker配合處理各類響應，最後獲得響應後喚醒被阻塞的主線程

dubbo線程模型圖

總體步驟：（受限於派發策略，以默認的all爲例, 以netty4爲例）

1. 客戶端的主線程發出一個請求後得到future，在執行get時進行阻塞等待；

2. 服務端使用worker線程（netty通訊模型）接收到請求後，將請求提交到server線程池中進行處理

3. server線程處理完成以後，將相應結果返回給客戶端的worker線程池（netty通訊模型），最後，worker線程將響應結果提交到client線程池進行處理

4. client線程將響應結果填充到future中，而後喚醒等待的主線程，主線程獲取結果，返回給客戶端