dubbo參數調優

dubbo做爲一個服務治理框架，功能相對比較完善，性能也挺不錯。但不少朋友在使用dubbo的時候，只是簡單的參考官方說明進行搭建，並無過多的去思考一些關鍵參數的意義（也多是時間緊任務多，沒空出來研究），最終作出來的效果有必定的打折。 這裏我根據目前咱們項目的使用狀況列出幾個性能調優的參數及其意義，供你們參考。

        在介紹參數以前，咱們先了解下dubbo中配置的優先級，以避免出現調優參數設置了卻沒發現效果實際是配置被覆蓋致使這樣的問題。dubbo分爲consumer和provider端，在配置各個參數時，其優先級以下：

一、consumer的method配置 

二、provider的method配置

三、consumer的reference配置

四、provider的service配置

五、consumer的consumer節點配置

六、provider的provider節點配置

能夠看到，方法級的配置優先級高於接口級，consumer的優先級高於provider。同時，在本地參數配置還存在一層優先級：

一、系統參數(-D)，如-Ddubbo.protocol.port=20881

二、xml配置

三、property文件

         瞭解了這兩個優先級，調優起來纔會更加清晰，省去了一些諸如配置設置了不生效這樣的麻煩。注意，其實dubbo中還能夠經過將配置寫入註冊中心的方式覆蓋用戶配置（優先級高於系統參數），這裏不展開，有興趣的同窗能夠去看官方文檔。接下來咱們看看dubbo的幾個比較重要的調優參數，及其影響的方式和大概實現。

          

參數名	做用範圍	defult	說明	備註
actives	consumer	0	每服務消費者每服務每方法最大併發調用數	0表示不限制
connections	consumer		對每一個提供者的最大鏈接數，rmi、http、hessian等短鏈接協議表示限制鏈接數，dubbo等長鏈接協表示創建的長鏈接個數	dubbo時爲1，及複用單連接
accepts	provider	0	服務提供方最大可接受鏈接數	0表示不限制
iothreads	provider	cpu個數+1	io線程池大小(固定大小)
threads	provider	200	業務線程池大小(固定大小)
executes	provider	0	服務提供者每服務每方法最大可並行執行請求數	0表示不限制
tps	provider		指定時間內（默認60s）最大的可執行次數，注意與executes的區別	默認不開啓

        注意表中參數與圖中的對應關係：

        一、當consumer發起一個請求時，首先通過active limit(參數actives）進行方法級別的限制，其實現方式爲CHM中存放計數器(AtomicInteger)，請求時加1，請求完成（包括異常）減1,若是超過actives則等待有其餘請求完成後重試或者超時後失敗；

        二、從多個鏈接(connections）中選擇一個鏈接發送數據，對於默認的netty實現來講，因爲能夠複用鏈接，默認一個鏈接就能夠。不過若是你在壓測，且只有一個consumer,一個provider，此時適當的加大connections確實可以加強網絡傳輸能力。但線上業務因爲有多個consumer多個provider，所以不建議增長connections參數；

        三、鏈接到達provider時（如dubbo的初次鏈接），首先會判斷總鏈接數是否超限（acceps），超過限制鏈接將被拒絕；

        四、鏈接成功後，具體的請求交給io thread處理。io threads雖然是處理數據的讀寫，但io部分爲異步，更多的消耗的是cpu，所以iothreads默認cpu個數+1是比較合理的設置，不建議調整此參數;

        五、數據讀取並反序列化之後，交給業務線程池處理，默認狀況下線程池爲fixed，且排隊隊列爲0(queues)，這種狀況下，最大併發等於業務線程池大小(threads)，若是但願有請求的堆積能力，能夠調整queues參數。若是但願快速失敗由其餘節點處理（官方推薦方式），則不修改queues，只調整threads;

        六、execute limit（參數executes）是方法級別的併發限制，原理與actives相似，只是少了等待的過程，即受限後當即失敗；

        七、tps，控制指定時間內（默認60s）的請求數。注意目前dubbo默認沒有支持該參數，須要加一個META-INF/dubbo/com.alibaba.dubbo.rpc.Filter文件，文件內容爲：

                   tps=com.alibaba.dubbo.rpc.filter.TpsLimitFilter

 

        從上面的分析，能夠看出若是consumer數*actives>provider數*threads且queues=0，則會存在部分請求沒法申請到資源，重試也有很大概率失敗。 當須要對一個接口的不一樣方法進行不一樣的併發控制時使用executes，不然調整threads就能夠。