限流總并發(fā)/連接/請求數(shù)
對于一個應(yīng)用系統(tǒng)來說一定會有極限并發(fā)/請求數(shù)，即總有一個TPS/QPS閥值，如果超了閥值則系統(tǒng)就會不響應(yīng)用戶請求或響應(yīng)的非常慢，因此我們最好進(jìn)行過載保護(hù)，防止大量請求涌入擊垮系統(tǒng)。
如果你使用過Tomcat，其Connector其中一種配置有如下幾個參數(shù)：
acceptCount：如果Tomcat的線程都忙于響應(yīng)，新來的連接會進(jìn)入隊列排隊，如果超出排隊大小，則拒絕連接；
maxConnections：瞬時最大連接數(shù)，超出的會排隊等待；
maxThreads：Tomcat能啟動用來處理請求的最大線程數(shù)，如果請求處理量一直遠(yuǎn)遠(yuǎn)大于最大線程數(shù)則可能會僵死。
詳細(xì)的配置請參考官方文檔。另外如MySQL（如max_connections）、Redis（如tcp-backlog）都會有類似的限制連接數(shù)的配置。
限流總資源數(shù)
如果有的資源是稀缺資源（如數(shù)據(jù)庫連接、線程），而且可能有多個系統(tǒng)都會去使用它，那么需要限制應(yīng)用；可以使用池化技術(shù)來限制總資源數(shù)：連接池、線程池。比如分配給每個應(yīng)用的數(shù)據(jù)庫連接是100，那么本應(yīng)用最多可以使用100個資源，超出了可以等待或者拋異常。
限流某個接口的總并發(fā)/請求數(shù)
如果接口可能會有突發(fā)訪問情況，但又擔(dān)心訪問量太大造成崩潰，如搶購業(yè)務(wù)；這個時候就需要限制這個接口的總并發(fā)/請求數(shù)總請求數(shù)了；因為粒度比較細(xì)，可以為每個接口都設(shè)置相應(yīng)的閥值?？梢允褂肑ava中的AtomicLong進(jìn)行限流：
適合對業(yè)務(wù)無損的服務(wù)或者需要過載保護(hù)的服務(wù)進(jìn)行限流，如搶購業(yè)務(wù)，超出了大小要么讓用戶排隊，要么告訴用戶沒貨了，對用戶來說是可以接受的。而一些開放平臺也會限制用戶調(diào)用某個接口的試用請求量，也可以用這種計數(shù)器方式實(shí)現(xiàn)。這種方式也是簡單粗暴的限流，沒有平滑處理，需要根據(jù)實(shí)際情況選擇使用；
限流某個接口的時間窗請求數(shù)
即一個時間窗口內(nèi)的請求數(shù)，如想限制某個接口/服務(wù)每秒/每分鐘/每天的請求數(shù)/調(diào)用量。如一些基礎(chǔ)服務(wù)會被很多其他系統(tǒng)調(diào)用，比如商品詳情頁服務(wù)會調(diào)用基礎(chǔ)商品服務(wù)調(diào)用，但是怕因為更新量比較大將基礎(chǔ)服務(wù)打掛，這時我們要對每秒/每分鐘的調(diào)用量進(jìn)行限速；一種實(shí)現(xiàn)方式如下所示：
平滑限流某個接口的請求數(shù)
之前的限流方式都不能很好地應(yīng)對突發(fā)請求，即瞬間請求可能都被允許從而導(dǎo)致一些問題；因此在一些場景中需要對突發(fā)請求進(jìn)行整形，整形為平均速率請求處理（比如5r/s，則每隔200毫秒處理一個請求，平滑了速率）。這個時候有兩種算法滿足我們的場景：令牌桶和漏桶算法。Guava框架提供了令牌桶算法實(shí)現(xiàn)，可直接拿來使用。
Guava RateLimiter提供了令牌桶算法實(shí)現(xiàn)：平滑突發(fā)限流(SmoothBursty)和平滑預(yù)熱限流(SmoothWarmingUp)實(shí)現(xiàn)。
推薦閱讀：
<<<高并發(fā)架構(gòu)的整體思路
<<<一個網(wǎng)站訪問慢的真正原因
<<<高并發(fā)情況下，接口的代碼會存在哪些問題
<<<壓縮靜態(tài)資源減少帶寬傳輸?shù)姆绞?/a>
<<<動靜分離架構(gòu)模式
<<<緩存策略匯總
<<<后端服務(wù)的雪崩效應(yīng)及解決思路
<<<服務(wù)的隔離、降級和熔斷
<<<服務(wù)限流之計數(shù)器方式
<<<服務(wù)限流之滑動窗口計數(shù)
<<<服務(wù)限流之令牌桶算法
<<<服務(wù)限流之漏桶算法
<<<漏桶算法和令牌桶算法的區(qū)別
<<<自定義封裝限流算法
<<<接入層限流
