Dubbo的執行緒模型

Dubbo的 protocol標籤提供了三個引數 dispatcher,threads(預設為100)
和 threadpool來為我們自定義DUBBO協議下的執行緒模型，其中dubbo自定義了5個執行緒dispatcher：

Dispatcher 

all 所有訊息都派發到執行緒池，包括請求，響應，連線事件，斷開事件，心跳等。
direct 所有訊息都不派發到執行緒池，全部在Io執行緒上直接執行
message 只有請求響應訊息派發到執行緒池，其他連線斷開事件，心跳等訊息，直接在Io執行緒上執行。
execution 只請求訊息派發到執行緒池，不含響應和其他連線斷開事件，心跳等訊息，直接在Io執行緒上執行。
connection 在Io執行緒上，將連線斷開事件放入隊裡，有序 逐個執行，其他訊息派發到執行緒池。

以及四個常用的threadpool ：: 

fixed 固定大小執行緒池，啟動時建立執行緒，不關閉，一直持有。(預設)
cached 快取執行緒池，空閒一分鐘自動刪除，需要時重建。
limited 可伸縮執行緒池，但池中的執行緒數只會增長不會收縮。只增長不收縮的目的是為了避免收縮時突然來了大流量引起的效能問題。
eager 優先建立Worker執行緒池。在任務數量大於corePoolSize但是小於maximumPoolSize時，優先建立Worker來處理任務。當任務數量大於maximumPoolSize時，將任務放入阻塞佇列中。阻塞佇列充滿時丟擲RejectedExecutionException。(相比於cached:cached在任務數量超過maximumPoolSize時直接丟擲異常而不是將任務放入阻塞佇列)

DUBBO 官方文件給出的建議：
1：如果事件處理的邏輯能迅速完成，並且不會發起新的 IO 請求，比如只是在記憶體中記個標識，則直接在 IO 執行緒上處理更快，因為減少了執行緒池排程。:

2：但如果事件處理邏輯較慢，或者需要發起新的 IO 請求，比如需要查詢資料庫，則必須派發到執行緒池，否則 IO 執行緒阻塞，將導致不能接收其它請求。

3：如果用 IO 執行緒處理事件，又在事件處理過程中發起新的 IO 請求，比如在連線事件中發起登入請求，會報“可能引發死鎖”異常，但不會真死鎖

 

當然，Dispatcher 和 threadpool 都是可以擴充套件的，可以參考DUBBO文件的 訊息派發擴充套件和執行緒池擴充套件，此外，dispatcher與threadpool是有聯絡的

dispatcher在獲執行緒池時，如果沒有threadpool擴充套件則執行緒池預設為 Executors.newCachedThreadPool(new NamedThreadFactory("DubboSharedHandler", true));

如果有threadpool擴充套件則使用擴充的執行緒池。

 

配置如

<dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" />