常見的限流演算法有：令牌桶、漏桶。計數器也可以進行粗暴限流實現。
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表示不限制
tpsprovider
指定時間內（預設60s）最大的可執行次數，注意與executes的區別
預設不開啟
queues
provider
0執行緒池佇列大小，當執行緒池滿時，排隊等待執行的佇列大小，建議不要設定，當線程程池時應立即失敗，重試其它服務提供機器，而不是排隊，除非有特殊需求。
分析當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預設沒有支援該引數
從上面的分析，可以看出如果 (consumer數 * actives > provider數 * threads) 且 (queues=0)，則會存在部分請求無法申請到資源，重試也有很大機率失敗。當需要對乙個介面的不同方法進行不同的併發控制時使用executes，否則調整threads就可以。
內容引用自 dubbo引數調優說明dubbo filterdubbo提供了多個和請求相關的filter 我們可以看到：activelimitfilter executelimitfilter tpslimiterfilter作用於客戶端，控制客戶端同樣的方法可同時執行的次數【即該方法的併發度】```dubbo:reference
配置類:org.apache.dubbo.config.referenceconfig
actives:(int default 0) 每服務消費者每服務每方法最大併發呼叫數 2.0.5以上版本
``````
dubbo:consumer
配置類： org.apache.dubbo.config.consumerconfig
同時為 dubbo:reference 預設值設定
default.actives:(int default 0) 每服務消費者每服務每方法最大併發呼叫數 2.0.5以上版本
``````
dubbo:provider
配置類： org.apache.dubbo.config.providerconfig
同時為 dubbo:service 和 dubbo:protocol 預設值設定
default.actives:(int default 0) 每服務消費者每服務每方法最大併發呼叫數 2.0.5以上版本
```
actives：消費者端的最大併發呼叫限制，即當 consumer 對乙個服務的併發呼叫到上限後，新呼叫會阻塞直到超時，在方法上配置 dubbo:method 則針對該方法進行併發限制，在介面上配置 dubbo:service，則針對該服務進行併發限制建議在 provider 端配置的 consumer 端屬性
當超過了指定的active值之後該請求將等待前面的請求完成
何時結束呢？依賴於該方法的timeout 如果沒有設定timeout的話 可能就是多個請求一直被阻塞然後等待隨機喚醒吧
搭配timeout一起使用
服務端限制```dubbo:service
配置類：org.apache.dubbo.config.serviceconfig
executes:(int default 0) 服務提供者每服務每方法最大可並行執行請求數 2.0.5以上版
``````
dubbo:provider
配置類： org.apache.dubbo.config.providerconfig
同時為 dubbo:service 和 dubbo:protocol 預設值設定
default.actives:(int default 0) 服務提供者每服務每方法最大可並行執行請求數 2.0.5以上版
```
一旦超出指定的數目直接報錯 其實是指在服務端的並行度【需要注意這些都是指的是在單台服務上而不是整個服務集群】同樣作用在服務端 目的在於控制一段時間類中的請求數。dubbo沒有預設支援。dubbo sentinel```使用tpslimitfilter
dubbo框架並沒有預設通過配置檔案啟動這個filter，
所以我們需要在classpath的meta-inf/dubbo/目錄下增加com.alibaba.dubbo.rpc.filter檔案
tps=com.alibaba.dubbo.rpc.filter.tpslimitfilter
就算加上了這個配置，其實也還是生效不了，我們的provider url需要有tps=***引數
```
sentinel 為 dubbo 服務保駕護航
sentinel
dubbo hystrix
hystrix 主要用於熔斷降級討論nginx對於nginx接入層限流可以使用nginx自帶了兩個模組：spring cloud的zuul連線數限流模組ngx_http_limit_conn_module和漏桶演算法實現的請求限流模組ngx_http_limit_req_module。
spring cloud：服務閘道器 zuulspring cloud 對 zuul 進行了整合和增強，zuul 預設使用的 http 客戶端是 apache http client，也可使用 restclient 或 okhttpclient內容引用 spring cloud：服務閘道器 zuulspring cloud hystrixhystrix 主要用於熔斷降級hystrix的工作機制內容引用 熔斷器hystrixdubbo 熔斷，限流，降級
1 寫在前面 1.1 名詞解釋 consumer表示服務呼叫方 provider標示服務提供方，dubbo裡面一般就這麼講。下面的a呼叫b服務，一般是泛指呼叫b服務裡面的乙個介面。1.2 拓撲圖 大寫字母表示不同的服務，後面的序號表示同乙個服務部署在不同機器的例項。2 從微觀角度思考 2.1 超時 ...
dubbo 熔斷，限流，降級
1.1 名詞解釋 consumer表示服務呼叫方 provider標示服務提供方，dubbo裡面一般就這麼講。下面的a呼叫b服務，一般是泛指呼叫b服務裡面的乙個介面。1.2 拓撲圖 大寫字母表示不同的服務，後面的序號表示同乙個服務部署在不同機器的例項。2.1 超時 timeout 在介面呼叫過程中，...
mysql限流熔斷 熔斷，限流，降級
1 寫在前面 1.1 名詞解釋 consumer表示服務呼叫方 provider標示服務提供方，dubbo裡面一般就這麼講。下面的a呼叫b服務，一般是泛指呼叫b服務裡面的乙個介面。1.2 拓撲圖 大寫字母表示不同的服務，後面的序號表示同乙個服務部署在不同機器的例項。2 從微觀角度思考 2.1 超時 ...