2. 程式人生 > >Guava——平滑限流

Guava——平滑限流

阿新 • • 發佈：2019-02-02

1.常用限流方法

對於一個應用系統來說一定會有極限併發/請求數，即總有一個TPS/QPS閥值，如果超了閥值則系統就會不響應使用者請求或響應的非常慢，因此我們最好進行過載保護，防止大量請求湧入擊垮系統。

常見的限流方法有：

  • 容器限流

    常見的web容器其實也具備限流的功能。

    以Tomcat容器為例，其Connector 其中一種配置有如下幾個引數：

    acceptCount：如果Tomcat的執行緒都忙於響應，新來的連線會進入佇列排隊，如果超出排隊大小，則拒絕連線；

    maxConnections： 瞬時最大連線數，超出的會排隊等待；

    maxThreads：Tomcat能啟動用來處理請求的最大執行緒數，如果請求處理量一直遠遠大於最大執行緒數則可能會僵死。

  • 限流總資源數

    如果有的資源是稀缺資源（如資料庫連線、執行緒），而且可能有多個系統都會去使用它，那麼需要限制應用；可以使用池化技術來限制總資源數：連線池、執行緒池。比如分配給每個應用的資料庫連線是100，那麼本應用最多可以使用100個資源，超出了可以等待或者拋異常。

  • 限流某個介面的總併發/請求數

    如果介面可能會有突發訪問情況，但又擔心訪問量太大造成崩潰，如搶購業務；這個時候就需要限制這個介面的總併發請求數了；因為粒度比較細，可以為每個介面都設定相應的閥值。可以使用Java中的AtomicLong進行限流：

    try {
     if(atomic.incrementAndGet() > 限流數) {
     //拒絕請求
     

    }
     //處理請求
    } finally {
    atomic.decrementAndGet();
    }

  • 利用Netflix的hystrix限流

2.漏桶演算法 VS 令牌桶演算法

2.1 漏桶演算法(Leaky Bucket)

漏桶演算法(Leaky Bucket)：水(請求)先進入到漏桶裡,漏桶以一定的速度出水(介面有響應速率),當水流入速度過大會直接溢位(訪問頻率超過介面響應速率),然後就拒絕請求,可以看出漏桶演算法能強行限制資料的傳輸速率.示意圖如下:


可見這裡有兩個變數,一個是桶的大小,支援流量突發增多時可以存多少的水(burst),另一個是水桶漏洞的大小(rate)。

2.2 令牌桶演算法(Token Bucket)

令牌桶演算法(Token Bucket)和 Leaky Bucket 效果一樣但方向相反的演算法,更加容易理解.隨著時間流逝,系統會按恆定1/QPS時間間隔(如果QPS=100,則間隔是10ms)往桶裡加入Token(想象和漏洞漏水相反,有個水龍頭在不斷的加水),如果桶已經滿了就不再加了.新請求來臨時,會各自拿走一個Token,如果沒有Token可拿了就阻塞或者拒絕服務.


令牌桶的另外一個好處是可以方便的改變速度. 一旦需要提高速率,則按需提高放入桶中的令牌的速率. 一般會定時(比如100毫秒)往桶中增加一定數量的令牌, 有些變種演算法則實時的計算應該增加的令牌的數量.

2.3 漏桶演算法VS令牌桶演算法

  • 令牌桶是按照固定速率往桶中新增令牌，請求是否被處理需要看桶中令牌是否足夠，當令牌數減為零時則拒絕新的請求；

  • 漏桶則是按照常量固定速率流出請求，流入請求速率任意，當流入的請求數累積到漏桶容量時，則新流入的請求被拒絕；

  • 令牌桶限制的是平均流入速率（允許突發請求，只要有令牌就可以處理，支援一次拿3個令牌，4個令牌），並允許一定程度突發流量；

  • 漏桶限制的是常量流出速率（即流出速率是一個固定常量值，比如都是1的速率流出，而不能一次是1，下次又是2），從而平滑突發流入速率；

  • 令牌桶允許一定程度的突發，而漏桶主要目的是平滑流入速率；

  • 兩個演算法實現可以一樣，但是方向是相反的，對於相同的引數得到的限流效果是一樣的。

3.Guava實現平滑限流

3.1Guava是什麼

Guava是一個開源的Java庫，其中包含谷歌很多專案使用的核心庫。這個庫是為了方便編碼，並減少編碼錯誤。這個庫提供用於集合，快取，支援原語，併發性，常見註解，字串處理，I/O和驗證的實用方法。

3.2Guava RateLimiter實現平滑限流

Guava RateLimiter提供了令牌桶演算法實現：平滑突發限流(SmoothBursty)和平滑預熱限流(SmoothWarmingUp)實現。

平滑突發限流：

/**
 * 平滑突發限流(SmoothBursty)
 */
public class SmoothBurstyRateLimitTest {
    public static void main(String[] args) {
        //QPS = 5，每秒允許5個請求
        RateLimiter limiter = RateLimiter.create(5);
        //limiter.acquire() 返回獲取token的耗時，以秒為單位
        System.out.println(limiter.acquire());
        System.out.println(limiter.acquire());
        System.out.println(limiter.acquire());
        System.out.println(limiter.acquire());
        System.out.println(limiter.acquire());
        System.out.println(limiter.acquire());
    }
}

0.0
0.19667
0.195784
0.194672
0.195658
0.195285
/**
 * 平滑突發限流(smoothbursty)
 */
public class SmoothBurstyRateLimitTest02 {

    public static void main(String[] args) {
        //每秒允許5個請求，表示桶容量為5且每秒新增5個令牌，即每隔0.2毫秒新增一個令牌
        RateLimiter limiter = RateLimiter.create(5);
        //一次性消費5個令牌
        System.out.println(limiter.acquire(5));
        //limiter.acquire(1)將等待差不多1秒桶中才能有令牌
        System.out.println(limiter.acquire(1));
        //固定速率
        System.out.println(limiter.acquire(1));
        //固定速率
        System.out.println(limiter.acquire(1));
        //固定速率
        System.out.println(limiter.acquire(1));
    }
}
/**
 * 平滑突發限流(smoothbursty)
 */
public class SmoothBurstyRateLimitTest03 {

    public static void main(String[] args) {
        //每秒允許5個請求，表示桶容量為5且每秒新增5個令牌，即每隔0.2毫秒新增一個令牌
        RateLimiter limiter = RateLimiter.create(5);
        //第一秒突發了10個請求
        System.out.println(limiter.acquire(10));
        //limiter.acquire(1)將等待差不多2秒桶中才能有令牌
        System.out.println(limiter.acquire(1));
        //固定速率
        System.out.println(limiter.acquire(1));
        //固定速率
        System.out.println(limiter.acquire(1));
        //固定速率
        System.out.println(limiter.acquire(1));
    }
}

平滑預熱限流：

/**
 * 平滑預熱限流(SmoothWarmingUp)
 */
public class SmoothWarmingUp {
    public static void main(String[] args) {
        //permitsPerSecond:每秒新增的令牌數  warmupPeriod:從冷啟動速率過渡到平均速率的時間間隔
        //系統冷啟動後慢慢的趨於平均固定速率（即剛開始速率慢一些，然後慢慢趨於我們設定的固定速率）
        RateLimiter limiter = RateLimiter.create(10, 1000, TimeUnit.MILLISECONDS);
        for(int i = 0; i < 10;i++) {
            //獲取一個令牌
            System.out.println(limiter.acquire(1));
        }
    }
}

秒殺場景：

/**
 * 秒殺場景模擬
 */
public class MiaoShaTest {

    public static void main(String[] args) throws InterruptedException {

        //限流，每秒允許10個請求進入秒殺
        RateLimiter limiter = RateLimiter.create(10);

        for (int i = 0; i < 100; i++) {
            //100個執行緒同時搶購
            new Thread(() -> {
                //每個秒殺請求如果100ms以內得到令牌，就算是秒殺成功，否則就返回秒殺失敗
                if (limiter.tryAcquire(50, TimeUnit.MILLISECONDS)) {
                    System.out.println("恭喜您，秒殺成功");
                } else {
                    System.out.println("秒殺失敗，請繼續努力");
                }
            }).start();
            //等待新的令牌生成
            Thread.sleep(10);
        }
    }
}

測試demo地址：https://github.com/online-demo/yunxi-guava

相關推薦

Guava——平滑限流

1.常用限流方法對於一個應用系統來說一定會有極限併發/請求數，即總有一個TPS/QPS閥值，如果超了閥值則系統就會不響應使用者請求或響應的非常慢，因此我們最好進行過載保護，防止大量請求湧入擊垮系統。常見

使用Guava實現限流器

為什麼需要限流？在開發高併發系統時有三把利器用來保護系統：快取、降級和限流。限流可以認為服務降級的一種，限流通過限制請求的流量以達到保護系統的目的。一般來說，系統的吞吐量是可以計算出一個閾值的，為了保證系統的穩定執行，一旦達到這個閾值，就需要限制流量並採取一些措施以完成限制流

Guava RateLimiter限流原始碼解析和例項應用

在開發高併發系統時有三把利器用來保護系統：快取、降級和限流 快取 快取的目的是提升系統訪問速度和增大

Guava的RateLimiter實現接口限流

如果 pri work response 許可證 整理 ise quest 進行 最近開發需求中有需要對後臺接口進行限流處理，整理了一下基本使用方法。 首先添加guava依賴: <dependency> <groupId>com

使用Guava的RateLimiter完成簡單的大流量限流

 限流的一般思路： 1、隨機丟棄一定規則的使用者（迅速過濾掉90%的使用者）； 2、MQ削峰（比如設一個MQ可以容納的最大訊息量，達到這個量後MQ給予reject）； 3、業務邏輯層使用RateLimiter進行限流； 4、最終可以承受的流量到達DB層。 package rateli

常用介面限流功能實現基於Guava設計

Guava是一組核心庫，包括新的集合型別（例如multimap和multiset），不可變集合，圖形庫，函式型別，記憶體快取以及用於併發，I / O，雜湊，基元的API /實用程式，反射，字串處理等等！ 本示例只使用了Guava工具包的RateLimiter類，進行API的限流。 限

guava 限流的兩種方式

java中對於生產者消費者模型，或者小米手機營銷 1分鐘賣多少臺手機等都存在限流的思想在裡面。 關於限流 目前存在兩大類，從執行緒個數（jdk1.5 Semaphore）和RateLimiter速率(guava) Semaphore：從執行緒個數限流 RateLimi

使用Guava的RateLimiter做限流

RateLimiter 從概念上來講，速率限制器會在可配置的速率下分配許可證。如果必要的話，每個acquire() 會阻塞當前執行緒直到許可證可用後獲取該許可證。一旦獲取到許可證，不需要再釋放許可證。

Guava-RateLimiter秒殺限流技術詳解

使用場景 系統使用下游資源時，需要考慮下游對資源受限、處理能力，在下游資源無法或者短時間內無法提升處理效能的情況下，可以使用限流器或者類似保護機制，避免下游服務崩潰造成整體服務的不可用。 常用演算法 常見限流演算法有兩種：漏桶演算法和令牌桶演算法。 漏桶演算法

使用Guava-RateLimiter做介面限流

RateLimiter 速率限制器，是 Google Guava提供的基於令牌桶演算法的實現類。 對請求流量進行限制。不僅可以控制併發，而且可以準確的控制TPS（每秒鐘請求數）。 應用場景： 一年一度的天貓雙11限時搶購，使用者同時點選搶購， 洶湧澎湃的流量可能導

guava 限流的兩種方式

版權宣告： https://blog.csdn.net/mengxpFighting/article/details/79117934 java中對於生產者消費者模型，或者小米手機營銷 1分鐘賣多少臺手機等都存在限流的思想在裡面。 關於限流 目前存在兩大類，從執行緒個數（jdk1.5 Se

實戰限流（guava的RateLimiter）

常用的限流演算法有漏桶演算法和令牌桶演算法，guava的RateLimiter使用的是令牌桶演算法，也就是以固定的頻率向桶中放入令牌，例如一秒鐘10枚令牌，實際業務在每次響應請求之前都從桶中獲取令牌，只有取到令牌的請求才會被成功響應，獲取的方式有兩種：阻塞等待令牌或者取不到立

限流模式-Guava的RateLimiter

目前有幾種常見的限流方式： 1、通過限制單位時間段內呼叫量來限流 2、通過限制系統的併發呼叫程度來限流 3、使用漏桶（Leaky Bucket）演算法來進行限流 4、使用令牌桶（Token Bucket）演算法來進行限流 具體我們看下第三種和第四中演算法，也是我們目前看

Guava的RateLimiter限流器分析

RateLimiter 演算法原理 RateLimiter 從概念上來講，速率限制器會在可配置的速率下分配許可證。如果必要的話，每個acquire() 會阻塞當前執行緒直到許可證可用後獲取該許可證。一旦獲取到許可證，不需要再釋放許可證。 使用案例 Ra

RateLimit--使用guava來做介面限流

一、問題描述   　　某天A君突然發現自己的介面請求量突然漲到之前的10倍，沒多久該介面幾乎不可使用，並引發連鎖反應導致整個系統崩潰。如何應對這種情況呢？生活給了我們答案：比如老式電閘都安裝了保險絲，一旦有人使用超大功率的裝置，保險絲就會燒斷以保護各個電器不被強

【Guava】使用Guava的RateLimiter做限流

一、常見的限流演算法 目前常用的限流演算法有兩個：漏桶演算法和令牌桶演算法。 1.漏桶演算法 漏桶演算法的原理比較簡單，請求進入到漏桶中，漏桶以一定的速率漏水。當請求過多時，水直接溢位。可以看出，漏桶演算法可以強制限制資料的傳輸速度。 2.令

Guava RateLimiter + AOP註解實現單機限流、統計QPS

1、基於springboot專案pom.xml新增如下依賴： <dependency> <group

常用限流演算法與Guava RateLimiter原始碼解析

在分散式系統中，應對高併發訪問時，快取、限流、降級是保護系統正常執行的常用方法。當請求量突發暴漲時，如果不加以限制訪問，則可能導致整個系統崩潰，服務不可用。同時有一些業務場景，比如簡訊驗證碼，或者其它第三方API呼叫，也需要提供必要的訪問限制支援。還有一些資源消耗過大的請求，比如資料匯出等（參考 [記一次線上

限流、消峰的三種辦法

鏈接 png ret unit 做了 pan mit append vertex 互聯網服務賴以生存的根本是流量, 產品和運營會經常通過各種方式來為應用倒流,比如淘寶的雙十一等,如何讓系統在處理高並發的同時還是保證自身系統的穩定,通常在最短時間內提高並發的做法就是加機器,

Nginx 限流(請求數)

pan rst 沒有 con 空間大小 限流 ssi 請求 status limit_req_zone 用於設置每個IP在單位時間內所允許發起的請求數，值 zone=rate=10r/s 表示每個IP每秒只允許發起10個請求。limit_req的作用類似與緩沖區，用於緩存還