溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點(diǎn)擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

雙11的高并發(fā)流量是如何抗住

發(fā)布時(shí)間:2021-09-06 14:59:44 來源:億速云 閱讀:133 作者:Yi 欄目:軟件技術(shù)

雙11的高并發(fā)流量是如何抗住,很多新手對此不是很清楚,為了幫助大家解決這個(gè)難題,下面小編將為大家詳細(xì)講解,有這方面需求的人可以來學(xué)習(xí)下,希望你能有所收獲。

服務(wù)等級協(xié)議

我們常說的 N 個(gè) 9,就是對 SLA 的一個(gè)描述。SLA 全稱是 Service Level Agreement,翻譯為服務(wù)水平協(xié)議,也稱服務(wù)等級協(xié)議,它表明了公有云提供服務(wù)的等級以及質(zhì)量。

例如阿里云對外承諾的就是一個(gè)服務(wù)周期內(nèi)集群服務(wù)可用性不低于 99.99%,如果低于這個(gè)標(biāo)準(zhǔn),云服務(wù)公司就需要賠償客戶的損失。

做到 4 個(gè) 9 夠好了嗎

對互聯(lián)網(wǎng)公司來說,SLA 就是網(wǎng)站或者 API 服務(wù)可用性的一個(gè)保證。

9 越多代表全年服務(wù)可用時(shí)間越長服務(wù)更可靠,4 個(gè) 9 的服務(wù)可用性,聽起來已經(jīng)很高了,但對于實(shí)際的業(yè)務(wù)場景,這個(gè)值可能并不夠。

我們來做一個(gè)簡單的計(jì)算,假設(shè)一個(gè)核心鏈路依賴 20 個(gè)服務(wù),強(qiáng)依賴同時(shí)沒有配置任何降級,并且這 20 個(gè)服務(wù)的可用性達(dá)到 4 個(gè) 9,也就是 99.99%。

那這個(gè)核心鏈路的可用性只有 99.99 的 20 次方=99.8%,如果有 10 億次請求則有 3,000,000 次的失敗請求,理想狀況下,每年還是有 17 小時(shí)服務(wù)不可用。

雙11的高并發(fā)流量是如何抗住

這是一個(gè)理想的估算,在實(shí)際的生產(chǎn)環(huán)境中,由于服務(wù)發(fā)布,宕機(jī)等各種各樣的原因,情況肯定會(huì)比這個(gè)更差。
對于一些比較敏感的業(yè)務(wù),比如金融,或是對服務(wù)穩(wěn)定要求較高的行業(yè),比如訂單或者支付業(yè)務(wù),這樣的情況是不能接受的。

微服務(wù)的雪崩效應(yīng)

雙11的高并發(fā)流量是如何抗住

除了對服務(wù)可用性的追求,微服務(wù)架構(gòu)一個(gè)繞不過去的問題就是服務(wù)雪崩。
在一個(gè)調(diào)用鏈路上,微服務(wù)架構(gòu)各個(gè)服務(wù)之間組成了一個(gè)松散的整體,牽一發(fā)而動(dòng)全身,服務(wù)雪崩是一個(gè)多級傳導(dǎo)的過程。
首先是某個(gè)服務(wù)提供者不可用,由于大量超時(shí)等待,繼而導(dǎo)致服務(wù)調(diào)用者不可用,并且在整個(gè)鏈路上傳導(dǎo),繼而導(dǎo)致系統(tǒng)癱瘓。

限流降級怎么做

如同上面我們分析的,在大規(guī)模微服務(wù)架構(gòu)的場景下,避免服務(wù)出現(xiàn)雪崩,要減少停機(jī)時(shí)間,要盡可能的提高服務(wù)可用性。
提高服務(wù)可用性,可以從很多方向入手,比如緩存、池化、異步化、負(fù)載均衡、隊(duì)列和降級熔斷等手段。

緩存以及隊(duì)列等手段,增加系統(tǒng)的容量。限流和降級則是關(guān)心在到達(dá)系統(tǒng)瓶頸時(shí)系統(tǒng)的響應(yīng),更看重穩(wěn)定性。

緩存和異步等提高系統(tǒng)的戰(zhàn)力,限流降級關(guān)注的是防御。限流和降級,具體實(shí)施方法可以歸納為八字箴言,分別是限流,降級,熔斷和隔離。

限流和降級

限流顧名思義,提前對各個(gè)類型的請求設(shè)置最高的 QPS 閾值,若高于設(shè)置的閾值則對該請求直接返回,不再調(diào)用后續(xù)資源。
限流需要結(jié)合壓測等,了解系統(tǒng)的最高水位,也是在實(shí)際開發(fā)中應(yīng)用最多的一種穩(wěn)定性保障手段。
降級則是當(dāng)服務(wù)器壓力劇增的情況下,根據(jù)當(dāng)前業(yè)務(wù)情況及流量對一些服務(wù)和頁面有策略的降級,以此釋放服務(wù)器資源以保證核心任務(wù)的正常運(yùn)行。
從降級配置方式上,降級一般可以分為主動(dòng)降級和自動(dòng)降級。主動(dòng)降級是提前配置,自動(dòng)降級則是系統(tǒng)發(fā)生故障時(shí),如超時(shí)或者頻繁失敗,自動(dòng)降級。
其中,自動(dòng)降級,又可以分為以下策略:
  • 超時(shí)降級

  • 失敗次數(shù)降級

  • 故障降級

在系統(tǒng)設(shè)計(jì)中,降級一般是結(jié)合系統(tǒng)配置中心,通過配置中心進(jìn)行推送,下面是一個(gè)典型的降級通知設(shè)計(jì)。
雙11的高并發(fā)流量是如何抗住

熔斷隔離

如果某個(gè)目標(biāo)服務(wù)調(diào)用慢或者有大量超時(shí),此時(shí)熔斷該服務(wù)的調(diào)用,對于后續(xù)調(diào)用請求,不在繼續(xù)調(diào)用目標(biāo)服務(wù),直接返回,快速釋放資源。
熔斷一般需要設(shè)置不同的恢復(fù)策略,如果目標(biāo)服務(wù)情況好轉(zhuǎn)則恢復(fù)調(diào)用。
服務(wù)隔離與前面的三個(gè)略有區(qū)別,我們的系統(tǒng)通常提供了不止一個(gè)服務(wù),但是這些服務(wù)在運(yùn)行時(shí)是部署在一個(gè)實(shí)例,或者一臺(tái)物理機(jī)上面的。

如果不對服務(wù)資源做隔離,一旦一個(gè)服務(wù)出現(xiàn)了問題,整個(gè)系統(tǒng)的穩(wěn)定性都會(huì)受到影響!服務(wù)隔離的目的就是避免服務(wù)之間相互影響。

雙11的高并發(fā)流量是如何抗住

一般來說,隔離要關(guān)注兩方面,一個(gè)是在哪里進(jìn)行隔離,另外一個(gè)是隔離哪些資源。

何處隔離:一次服務(wù)調(diào)用,涉及到的是服務(wù)提供方和調(diào)用方,我們所指的資源,也是兩方的服務(wù)器等資源,服務(wù)隔離通常可以從提供方和調(diào)用方兩個(gè)方面入手。

隔離什么:廣義的服務(wù)隔離,不僅包括服務(wù)器資源,還包括數(shù)據(jù)庫分庫,緩存,索引等,這里我們只關(guān)注服務(wù)層面的隔離。

降級和熔斷的區(qū)別

服務(wù)降級和熔斷在概念上比較相近,通過兩個(gè)場景,談?wù)勎易约旱睦斫狻?/section>

熔斷,一般是停止服務(wù):典型的就是股市的熔斷,如果大盤不受控制,直接休市,不提供服務(wù),是保護(hù)大盤的一種方式。

降級,通常是有備用方案:從北京到濟(jì)南,下雨導(dǎo)致航班延誤,我可以乘坐高鐵,如果高鐵票買不到,也可以乘坐汽車或者開車過去。

兩者的區(qū)別:降級一般是主動(dòng)的,有預(yù)見性的,熔斷通常是被動(dòng)的,服務(wù) A 降級以后,一般會(huì)有服務(wù) B 來代替,而熔斷通常是針對核心鏈路的處理。

在實(shí)際開發(fā)中,熔斷的下一步通常就是降級。

常用限流算法設(shè)計(jì)

剛才講了限流的概念,那么怎樣判斷系統(tǒng)到達(dá)設(shè)置的流量閾值了?這就需要一些限流策略來支持,不同的限流算法有不同的特點(diǎn),平滑程度也不同。

計(jì)數(shù)器法

計(jì)數(shù)器法是限流算法里最簡單也是最容易實(shí)現(xiàn)的一種算法。
假設(shè)一個(gè)接口限制一分鐘內(nèi)的訪問次數(shù)不能超過 100 個(gè),維護(hù)一個(gè)計(jì)數(shù)器,每次有新的請求過來,計(jì)數(shù)器加一。

這時(shí)候判斷,如果計(jì)數(shù)器的值小于限流值,并且與上一次請求的時(shí)間間隔還在一分鐘內(nèi),允許請求通過,否則拒絕請求,如果超出了時(shí)間間隔,要將計(jì)數(shù)器清零。

public class CounterLimiter {

    //初始時(shí)間
    private static long startTime = System.currentTimeMillis();

    //初始計(jì)數(shù)值
    private static final AtomicInteger ZERO = new AtomicInteger(0);

    //時(shí)間窗口限制
    private static final long interval = 10000;

    //限制通過請求
    private static int limit = 100;

    //請求計(jì)數(shù)
    private AtomicInteger requestCount = ZERO;

    //獲取限流
    public boolean tryAcquire() {

        long now = System.currentTimeMillis();

        //在時(shí)間窗口內(nèi)
        if (now < startTime + interval) {

            //判斷是否超過最大請求
            if (requestCount.get() < limit) {
                requestCount.incrementAndGet();
                return true;
            }
            return false;

        } else {

            //超時(shí)重置
            startTime = now;
            requestCount = ZERO;
            return true;
        }

    }
}
計(jì)數(shù)器限流可以比較容易的應(yīng)用在分布式環(huán)境中,用一個(gè)單點(diǎn)的存儲(chǔ)來保存計(jì)數(shù)值,比如用 Redis,并且設(shè)置自動(dòng)過期時(shí)間,這時(shí)候就可以統(tǒng)計(jì)整個(gè)集群的流量,并且進(jìn)行限流。
計(jì)數(shù)器方式的缺點(diǎn)是不能處理臨界問題,或者說限流策略不夠平滑。
假設(shè)在限流臨界點(diǎn)的前后,分別發(fā)送 100 個(gè)請求,實(shí)際上在計(jì)數(shù)器置 0 前后的極短時(shí)間里,處理了 200 個(gè)請求,這是一個(gè)瞬時(shí)的高峰,可能會(huì)超過系統(tǒng)的限制。
計(jì)數(shù)器限流允許出現(xiàn) 2*permitsPerSecond 的突發(fā)流量,可以使用滑動(dòng)窗口算法去優(yōu)化,具體不展開。

漏桶算法

假設(shè)我們有一個(gè)固定容量的桶,桶底部可以漏水(忽略氣壓等,不是物理問題),并且這個(gè)漏水的速率可控的,那么我們可以通過這個(gè)桶來控制請求速度,也就是漏水的速度。
我們不關(guān)心流進(jìn)來的水,也就是外部請求有多少,桶滿了之后,多余的水會(huì)溢出。

漏桶算法的示意圖如下:

雙11的高并發(fā)流量是如何抗住

將算法中的水換成實(shí)際應(yīng)用中的請求,可以看到漏桶算法從入口限制了請求的速度。
使用漏桶算法,我們可以保證接口會(huì)以一個(gè)常速速率來處理請求,所以漏桶算法不會(huì)出現(xiàn)臨界問題。

這里簡單實(shí)現(xiàn)一下,也可以使用 Guava 的 SmoothWarmingUp 類,可以更好的控制漏桶算法:

public class LeakyLimiter {

    //桶的容量
    private int capacity;

    //漏水速度
    private int ratePerMillSecond;

    //水量
    private double water;

    //上次漏水時(shí)間
    private long lastLeakTime;

    public LeakyLimiter(int capacity, int ratePerMillSecond) {

        this.capacity = capacity;
        this.ratePerMillSecond = ratePerMillSecond;
        this.water = 0;
    }


    //獲取限流
    public boolean tryAcquire() {

        //執(zhí)行漏水,更新剩余水量
        refresh();

        //嘗試加水,水滿則拒絕
        if (water + 1 > capacity) {
            return false;
        }

        water = water + 1;
        return true;

    }

    private void refresh() {
        //當(dāng)前時(shí)間
        long currentTime = System.currentTimeMillis();

        if (currentTime > lastLeakTime) {

            //距上次漏水的時(shí)間間隔
            long millisSinceLastLeak = currentTime - lastLeakTime;
            long leaks = millisSinceLastLeak * ratePerMillSecond;

            //允許漏水
            if (leaks > 0) {
                //已經(jīng)漏光
                if (water <= leaks) {
                    water = 0;
                } else {
                    water = water - leaks;
                }
                this.lastLeakTime = currentTime;
            }
        }
    }
}

令牌桶算法

漏桶是控制水流入的速度,令牌桶則是控制留出,通過控制 Token,調(diào)節(jié)流量。
假設(shè)一個(gè)大小恒定的桶,桶里存放著令牌(Token)。桶一開始是空的,現(xiàn)在以一個(gè)固定的速率往桶里填充,直到達(dá)到桶的容量,多余的令牌將會(huì)被丟棄。

如果令牌不被消耗,或者被消耗的速度小于產(chǎn)生的速度,令牌就會(huì)不斷地增多,直到把桶填滿。后面再產(chǎn)生的令牌就會(huì)從桶中溢出。

雙11的高并發(fā)流量是如何抗住

最后桶中可以保存的最大令牌數(shù)永遠(yuǎn)不會(huì)超過桶的大小,每當(dāng)一個(gè)請求過來時(shí),就會(huì)嘗試從桶里移除一個(gè)令牌,如果沒有令牌的話,請求無法通過。

public class TokenBucketLimiter {

    private long capacity;
    private long windowTimeInSeconds;
    long lastRefillTimeStamp;
    long refillCountPerSecond;
    long availableTokens;

    public TokenBucketLimiter(long capacity, long windowTimeInSeconds) {
        this.capacity = capacity;
        this.windowTimeInSeconds = windowTimeInSeconds;
        lastRefillTimeStamp = System.currentTimeMillis();
        refillCountPerSecond = capacity / windowTimeInSeconds;
        availableTokens = 0;
    }

    public long getAvailableTokens() {
        return this.availableTokens;
    }

    public boolean tryAcquire() {

        //更新令牌桶
        refill();

        if (availableTokens > 0) {
            --availableTokens;
            return true;
        } else {
            return false;
        }
    }


    private void refill() {
        long now = System.currentTimeMillis();

        if (now > lastRefillTimeStamp) {

            long elapsedTime = now - lastRefillTimeStamp;

            int tokensToBeAdded = (int) ((elapsedTime / 1000) * refillCountPerSecond);

            if (tokensToBeAdded > 0) {
                availableTokens = Math.min(capacity, availableTokens + tokensToBeAdded);
                lastRefillTimeStamp = now;
            }
        }
    }

}
這兩種算法的主要區(qū)別在于漏桶算法能夠強(qiáng)行限制數(shù)據(jù)的傳輸速率,而令牌桶算法在能夠限制數(shù)據(jù)的平均傳輸速率外,還允許某種程度的突發(fā)傳輸。
在令牌桶算法中,只要令牌桶中存在令牌,那么就允許突發(fā)地傳輸數(shù)據(jù)直到達(dá)到用戶配置的門限,因此它適合于具有突發(fā)特性的流量。

漏桶和令牌桶的比較

漏桶和令牌桶算法實(shí)現(xiàn)可以一樣,但是方向是相反的,對于相同的參數(shù)得到的限流效果是一樣的。
主要區(qū)別在于令牌桶允許一定程度的突發(fā),漏桶主要目的是平滑流入速率,考慮一個(gè)臨界場景,令牌桶內(nèi)積累了 100 個(gè) Token,可以在一瞬間通過。
但是因?yàn)橄乱幻氘a(chǎn)生 Token 的速度是固定的,所以令牌桶允許出現(xiàn)瞬間出現(xiàn) permitsPerSecond 的流量,但是不會(huì)出現(xiàn) 2*permitsPerSecond 的流量,漏桶的速度則始終是平滑的。

使用 RateLimiter 實(shí)現(xiàn)限流

Google 開源工具包 Guava 提供了限流工具類 RateLimiter,該類基于令牌桶算法實(shí)現(xiàn)流量限制,使用方便。
RateLimiter 使用的是令牌桶的流控算法,RateLimiter 會(huì)按照一定的頻率往桶里扔令牌,線程拿到令牌才能執(zhí)行。
比如你希望自己的應(yīng)用程序 QPS 不要超過 1000,那么 RateLimiter 設(shè)置 1000 的速率后,就會(huì)每秒往桶里扔 1000 個(gè)令牌,看下方法的說明:

雙11的高并發(fā)流量是如何抗住

RateLimter 提供的 API 可以直接應(yīng)用,其中 acquire 會(huì)阻塞,類似 JUC 的信號(hào)量 Semphore,tryAcquire 方法則是非阻塞的:

public class RateLimiterTest {

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

        //允許10個(gè),permitsPerSecond
        RateLimiter limiter = RateLimiter.create(10);

        for(int i=1;i<20;i++){
            if (limiter.tryAcquire(1)){
                System.out.println("第"+i+"次請求成功");
            }else{
                System.out.println("第"+i+"次請求拒絕");
            }
        }
    }
}

總結(jié)

本文從服務(wù)可用性開始,分析了在業(yè)務(wù)高峰期通過限流降級保障服務(wù)高可用的重要性。

看完上述內(nèi)容是否對您有幫助呢?如果還想對相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章,請關(guān)注億速云行業(yè)資訊頻道,感謝您對億速云的支持。

向AI問一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI