dubbo引數調優說明
dubbo作為一個服務治理框架，功能相對比較完善，效能也挺不錯。但很多朋友在使用dubbo的時候，只是簡單的參考官方說明進行搭建，並沒有過多的去思考一些關鍵引數的意義（也可能是時間緊任務多，沒空出來研究），最終做出來的效果有一定的打折。 這裡我根據目前我們專案的使用情況列出幾個效能調優的引數及其意義，供大家參考。
在介紹引數之前，我們先了解下dubbo中配置的優先順序，以免出現調優引數設定了卻沒發現效果實際是配置被覆蓋導致這樣的問題。dubbo分為consumer和provider端，在配置各個引數時，其優先順序如下：
1、consumer的method配置
2、provider的method配置
3、consumer的reference配置
4、provider的service配置
5、consumer的consumer節點配置
6、provider的provider節點配置
可以看到，方法級的配置優先順序高於介面級，consumer的優先順序高於provider。同時，在本地引數配置還存在一層優先順序：
1、系統引數(-D)，如-Ddubbo.protocol.port=20881
2、xml配置
3、property檔案
瞭解了這兩個優先順序，調優起來才會更加清晰，省去了一些諸如配置設定了不生效這樣的麻煩。注意，其實dubbo中還可以通過將配置寫入註冊中心的方式覆蓋使用者配置（優先順序高於系統引數），這裡不展開，有興趣的同學可以去看官方文件。接下來我們看看dubbo的幾個比較重要的調優引數，及其影響的方式和大概實現。
| 引數名 | 作用範圍 | 預設值 | 說明 | 備註 |
|---|---|---|---|---|
| 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的區別 | 預設不開啟 |
注意表中引數與圖中的對應關係：
1、當consumer發起一個請求時，首先經過active limit(引數actives）進行方法級別的限制，其實現方式為CHM中存放計數器(AtomicInteger)，請求時加1，請求完成（包括異常）減1,如果超過actives則等待有其他請求完成後重試或者超時後失敗；
2、從多個連線(connections）中選擇一個連線傳送資料，對於預設的netty實現來說，由於可以複用連線，預設一個連線就可以。不過如果你在壓測，且只有一個consumer,一個provider，此時適當的加大connections確實能夠增強網路傳輸能力。但線上業務由於有多個consumer多個provider，因此不建議增加connections引數；
3、連線到達provider時（如dubbo的初次連線），首先會判斷總連線數是否超限（acceps），超過限制連線將被拒絕；
4、連線成功後，具體的請求交給io thread處理。io threads雖然是處理資料的讀寫，但io部分為非同步，更多的消耗的是cpu，因此iothreads預設cpu個數+1是比較合理的設定，不建議調整此引數;
5、資料讀取並反序列化以後，交給業務執行緒池處理，預設情況下執行緒池為fixed，且排隊佇列為0(queues)，這種情況下，最大併發等於業務執行緒池大小(threads)，如果希望有請求的堆積能力，可以調整queues引數。如果希望快速失敗由其他節點處理（官方推薦方式），則不修改queues，只調整threads;
6、execute limit（引數executes）是方法級別的併發限制，原理與actives類似，只是少了等待的過程，即受限後立即失敗；
7、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就可以。
轉載於:https://my.oschina.net/mifans/blog/860693