前言

---

在實際項目中，曾經(jīng)遭遇過線上5W+QPS的峰值，也在壓測狀態(tài)下經(jīng)歷過10W+QPS的大流量請求，本篇博客的話題主要就是自己對高并發(fā)流量控制的一點(diǎn)思考。

?

應(yīng)對大流量的一些思路

---

首先，我們來說一下什么是大流量？

大流量，我們很可能會冒出：TPS（每秒事務(wù)量），QPS（每秒請求量），1W+，5W+，10W+，100W+...。其實并沒有一個絕對的數(shù)字，如果這個量造成了系統(tǒng)的壓力，影響了系統(tǒng)的性能，那么這個量就可以稱之為大流量了。

其次，應(yīng)對大流量的一些常見手段是什么？

緩存：說白了，就是讓數(shù)據(jù)盡早進(jìn)入緩存，離程序近一點(diǎn)，不要大量頻繁的訪問DB。

降級：如果不是核心鏈路，那么就把這個服務(wù)降級掉。打個比喻，現(xiàn)在的APP都講究千人千面，拿到數(shù)據(jù)后，做個性化排序展示，如果在大流量下，這個排序就可以降級掉！

限流：大家都知道，北京地鐵早高峰，地鐵站都會做一件事情，就是限流了！想法很直接，就是想在一定時間內(nèi)把請求限制在一定范圍內(nèi)，保證系統(tǒng)不被沖垮，同時盡可能提升系統(tǒng)的吞吐量。

注意到，有些時候，緩存和降級是解決不了問題的，比如，電商的雙十一，用戶的購買，下單等行為，是涉及到大量寫操作，而且是核心鏈路，無法降級的，這個時候，限流就比較重要了。

那么接下來，我們重點(diǎn)說一下，限流。

?

限流的常用方式

---

限流的常用處理手段有：計數(shù)器、滑動窗口、漏桶、令牌。

計數(shù)器

計數(shù)器是一種比較簡單的限流算法，用途比較廣泛，在接口層面，很多地方使用這種方式限流。在一段時間內(nèi)，進(jìn)行計數(shù)，與閥值進(jìn)行比較，到了時間臨界點(diǎn)，將計數(shù)器清0。

計數(shù)器思想

?

代碼實例

計數(shù)器代碼實現(xiàn)

這里需要注意的是，存在一個時間臨界點(diǎn)的問題。舉個栗子，在12:01:00到12:01:58這段時間內(nèi)沒有用戶請求，然后在12:01:59這一瞬時發(fā)出100個請求，OK，然后在12:02:00這一瞬時又發(fā)出了100個請求。這里你應(yīng)該能感受到，在這個臨界點(diǎn)可能會承受惡意用戶的大量請求，甚至超出系統(tǒng)預(yù)期的承受。

滑動窗口

由于計數(shù)器存在臨界點(diǎn)缺陷，后來出現(xiàn)了滑動窗口算法來解決。

滑動窗口原理圖

滑動窗口的意思是說把固定時間片，進(jìn)行劃分，并且隨著時間的流逝，進(jìn)行移動，這樣就巧妙的避開了計數(shù)器的臨界點(diǎn)問題。也就是說這些固定數(shù)量的可以移動的格子，將會進(jìn)行計數(shù)判斷閥值，因此格子的數(shù)量影響著滑動窗口算法的精度。

漏桶

雖然滑動窗口有效避免了時間臨界點(diǎn)的問題，但是依然有時間片的概念，而漏桶算法在這方面比滑動窗口而言，更加先進(jìn)。

有一個固定的桶，進(jìn)水的速率是不確定的，但是出水的速率是恒定的，當(dāng)水滿的時候是會溢出的。

漏桶算法思想

代碼實現(xiàn)

漏桶代碼實現(xiàn)

令牌桶

注意到，漏桶的出水速度是恒定的，那么意味著如果瞬時大流量的話，將有大部分請求被丟棄掉（也就是所謂的溢出）。為了解決這個問題，令牌桶進(jìn)行了算法改進(jìn)。

令牌桶原理

生成令牌的速度是恒定的，而請求去拿令牌是沒有速度限制的。這意味，面對瞬時大流量，該算法可以在短時間內(nèi)請求拿到大量令牌，而且拿令牌的過程并不是消耗很大的事情。（有一點(diǎn)生產(chǎn)令牌，消費(fèi)令牌的意味）

不論是對于令牌桶拿不到令牌被拒絕，還是漏桶的水滿了溢出，都是為了保證大部分流量的正常使用，而犧牲掉了少部分流量，這是合理的，如果因為極少部分流量需要保證的話，那么就可能導(dǎo)致系統(tǒng)達(dá)到極限而掛掉，得不償失。

代碼實現(xiàn)

令牌桶代碼實現(xiàn)

?

限流神器：Guava RateLimiter

---

Guava不僅僅在集合、緩存、異步回調(diào)等方面功能強(qiáng)大（可以參考博主的《使用Google Guava快樂編程》），而且還給我們封裝好了限流的API！

Guava RateLimiter基于令牌桶算法，我們只需要告訴RateLimiter系統(tǒng)限制的QPS是多少，那么RateLimiter將以這個速度往桶里面放入令牌，然后請求的時候，通過tryAcquire()方法向RateLimiter獲取許可（令牌）。

代碼示例

RateLimiter

?

分布式場景下的限流

---

上面所說的限流的一些方式，都是針對單機(jī)而言的，其實大部分的場景，單機(jī)的限流已經(jīng)足夠了。分布式下限流的手段常常需要多種技術(shù)相結(jié)合，比如Nginx+Lua，Redis+Lua等去做。本文主要討論的是單機(jī)的限流，這里就不在詳細(xì)介紹分布式場景下的限流了。

一句話，讓系統(tǒng)的流量，先到隊列中排隊、限流，不要讓流量直接打到系統(tǒng)上。

?

好了，到這里，本文就結(jié)束了！

早安！

美好的一天開始了，上班咯！

?

?

手寫系列相關(guān)爆文

---

【手寫系列】寫出我的第一個框架：迷你版Spring MVC

【手寫系列】透徹理解Spring事務(wù)設(shè)計思想之手寫實現(xiàn)

【手寫系列】透徹理解MyBatis設(shè)計思想之手寫實現(xiàn)

【手寫系列】純手寫實現(xiàn)一個高可用的RPC

【手寫系列】理解數(shù)據(jù)庫連接池底層原理之手寫實現(xiàn)

【手寫系列】對HashMap的思考及手寫實現(xiàn)

【手寫系列】純手寫實現(xiàn)JDK動態(tài)代理

【手寫系列】寫一個迷你版的Tomcat

作者：張豐哲
鏈接：https://www.jianshu.com/p/d9504fc0af4d
來源：簡書
簡書著作權(quán)歸作者所有，任何形式的轉(zhuǎn)載都請聯(lián)系作者獲得授權(quán)并注明出處。

總結(jié)

以上是生活随笔為你收集整理的对高并发流量控制的一点思考的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。