Dubbo3 線程模型

2022-03-30 15:59 更新

配置 Dubbo 中的線程模型

如果事件處理的邏輯能迅速完成,并且不會發(fā)起新的 IO 請求,比如只是在內(nèi)存中記個標識,則直接在 IO 線程上處理更快,因為減少了線程池調(diào)度。

但如果事件處理邏輯較慢,或者需要發(fā)起新的 IO 請求,比如需要查詢數(shù)據(jù)庫,則必須派發(fā)到線程池,否則 IO 線程阻塞,將導(dǎo)致不能接收其它請求。

如果用 IO 線程處理事件,又在事件處理過程中發(fā)起新的 IO 請求,比如在連接事件中發(fā)起登錄請求,會報“可能引發(fā)死鎖”異常,但不會真死鎖。

dubbo-protocol

因此,需要通過不同的派發(fā)策略和不同的線程池配置的組合來應(yīng)對不同的場景:

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

Dispatcher

  • ?all ?所有消息都派發(fā)到線程池,包括請求,響應(yīng),連接事件,斷開事件,心跳等。
  • ?direct ?所有消息都不派發(fā)到線程池,全部在 IO 線程上直接執(zhí)行。
  • ?message ?只有請求響應(yīng)消息派發(fā)到線程池,其它連接斷開事件,心跳等消息,直接在 IO 線程上執(zhí)行。
  • ?execution ?只有請求消息派發(fā)到線程池,不含響應(yīng),響應(yīng)和其它連接斷開事件,心跳等消息,直接在 IO 線程上執(zhí)行。
  • ?connection ?在 IO 線程上,將連接斷開事件放入隊列,有序逐個執(zhí)行,其它消息派發(fā)到線程池。

ThreadPool

  • ?fixed ?固定大小線程池,啟動時建立線程,不關(guān)閉,一直持有。(缺省)
  • ?cached ?緩存線程池,空閑一分鐘自動刪除,需要時重建。
  • ?limited ?可伸縮線程池,但池中的線程數(shù)只會增長不會收縮。只增長不收縮的目的是為了避免收縮時突然來了大流量引起的性能問題。
  • ?eager ?優(yōu)先創(chuàng)建?Worker?線程池。在任務(wù)數(shù)量大于?corePoolSize?但是小于?maximumPoolSize?時,優(yōu)先創(chuàng)建?Worker?來處理任務(wù)。當(dāng)任務(wù)數(shù)量大于?maximumPoolSize?時,將任務(wù)放入阻塞隊列中。阻塞隊列充滿時拋出?RejectedExecutionException?。(相比于?cached:cached?在任務(wù)數(shù)量超過?maximumPoolSize?時直接拋出異常而不是將任務(wù)放入阻塞隊列)


以上內(nèi)容是否對您有幫助:
在線筆記
App下載
App下載

掃描二維碼

下載編程獅App

公眾號
微信公眾號

編程獅公眾號