http://www.cnblogs.com/haoxinyue/p/6792309.html?utm_source=tuicool&utm_medium=referral
開濤大神在部落格中說過:在開發高并發系統時有三把利器用來保護系統:緩存、降級和限流。本文結合作者的一些經驗介紹限流的相關概念、算法和正常的實作方式。
緩存
緩存比較好了解,在大型高并發系統中,如果沒有緩存資料庫将分分鐘被爆,系統也會瞬間癱瘓。使用緩存不單單能夠提升系統通路速度、提高并發通路量,也是保護資料庫、保護系統的有效方式。大型網站一般主要是“讀”,緩存的使用很容易被想到。在大型“寫”系統中,緩存也常常扮演者非常重要的角色。比如累積一些資料批量寫入,記憶體裡面的緩存隊列(生産消費),以及HBase寫資料的機制等等也都是通過緩存提升系統的吞吐量或者實作系統的保護措施。甚至消息中間件,你也可以認為是一種分布式的資料緩存。
降級
服務降級是當伺服器壓力劇增的情況下,根據目前業務情況及流量對一些服務和頁面有政策的降級,以此釋放伺服器資源以保證核心任務的正常運作。降級往往會指定不同的級别,面臨不同的異常等級執行不同的處理。根據服務方式:可以拒接服務,可以延遲服務,也有時候可以随機服務。根據服務範圍:可以砍掉某個功能,也可以砍掉某些子產品。總之服務降級需要根據不同的業務需求采用不同的降級政策。主要的目的就是服務雖然有損但是總比沒有好。
限流
限流可以認為服務降級的一種,限流就是限制系統的輸入和輸出流量已達到保護系統的目的。一般來說系統的吞吐量是可以被測算的,為了保證系統的穩定運作,一旦達到的需要限制的門檻值,就需要限制流量并采取一些措施以完成限制流量的目的。比如:延遲處理,拒絕處理,或者部分拒絕處理等等。
限流的算法
常見的限流算法有:計數器、漏桶和令牌桶算法。
計數器
計數器是最簡單粗暴的算法。比如某個服務最多隻能每秒鐘處理100個請求。我們可以設定一個1秒鐘的滑動視窗,視窗中有10個格子,每個格子100毫秒,每100毫秒移動一次,每次移動都需要記錄目前服務請求的次數。記憶體中需要儲存10次的次數。可以用資料結構LinkedList來實作。格子每次移動的時候判斷一次,目前通路次數和LinkedList中最後一個相差是否超過100,如果超過就需要限流了。

很明顯,當滑動視窗的格子劃分的越多,那麼滑動視窗的滾動就越平滑,限流的統計就會越精确。
示例代碼如下:
//服務通路次數,可以放在Redis中,實作分布式系統的通路計數
Long counter = 0L;
//使用LinkedList來記錄滑動視窗的10個格子。
LinkedList<Long> ll = new LinkedList<Long>();
public static void main(String[] args)
{
Counter counter = new Counter();
counter.doCheck();
}
private void doCheck()
{
while (true)
{
ll.addLast(counter);
if (ll.size() > 10)
{
ll.removeFirst();
}
//比較最後一個和第一個,兩者相差一秒
if ((ll.peekLast() - ll.peekFirst()) > 100)
{
//To limit rate
}
Thread.sleep(100);
}
}
漏桶算法
漏桶算法即leaky bucket是一種非常常用的限流算法,可以用來實作流量整形(Traffic Shaping)和流量控制(Traffic Policing)。貼了一張維基百科上示意圖幫助大家了解:
漏桶算法的主要概念如下:
- 一個固定容量的漏桶,按照常量固定速率流出水滴;
- 如果桶是空的,則不需流出水滴;
- 可以以任意速率流入水滴到漏桶;
- 如果流入水滴超出了桶的容量,則流入的水滴溢出了(被丢棄),而漏桶容量是不變的。
漏桶算法比較好實作,在單機系統中可以使用隊列來實作(.Net中TPL DataFlow可以較好的處理類似的問題,你可以在這裡找到相關的介紹),在分布式環境中消息中間件或者Redis都是可選的方案。
令牌桶算法
令牌桶算法是一個存放固定容量令牌(token)的桶,按照固定速率往桶裡添加令牌。令牌桶算法基本可以用下面的幾個概念來描述:
- 令牌将按照固定的速率被放入令牌桶中。比如每秒放10個。
- 桶中最多存放b個令牌,當桶滿時,新添加的令牌被丢棄或拒絕。
- 當一個n個位元組大小的資料包到達,将從桶中删除n個令牌,接着資料包被發送到網絡上。
- 如果桶中的令牌不足n個,則不會删除令牌,且該資料包将被限流(要麼丢棄,要麼緩沖區等待)。
如下圖:
令牌算法是根據放令牌的速率去控制輸出的速率,也就是上圖的to network的速率。to network我們可以了解為消息的處理程式,執行某段業務或者調用某個RPC。
漏桶和令牌桶的比較
令牌桶可以在運作時控制和調整資料處理的速率,處理某時的突發流量。放令牌的頻率增加可以提升整體資料處理的速度,而通過每次擷取令牌的個數增加或者放慢令牌的發放速度和降低整體資料處理速度。而漏桶不行,因為它的流出速率是固定的,程式處理速度也是固定的。
整體而言,令牌桶算法更優,但是實作更為複雜一些。
限流算法實作
Guava
Guava是一個Google開源項目,包含了若幹被Google的Java項目廣泛依賴的核心庫,其中的RateLimiter提供了令牌桶算法實作:平滑突發限流(SmoothBursty)和平滑預熱限流(SmoothWarmingUp)實作。
1. 正常速率:
建立一個限流器,設定每秒放置的令牌數:2個。傳回的RateLimiter對象可以保證1秒内不會給超過2個令牌,并且是固定速率的放置。達到平滑輸出的效果
public void test()
{
/**
* 建立一個限流器,設定每秒放置的令牌數:2個。速率是每秒可以2個的消息。
* 傳回的RateLimiter對象可以保證1秒内不會給超過2個令牌,并且是固定速率的放置。達到平滑輸出的效果
*/
RateLimiter r = RateLimiter.create(2);
while (true)
{
/**
* acquire()擷取一個令牌,并且傳回這個擷取這個令牌所需要的時間。如果桶裡沒有令牌則等待,直到有令牌。
* acquire(N)可以擷取多個令牌。
*/
System.out.println(r.acquire());
}
}
上面代碼執行的結果如下圖,基本是0.5秒一個資料。拿到令牌後才能處理資料,達到輸出資料或者調用接口的平滑效果。acquire()的傳回值是等待令牌的時間,如果需要對某些突發的流量進行處理的話,可以對這個傳回值設定一個門檻值,根據不同的情況進行處理,比如過期丢棄。
2. 突發流量:
突發流量可以是突發的多,也可以是突發的少。首先來看個突發多的例子。還是上面例子的流量,每秒2個資料令牌。如下代碼使用acquire方法,指定參數。
System.out.println(r.acquire(2));
System.out.println(r.acquire(1));
System.out.println(r.acquire(1));
System.out.println(r.acquire(1));
得到如下類似的輸出。
如果要一次新處理更多的資料,則需要更多的令牌。代碼首先擷取2個令牌,那麼下一個令牌就不是0.5秒之後獲得了,還是1秒以後,之後又恢複正常速度。這是一個突發多的例子,如果是突發沒有流量,如下代碼:
System.out.println(r.acquire(1));
Thread.sleep(2000);
System.out.println(r.acquire(1));
System.out.println(r.acquire(1));
System.out.println(r.acquire(1));
得到如下類似的結果:
等了兩秒鐘之後,令牌桶裡面就積累了3個令牌,可以連續不花時間的擷取出來。處理突發其實也就是在機關時間内輸出恒定。這兩種方式都是使用的RateLimiter的子類SmoothBursty。另一個子類是SmoothWarmingUp,它提供的有一定緩沖的流量輸出方案。
/**
* 建立一個限流器,設定每秒放置的令牌數:2個。速率是每秒可以210的消息。
* 傳回的RateLimiter對象可以保證1秒内不會給超過2個令牌,并且是固定速率的放置。達到平滑輸出的效果
* 設定緩沖時間為3秒
*/
RateLimiter r = RateLimiter.create(2,3,TimeUnit.SECONDS);
while (true) {
/**
* acquire()擷取一個令牌,并且傳回這個擷取這個令牌所需要的時間。如果桶裡沒有令牌則等待,直到有令牌。
* acquire(N)可以擷取多個令牌。
*/
System.out.println(r.acquire(1));
System.out.println(r.acquire(1));
System.out.println(r.acquire(1));
System.out.println(r.acquire(1));
}
輸出結果如下圖,由于設定了緩沖的時間是3秒,令牌桶一開始并不會0.5秒給一個消息,而是形成一個平滑線性下降的坡度,頻率越來越高,在3秒鐘之内達到原本設定的頻率,以後就以固定的頻率輸出。圖中紅線圈出來的3次累加起來正好是3秒左右。這種功能适合系統剛啟動需要一點時間來“熱身”的場景。
Nginx
對于Nginx接入層限流可以使用Nginx自帶了兩個子產品:連接配接數限流子產品ngx_http_limit_conn_module和漏桶算法實作的請求限流子產品ngx_http_limit_req_module。
1. ngx_http_limit_conn_module
我們經常會遇到這種情況,伺服器流量異常,負載過大等等。對于大流量惡意的攻擊通路,會帶來帶寬的浪費,伺服器壓力,影響業務,往往考慮對同一個ip的連接配接數,并發數進行限制。ngx_http_limit_conn_module 子產品來實作該需求。該子產品可以根據定義的鍵來限制每個鍵值的連接配接數,如同一個IP來源的連接配接數。并不是所有的連接配接都會被該子產品計數,隻有那些正在被處理的請求(這些請求的頭資訊已被完全讀入)所在的連接配接才會被計數。
我們可以在nginx_conf的http{}中加上如下配置實作限制:
#限制每個使用者的并發連接配接數,取名one
limit_conn_zone $binary_remote_addr zone=one:10m;
#配置記錄被限流後的日志級别,預設error級别
limit_conn_log_level error;
#配置被限流後傳回的狀态碼,預設傳回503
limit_conn_status 503;
然後在server{}裡加上如下代碼:
#限制使用者并發連接配接數為1
limit_conn one 1;
然後我們是使用ab測試來模拟并發請求:
ab -n 5 -c 5 http://10.23.22.239/index.html
得到下面的結果,很明顯并發被限制住了,超過門檻值的都顯示503:
另外剛才是配置針對單個IP的并發限制,還是可以針對域名進行并發限制,配置和用戶端IP類似。
#http{}段配置
limit_conn_zone $ server_name zone=perserver:10m;
#server{}段配置
limit_conn perserver 1;
2. ngx_http_limit_req_module
上面我們使用到了ngx_http_limit_conn_module 子產品,來限制連接配接數。那麼請求數的限制該怎麼做呢?這就需要通過ngx_http_limit_req_module 子產品來實作,該子產品可以通過定義的鍵值來限制請求處理的頻率。特别的,可以限制來自單個IP位址的請求處理頻率。 限制的方法是使用了漏鬥算法,每秒固定處理請求數,推遲過多請求。如果請求的頻率超過了限制域配置的值,請求處理會被延遲或被丢棄,是以所有的請求都是以定義的頻率被處理的。
在http{}中配置
#區域名稱為one,大小為10m,平均處理的請求頻率不能超過每秒一次。
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
在server{}中配置
#設定每個IP桶的數量為5
limit_req zone=one burst=5;
上面設定定義了每個IP的請求處理隻能限制在每秒1個。并且服務端可以為每個IP緩存5個請求,如果操作了5個請求,請求就會被丢棄。
使用ab測試模拟用戶端連續通路10次:ab -n 10 -c 10 http://10.23.22.239/index.html
如下圖,設定了通的個數為5個。一共10個請求,第一個請求馬上被處理。第2-6個被存放在桶中。由于桶滿了,沒有設定nodelay是以,餘下的4個請求被丢棄。