1. 程式人生 > >RateLimit--使用guava來做介面限流

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

一、問題描述  

  某天A君突然發現自己的介面請求量突然漲到之前的10倍,沒多久該介面幾乎不可使用,並引發連鎖反應導致整個系統崩潰。如何應對這種情況呢?生活給了我們答案:比如老式電閘都安裝了保險絲,一旦有人使用超大功率的裝置,保險絲就會燒斷以保護各個電器不被強電流給燒壞。同理我們的介面也需要安裝上“保險絲”,以防止非預期的請求對系統壓力過大而引起的系統癱瘓,當流量過大時,可以採取拒絕或者引流等機制。 

二、常用的限流演算法

      常用的限流演算法有兩種:漏桶演算法和令牌桶演算法,這篇博文介紹得比較清晰(過載保護演算法淺析)。

      漏桶演算法思路很簡單,請求先進入到漏桶裡,漏桶以一定的速度出水,當水請求過大會直接溢位,可以看出漏桶演算法能強行限制資料的傳輸速率。


圖1 漏桶演算法示意圖

      對於很多應用場景來說,除了要求能夠限制資料的平均傳輸速率外,還要求允許某種程度的突發傳輸。這時候漏桶演算法可能就不合適了,令牌桶演算法更為適合。如圖2所示,令牌桶演算法的原理是系統會以一個恆定的速度往桶裡放入令牌,而如果請求需要被處理,則需要先從桶裡獲取一個令牌,當桶裡沒有令牌可取時,則拒絕服務。


圖2 令牌桶演算法示意圖

三、限流工具類RateLimiter

   google開源工具包guava提供了限流工具類RateLimiter,該類基於“令牌桶演算法”,非常方便使用。該類的介面描述請參考:RateLimiter介面描述

,具體的使用請參考:RateLimiter使用實踐

RateLimiter 使用Demo

package ratelimite;

import com.google.common.util.concurrent.RateLimiter;
 
public class RateLimiterDemo {
    public static void main(String[] args) {
    	testNoRateLimiter();
    	testWithRateLimiter();
    }
 
    public static void testNoRateLimiter() {
    	Long start = System.currentTimeMillis();
        for (int i = 0; i < 10; i++) {
            System.out.println("call execute.." + i);
            
        }
        Long end = System.currentTimeMillis();
        
        System.out.println(end - start);
        
    }
    
    public static void testWithRateLimiter() {
    	Long start = System.currentTimeMillis();
        RateLimiter limiter = RateLimiter.create(10.0); // 每秒不超過10個任務被提交
        for (int i = 0; i < 10; i++) {
            limiter.acquire(); // 請求RateLimiter, 超過permits會被阻塞
            System.out.println("call execute.." + i);
            
        }
        Long end = System.currentTimeMillis();
        
        System.out.println(end - start);
        
    }
    
}
 


四 Guava併發:ListenableFuture與RateLimiter示例

概念

        ListenableFuture顧名思義就是可以監聽的Future,它是對java原生Future的擴充套件增強。我們知道Future表示一個非同步計算任務,當任務完成時可以得到計算結果。如果我們希望一旦計算完成就拿到結果展示給使用者或者做另外的計算,就必須使用另一個執行緒不斷的查詢計算狀態。這樣做,程式碼複雜,而且效率低下。使用ListenableFuture Guava幫我們檢測Future是否完成了,如果完成就自動呼叫回撥函式,這樣可以減少併發程式的複雜度。

        推薦使用第二種方法,因為第二種方法可以直接得到Future的返回值,或者處理錯誤情況。本質上第二種方法是通過調動第一種方法實現的,做了進一步的封裝。

另外ListenableFuture還有其他幾種內建實現:

  1. SettableFuture:不需要實現一個方法來計算返回值,而只需要返回一個固定值來做為返回值,可以通過程式設定此Future的返回值或者異常資訊

  2. CheckedFuture: 這是一個繼承自ListenableFuture介面,他提供了checkedGet()方法,此方法在Future執行發生異常時,可以丟擲指定型別的異常。

    RateLimiter類似於JDK的訊號量Semphore,他用來限制對資源併發訪問的執行緒數,本文介紹RateLimiter使用

程式碼示例

?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78

相關推薦

RateLimit--使用guava介面

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

使用Guava-RateLimiter介面

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

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

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

使用before_request和用戶檢查

before restfu def 權限 end rule 集中 for nbsp 因為使用restful方式,因此每次用戶訪問都會上傳帶入auth_key,如jwt等,因此可在@app.before_request中做權限的檢查。 @app.app.befo

c# 反射打開窗臺 可根據命名空間

強制轉換 user sem eat ont sof exec for nbsp Assembly assembly = Assembly.GetExecutingAssembly(); // 實例化窗體 //User

Java 介面

目錄: 限流原理 知識點 具體實現 結語   內容: 1、限流原理 -- 令牌桶演算法  令牌桶演算法的原理是系統會以一個恆定的速度(每秒生成一個令牌)往桶裡放入令牌。當有訪問者(針對於 IP)要訪問介面時,則需要先從桶裡獲取一個令

SpringBoot基於RateLimiter+AOP動態的為不同介面

1.首先介面限流演算法:       1.計數器方式(傳統計數器缺點:臨界問題 可能違背定義固定速率原則)      2.令牌桶方式           

微服務介面的設計、思考

微服務拆分之後,系統之間的呼叫關係錯綜複雜,平臺的整體複雜熵升高,出錯的概率、debug 問題的難度都高了好幾個數量級。所以,服務治理便成了微服務的一個技術重點。服務治理本身的概念比較大,包括鑑權、限流、降級、熔斷、監控告警等等,本文聚焦於限流,根據筆者的實戰經驗,分享一些對微服務介面限流的思考。

微服務介面設計與思考

服務治理本身的概念比較大,包括鑑權、限流、降級、熔斷、監控告警等等,本文聚焦於限流,分享一些對微服務介面限流的思考。 本文試圖講清楚以下問題: 如何對介面選擇合適的限流時間粒度和最大限流值? 如何驗證微服務介面限流功能的有效性和正確性? 如何打造高

介面演算法:漏桶演算法&令牌桶演算法

工作中對外提供的API 介面設計都要考慮限流,如果不考慮限流,會成系統的連鎖反應,輕者響應緩慢,重者系統宕機,整個業務線崩潰,如何應對這種情況呢,我們可以對請求進行引流或者直接拒絕等操作,保持系統的可用性和穩定性,防止因流量暴增而導致的系統執行緩慢或宕機。 在

Guava-RateLimiter秒殺技術詳解

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

【本人禿頂程式設計師】介面演算法之漏桶演算法&令牌桶演算法

←←←←←←←←←←←← 快,點關注! 工作中對外提供的API 介面設計都要考慮限流,如果不考慮限流,會成系統的連鎖反應,輕者響應緩慢,重者系統宕機,整個業務線崩潰,如何應對這種情況呢,我們可以對請求進行引流或者直接拒絕等操作,保持系統的可用性和穩定性,防止因流量暴增而導致的系統執行緩慢

定義攔截器,介面防刷

一、自定義註解package com.mydre.miaosha.access;import java.lang.annotation.ElementType;import java.lang.annotation.Retention;import java.lang.ann

SpringBoot(20)之高併發介面優化-------秒殺介面地址隱藏 + 驗證碼驗證 +介面防刷

SpringBoot學習之高併發介面優化—–秒殺介面地址隱藏(驗證碼)+介面限流防刷 秒殺介面地址隱藏 思路:秒殺開始之前,先去請求介面獲取秒殺地址。 - 介面改造,帶上PathVariable引數 - 新增生成地址的介面 - 秒殺收到請求,先驗證

高併發之API介面

   在開發高併發系統時有三把利器用來保護系統:快取、降級和限流 快取 快取的目的是提升系統訪問速度和增大系統處理容量 降級 降級是當服務出現問題或者影響到核心流程時,需要暫時遮蔽掉,待高峰或者問題解決後再開啟 限流 限流的目的是通過對併發訪問/請求進行限速,或者對一個

Spring Cloud Gateway 原生的介面該怎麼玩

作者:冷冷gg來源:https://my.oschina.net/giegie/blog/183

技巧:Chrome測試外掛——使用Restlet Client 介面測試

最近發現一款非常不錯的測試外掛,在chrome上擴充套件程式(需要科學上網),搜尋Restlet Client 安裝即可。 這款外掛可以將你每次測試的方式儲存下來而且會有錯誤資訊的輸出。 最重要是的可以模擬post和get請求並且傳引數自選輸入,用來

高併發處理之介面

最近開發的搶購活動上線後發現了兩個比較明顯的問題,其一:活動一開始,介面訪問量劇增;其二:黑名單中增加了一大批黑名單使用者(或者說IP),這其中就包含了一些惡意使用者或機器人刷介面。 針對一些高併發的介面,限流是處理高併發的幾大利劍之一。一方面,限流可以防止介面被刷,造成不

介面演算法:漏桶演算法和令牌桶演算法

漏桶演算法 漏桶可以看作是一個帶有常量服務時間的單伺服器佇列,如果漏桶(包快取)溢位,那麼資料包會被丟棄。這一點和執行緒池原理是很

介面看這一篇就夠了!!!

## 導讀 - 前幾天和一個朋友討論了他們公司的系統問題,傳統的單體應用,叢集部署,他說近期服務的併發量可能會出現瞬時增加的風險,雖然部署了叢集,但是通過壓測後發現請求延遲仍然是很大,想問問我有什麼改進的地方。我沉思了一會,現在去改架構顯然是不可能的,於是我給出了一個建議,讓他去做個介面限流,這樣能夠保證瞬