什么是限流？

限流可以認為服務降級的一種，限流就是限制系統(tǒng)的輸入和輸出流量已達到保護系統(tǒng)的目的。一般來說系統(tǒng)的吞吐量是可以被測算的，為了保證系統(tǒng)的穩(wěn)定運行，一旦達到的需要限制的閾值，就需要限制流量并采取一些措施以完成限制流量的目的。比如：延遲處理，拒絕處理，或者部分拒絕處理等等。

坐地鐵上班的同學對于這張圖片是不是都不會陌生。基本上在上下班的早晚高峰我們就會發(fā)現(xiàn)進站的閘機會有一部分是關(guān)閉的。為什么地鐵站會關(guān)閉一部分閘機呢？這就是為了限流。畢竟地鐵站就那么大，可容納的人數(shù)也就那么多。如果大家一股腦全部擠進地鐵站是不是又會發(fā)生踩踏事件什么的。這是生活中的限流。還有我們?nèi)ゾ皡^(qū)玩，景區(qū)的門票是不是也是固定的，每天就賣那么多張，賣完即止。限流是不是和我們的生活也息息相關(guān)。

為什么要限流？

開篇也有說到限流是為了「保證系統(tǒng)的穩(wěn)定運行」。假設我們一個系統(tǒng)一小時之最多只能處理10000個請求，但是一小時流量突增10倍，這突增的流量我們?nèi)绻贿M行限制的話，任由它直接進入系統(tǒng)的話，是不是直接會把我們的系統(tǒng)弄癱瘓，就無法對外提供服務了。本人就曾經(jīng)被這個所坑過，有一次把爬蟲開關(guān)攔截的開關(guān)給關(guān)掉了，突然有一大波的爬蟲流量進入系統(tǒng)中，我們也沒有把這些爬蟲請求進行攔截，然后一股腦的全部給轉(zhuǎn)發(fā)到下游系統(tǒng)里面去了。下游系統(tǒng)直接就找上門來了，造成他們的服務發(fā)生大量的超時。比如地鐵早高峰的時候我們?nèi)绻粚Φ罔F站進行限流的話，大家是不是都會往地鐵站擠，然后再往地鐵里面擠，擠不上都還要擠。會導致地鐵門都關(guān)不上，然后地鐵就開不走，會導致越來越多的人堵在地鐵站。然后最后就會導致整條地鐵線都阻塞了。上班就妥妥的遲到了（對于程序員說大多數(shù)應該是彈性制的所以也不存在遲到這一說法）。

限流操作有哪些？

拒絕服務

這個是最最簡單粗暴的做法了，直接把請求直接拒絕掉。比如早高峰坐地鐵的時候，直接讓進入1000個人，剩下多出來的人不讓坐地鐵了。直接把入站口給關(guān)閉了。

服務降級

將系統(tǒng)的所有功能服務進行一個分級，當系統(tǒng)出現(xiàn)問題，需要緊急限流時，可將不是那么重要的功能進行降級處理，停止服務，這樣可以釋放出更多的資源供給核心功能的去用。假設有一個功能新用戶注冊完，要給用戶發(fā)送多少優(yōu)惠券。這時候服務降級的話就可以直接把送券服務關(guān)掉，讓服務快速響應，提高系統(tǒng)處理能力。應用到早高峰坐地鐵的時候比如在人民廣場這個大站點，處理不過來了那么多人換乘，我們是不是可以直接地鐵一號線在人民廣場不停，直接到下一站在停，這時候經(jīng)過人民廣場換乘的人就少多了。

延遲處理

把請求全部放入到隊列中，真正處理的話，就從隊列里面依次去取，這樣的話流量比較大的情況可能會導致處理不及時，會有一定的延時。雙十一零點我們付款的時候，去查詢訂單的狀態(tài)是不是也會有一定的延時，不像在平時付完款訂單狀態(tài)就變成了付款狀態(tài)。

特權(quán)處理

這個模式需要將用戶進行分類，通過預設的分類，讓系統(tǒng)優(yōu)先處理需要高保障的用戶群體，其它用戶群的請求就會延遲處理或者直接不處理。我們?nèi)ャy行辦理業(yè)務的時候是不是也會經(jīng)常需要排隊，但是是不是經(jīng)常會VIP用戶、什么白金卡用戶，直接不需要排隊，直接一上來就可以辦理業(yè)務，還優(yōu)先處理這些人的業(yè)務。是不是特羨慕這些人,哎 羨慕也沒辦法誰叫人家有錢咧。

限流的實現(xiàn)方式？

計數(shù)器方法

這是最簡單的限流算法了，系統(tǒng)里面維護一個計數(shù)器，來一個請求就加1，請求處理完成就減1，當計數(shù)器大于指定的閾值，就拒絕新的請求。是通過全局的總求數(shù)于設置的閾值來達到限流的目的。通常應用在池化技術(shù)上面比如：「數(shù)據(jù)庫連接池、線程池」等中應用。這種方式的話限流不是「平均速率」的?？覆蛔⊥辉龅牧髁?。

漏桶算法

我們可以看到水是可以持續(xù)流入漏桶里面的，底部也是勻速的流出，如果流入的速率大于底部流出的速率，以及漏桶的水超過桶的大小就會發(fā)生益出。請求一經(jīng)過漏桶的過濾，不管你請求有多少，速率有多快，我反正就這么個速度處理。我們平時坐地鐵的時候是不是也是這樣，不管你乘客有多少，反正就是隔5min發(fā)一趟車。那早高峰的時候你5min鐘一趟車根本就不夠用啊，上班的人太多啊，你需要加快速度處理啊，所以可能早高峰改為3min一趟，動態(tài)調(diào)整速率。

令牌桶

看圖的話是不是令牌桶和漏桶都差不多，只不過令牌桶新增了一個勻速生產(chǎn)令牌的中間人以恒定的速度往桶里面放令牌，如果令牌的數(shù)量超過里桶的限制的話，令牌就會溢出，這時候就直接舍棄多余的令牌。每個請求過來必須拿到桶里面拿到了令牌才允許請求（拿令牌的速度是不限制的，這就意味著如果瞬間有大量的流量請求進來，可以短時間內(nèi)拿到大量的令牌），拿不到令牌的話直接拒絕。這個令牌桶的思想是不是跟我們java里面的「Semaphore」 有點類似。Semaphore 是拿信號量，用完了就還回去。但是令牌桶的話，不需要還回去，因為令牌會定時的補充。令牌桶算法我們可以通過Google開源的guava包創(chuàng)建一個令牌桶算法的限流器。

總結(jié)

• 以上粗略的介紹了幾種單機的限流思想，大家可以根據(jù)這個思想然后去實現(xiàn)各種各樣的限流組件。
• 我們的限流算法每個里面是不是都一個閾值，這個閾值設置為多少是不是比較難。閾值設置過大的話，服務可能扛不住，閾值設置小了會把用戶請求給誤殺，資源沒有得到最大的一個利用。
• 分布式限流的話，以后有機會再講。