Dubbo學習筆記(三) RPC核心原理和執行緒模型

在幾個典型的RPC使用場景中,包含服務發現,負載均衡,容錯,透明,序列化,網路傳輸等模組.其中RPC協議就是核心模組,主要包括序列化,網路傳輸.只要RPC協議實現了,就可以進行遠端呼叫,其他的負載,容錯,透明,註冊發現都是對RPC呼叫的優化,使他更加穩定健壯.

圖解RPC原理

圖解:
客戶端通過呼叫模組,找到服務發現,獲取服務地址,之後進行負載均衡,容錯等執行RPC協議過程, 經過網路傳輸,反序列化 獲取呼叫的服務介面. 再通過執行緒池,對真實服務進行呼叫, 執行緒返回結果,之後再經過網路 把結果反饋回來.這裡RPC協議的過程是IO執行緒,業務邏輯的執行是業務執行緒,通過執行緒池進行解耦,避免了IO執行緒被服務執行緒拖垮.提高效率,類似於TOMCAT,IO執行緒和工作執行緒.

執行緒模型

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

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

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

因此，需要通過不同的派發策略和不同的執行緒池配置的組合來應對不同的場景:

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

重點: 這是配置的 協議 協議有個名字 檢視 配置裡面發現 裡面有個
protocol 屬性,可以引用配置好的協議,並且可以引用多協議. 多協議使用逗號分隔.

Dispatcher

all 所有訊息都派發到執行緒池，包括請求，響應，連線事件，斷開事件，心跳等。

direct 所有訊息都不派發到執行緒池，全部在 IO 執行緒上直接執行。

message 只有請求響應訊息派發到執行緒池，其它連線斷開事件，心跳等訊息，直接在 IO 執行緒上執行。

execution 只請求訊息派發到執行緒池，不含響應，響應和其它連線斷開事件，心跳等訊息，直接在 IO 執行緒上執行。

connection 在 IO 執行緒上，將連線斷開事件放入佇列，有序逐個執行，其它訊息派發到執行緒池。

ThreadPool

fixed 固定大小執行緒池，啟動時建立執行緒，不關閉，一直持有。(預設)

cached 快取執行緒池，空閒一分鐘自動刪除，需要時重建。

limited 可伸縮執行緒池，但池中的執行緒數只會增長不會收縮。只增長不收縮的目的是為了避免收縮時突然來了大流量引起的效能問題。