一、概述

1.1 主要解決的問題

• 訪問請求流量遠(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ù)熔斷【或降級】

1.2 限流定義

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

1.3 常見限流規(guī)則

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

1.4 分布式限流

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

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

二、常用的限流方案

2.1 Guava限流

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

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

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

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

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

Nginx限流：

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

SpringCloud 的GateWay組件限流。

2.3 中間件限流

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

三、常用限流算法

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

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

3.2 滑動窗口限流

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

3.3 令牌桶限流

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

3.4 漏桶限流算法

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

四、Guava流量預(yù)熱

4.1 概述

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

4.2 預(yù)熱模型

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

閑時(shí)到忙時(shí)的流量轉(zhuǎn)變：假定當(dāng)前我們處于閑時(shí)流量階段，沒幾個(gè)訪問請求，這時(shí)令牌桶是滿的。接著在下一秒突然涌入了10個(gè)請求，這些請求開始消耗令牌桶中的令牌。在初始階段，令牌的放行速度比較慢，在第一個(gè)令牌被消耗以后，后面的請求要經(jīng)過3x時(shí)間間隔也就是0.3s才會獲取第二塊令牌。隨著令牌桶中令牌數(shù)量被逐漸消耗，當(dāng)令牌存量下降到最大容量一半的時(shí)候（Half位置），令牌放行的速率也會提升，以穩(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正是通過這種方式來控制令牌發(fā)放的時(shí)間間隔，從而使流量的變化更加平滑。

五、Sentinel工作原理

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

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

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

最新評論