一、概述

1.1 主要解決的問題

• 訪問請(qǐng)求流量遠(yuǎn)遠(yuǎn)大于服務(wù)器的負(fù)載，致使服務(wù)器宕機(jī)，導(dǎo)致整個(gè)服務(wù)的不可用；- 限流
• 當(dāng)前服務(wù)調(diào)用其他服務(wù)，其他服務(wù)不可用，導(dǎo)致當(dāng)前服務(wù)的調(diào)用一直超時(shí)，進(jìn)而當(dāng)前服務(wù)的線程資源耗盡，進(jìn)而服務(wù)宕機(jī)，產(chǎn)生服務(wù)雪崩。- 服務(wù)熔斷【或降級(jí)】

1.2 限流定義

通過限制并發(fā)數(shù)或一段時(shí)間窗口允許處理的最大連接數(shù)來(lái)保護(hù)系統(tǒng)，一旦超過設(shè)定閾值，對(duì)當(dāng)前請(qǐng)求進(jìn)行處理。主要的處理方式有：跳轉(zhuǎn)到錯(cuò)誤頁(yè)面、進(jìn)入排隊(duì)系統(tǒng)或降級(jí)等。本質(zhì)上，就是損失一部分用戶的可用性，來(lái)保證整體的可用性。

1.3 常見限流規(guī)則

1. QPS或連接數(shù)控制；例如對(duì)單個(gè)IP的限制、單臺(tái)機(jī)器的限制、單個(gè)服務(wù)組的限制或整個(gè)機(jī)房的限制
2. 傳輸速率：例如資源的下載速度
3. 黑白名單。

1.4 分布式限流

把整個(gè)分布式環(huán)境中所有服務(wù)器當(dāng)做一個(gè)整體來(lái)考量。比如說針對(duì)IP的限流，我們限制了1個(gè)IP每秒最多10個(gè)訪問，不管來(lái)自這個(gè)IP的請(qǐng)求落在了哪臺(tái)機(jī)器上，只要是訪問了集群中的服務(wù)節(jié)點(diǎn)，那么都會(huì)受到限流規(guī)則的制約。必須將限流信息保存在一個(gè)中心化的組件上，這樣它就可以獲取到集群中所有機(jī)器的訪問狀態(tài)，目前有兩個(gè)比較主流的限流方案：

網(wǎng)關(guān)層限流：應(yīng)用在流量入口處；中間件限流：將限流信息存儲(chǔ)在分布式環(huán)境中某個(gè)中間件里（比如Redis緩存），每個(gè)組件都可以從這里獲取到當(dāng)前時(shí)刻的流量統(tǒng)計(jì)，從而決定是拒絕服務(wù)還是放行流量。

二、常用的限流方案

2.1 Guava限流

一種Google研發(fā)的客戶端限流組件，非常輕量級(jí)。但僅支持單機(jī)限流。底層是令牌桶限流算法。

2.2 網(wǎng)關(guān)層限流

將系統(tǒng)流量的分布層次抽象成一個(gè)簡(jiǎn)單的漏斗模型來(lái)看。

上面是一個(gè)最普通的流量模型，從上到下的路徑依次是：

用戶流量從網(wǎng)關(guān)層轉(zhuǎn)發(fā)到后臺(tái)服務(wù)后臺(tái)服務(wù)承接流量，調(diào)用緩存獲取數(shù)據(jù)緩存中無(wú)數(shù)據(jù)，則訪問數(shù)據(jù)庫(kù)

Nginx限流：

基于IP地址和基于服務(wù)器的訪問請(qǐng)求限流并發(fā)量（連接數(shù)）限流下行帶寬速率限制

SpringCloud 的GateWay組件限流。

2.3 中間件限流

方案1： Redis+LUA腳本實(shí)現(xiàn)限流：
方案2： Sentinal限流：底層使用滑動(dòng)窗口算法來(lái)限流。

三、常用限流算法

3.1 計(jì)數(shù)器限流

概述：在一定周期內(nèi)累加訪問次數(shù)，當(dāng)訪問次數(shù)達(dá)到閾值時(shí)，觸發(fā)限流策略，當(dāng)進(jìn)入下一個(gè)時(shí)間周期時(shí)，計(jì)算器會(huì)清零，重新計(jì)數(shù)。
適用場(chǎng)景：短信發(fā)送次數(shù)限制
存在問題：臨界問題，會(huì)造成系統(tǒng)的抖動(dòng)。假設(shè)時(shí)間周期為1s，閾值為50。開始時(shí)間是32s, 32.0-32.8s請(qǐng)求次數(shù)為10，32.8-33s請(qǐng)求次數(shù)為30，33.0-33.2請(qǐng)求次數(shù)為30，33.3-34s請(qǐng)求次數(shù)為30，可以看出在32s和33s時(shí)間窗口內(nèi)都沒有觸發(fā)限流閾值，但在32.8-33.2區(qū)間內(nèi)超過限流閾值，造成系統(tǒng)的不穩(wěn)定。

3.2 滑動(dòng)窗口限流

概述：解決了計(jì)數(shù)器限流算法的臨界問題。將固定周期劃分為n個(gè)小的時(shí)間段，分別在每個(gè)時(shí)間段內(nèi)統(tǒng)計(jì)請(qǐng)求訪問次數(shù)，然后根據(jù)時(shí)間將窗口向前滑動(dòng)并刪除過期的時(shí)間段，時(shí)間段越短統(tǒng)計(jì)的越準(zhǔn)，很好的解決了臨界問題
適用場(chǎng)景：sentinel底層采用該算法
存在問題：窗口大小選擇以及n大小的選擇。

3.3 令牌桶限流

概述：對(duì)于每一個(gè)請(qǐng)求，都需要先從令牌桶中獲取令牌。若獲取不到令牌，觸發(fā)限流策略。系統(tǒng)會(huì)以一個(gè)恒定速率向令牌童中放入令牌，令牌中滿了后直接丟棄令牌
適用場(chǎng)景：網(wǎng)絡(luò)流量整形和速率限制，適合處理突發(fā)流量。當(dāng)突發(fā)流量來(lái)的時(shí)候，可以直接獲取令牌中所有的令牌進(jìn)行快速處理。Guava底層就采用該算法
存在問題：雖然可以處理突發(fā)流量，但后臺(tái)系統(tǒng)的壓力也會(huì)瞬間增大，要合理設(shè)置令牌數(shù)量。

3.4 漏桶限流算法

概述：控制數(shù)據(jù)注入網(wǎng)絡(luò)的速度。在漏桶內(nèi)部維護(hù)一個(gè)容器，這個(gè)容器會(huì)以恒定速率出水，不論漏桶的流入速度多快，出水的速度是固定的，消息中間件就利用了該思想。
適用場(chǎng)景：流量平滑
存在的問題：無(wú)法處理突發(fā)流量。漏桶的天然特性決定了它不會(huì)發(fā)生突發(fā)流量，就算每秒1000個(gè)請(qǐng)求到來(lái)，那么它對(duì)后臺(tái)服務(wù)輸出的訪問速率永遠(yuǎn)恒定。而令牌桶則不同，其特性可以預(yù)存一定量的令牌，因此在應(yīng)對(duì)突發(fā)流量的時(shí)候可以在短時(shí)間消耗所有令牌，其突發(fā)流量處理效率會(huì)比漏桶高，但是導(dǎo)向后臺(tái)系統(tǒng)的壓力也會(huì)相應(yīng)增多。

四、Guava流量預(yù)熱

4.1 概述

核心思想：動(dòng)態(tài)的調(diào)整令牌的發(fā)放速度，讓流量變化更加平滑。例如：某個(gè)接口設(shè)定了100個(gè)Request每秒的限流標(biāo)準(zhǔn)，同時(shí)使用令牌桶算法做限流。假如當(dāng)前時(shí)間窗口內(nèi)都沒有Request過來(lái)，那么令牌桶中會(huì)裝滿100個(gè)令牌。如果在下一秒突然涌入100個(gè)請(qǐng)求，這些請(qǐng)求會(huì)迅速消耗令牌，對(duì)服務(wù)的瞬時(shí)沖擊會(huì)比較大。

4.2 預(yù)熱模型

其中橫坐標(biāo)是令牌桶的當(dāng)前容量，縱坐標(biāo)是令牌發(fā)放速率。

閑時(shí)到忙時(shí)的流量轉(zhuǎn)變：假定當(dāng)前我們處于閑時(shí)流量階段，沒幾個(gè)訪問請(qǐng)求，這時(shí)令牌桶是滿的。接著在下一秒突然涌入了10個(gè)請(qǐng)求，這些請(qǐng)求開始消耗令牌桶中的令牌。在初始階段，令牌的放行速度比較慢，在第一個(gè)令牌被消耗以后，后面的請(qǐng)求要經(jīng)過3x時(shí)間間隔也就是0.3s才會(huì)獲取第二塊令牌。隨著令牌桶中令牌數(shù)量被逐漸消耗，當(dāng)令牌存量下降到最大容量一半的時(shí)候（Half位置），令牌放行的速率也會(huì)提升，以穩(wěn)定間隔0.1s發(fā)放令牌。
流量從忙時(shí)轉(zhuǎn)變?yōu)殚e時(shí)：令牌發(fā)放速率是由快到慢逐漸變化。起始階段的令牌放行間隔是0.1s，隨著令牌桶內(nèi)令牌逐漸增多，當(dāng)令牌的存量積累到最大容量的一半后，放行令牌的時(shí)間間隔進(jìn)一步增大為0.3s。

RateLimiter正是通過這種方式來(lái)控制令牌發(fā)放的時(shí)間間隔，從而使流量的變化更加平滑。

五、Sentinel工作原理

概述：一款高性能的分布式限流組件，能夠保護(hù)微服務(wù)架構(gòu)下的應(yīng)用程序，實(shí)現(xiàn)服務(wù)限流和服務(wù)降級(jí)熔斷等。
主要原理：利用AOP切面來(lái)攔截所有的請(qǐng)求，對(duì)請(qǐng)求進(jìn)行實(shí)時(shí)計(jì)數(shù)、實(shí)時(shí)統(tǒng)計(jì)等，并根據(jù)設(shè)定的閾值來(lái)決定是否放行該請(qǐng)求。
主要流程為：

1. 規(guī)則配置。利用sentinel提供的功能來(lái)配置限流規(guī)則，即每分鐘請(qǐng)求的次數(shù)。限流規(guī)則會(huì)被加載到內(nèi)存中，sentinel會(huì)利用這些限流規(guī)則進(jìn)行限流
2. 請(qǐng)求攔截。在程序處理處理之前，sentinel利用AOP切面攔截所有的請(qǐng)求；
3. 統(tǒng)計(jì)請(qǐng)求。攔截后，sentinel會(huì)對(duì)請(qǐng)求進(jìn)行實(shí)時(shí)統(tǒng)計(jì)，在內(nèi)存中維護(hù)的時(shí)間窗口內(nèi)統(tǒng)計(jì)請(qǐng)求qps，響應(yīng)時(shí)間以及異常次數(shù)等；
4. 判斷流量。如果qps超過設(shè)定的閾值，則進(jìn)行限流處理，包括降級(jí)等；若調(diào)用其他服務(wù)的響應(yīng)時(shí)間或異常次數(shù)超過閾值，則直接熔斷服務(wù)，不再調(diào)用其他服務(wù)，返回一個(gè)默認(rèn)的降級(jí)值
5. 動(dòng)態(tài)調(diào)整限流。可以在運(yùn)行期間，sentinel可以修改閾值，刪除規(guī)則等

到此這篇關(guān)于探索Java分布式限流技術(shù)的文章就介紹到這了,更多相關(guān)Java分布式限流內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論