[[346652]]

本文轉(zhuǎn)載自微信公眾號(hào)「腦子進(jìn)煎魚了」，作者陳煎魚 。轉(zhuǎn)載本文請(qǐng)聯(lián)系腦子進(jìn)煎魚了公眾號(hào)。   

前言

理論上每一個(gè)對(duì)外/內(nèi)提供功能的資源點(diǎn)，都需要進(jìn)行一定的流量控制，否則在業(yè)務(wù)的持續(xù)迭代中，是有可能出現(xiàn)突發(fā)性流量的場(chǎng)景(就像年初所帶來的一些行業(yè)突發(fā)轉(zhuǎn)變，導(dǎo)致業(yè)務(wù)流量突然暴增)：

突發(fā)流量

若沒有進(jìn)行限流，就會(huì)出現(xiàn)一些奇奇怪怪的問題點(diǎn)，實(shí)則就是系統(tǒng)無(wú)法承受這波流量，逐漸崩潰，走向系統(tǒng)假死。

現(xiàn)實(shí)場(chǎng)景

最常見的現(xiàn)實(shí)場(chǎng)景就是日常隨處可見的排插、插座，其內(nèi)置的保險(xiǎn)絲，也被稱為電流保險(xiǎn)絲，其主要是起過載保護(hù)作用，保險(xiǎn)絲會(huì)在電流異常升高到一定的高度和熱度的時(shí)候，自身熔斷切斷電流，從而起到保護(hù)電路安全運(yùn)行的作用。

因此真實(shí)世界中有許多與軟件工程中的限流熔斷的場(chǎng)景有異曲同工之處，也是為了控制量，超量就切斷。你也可以想想現(xiàn)實(shí)生活中是否有遇到其他類似的例子呢?

[[346653]]

保險(xiǎn)絲(圖來自網(wǎng)絡(luò))

漏桶算法(Leaky Bucket)

漏桶算法(Leaky Bucket)是網(wǎng)絡(luò)中流量整形(Traffic Shaping)或速率限制(Rate Limiting)時(shí)常用的一種算法，它的主要目的是控制數(shù)據(jù)注入到網(wǎng)絡(luò)的速率，平滑網(wǎng)絡(luò)上的突發(fā)流量。

漏桶算法通過其算法調(diào)控了流量訪問，使得突發(fā)流量可以被整形，去毛刺，變成一個(gè)相對(duì)緩和，以便為網(wǎng)絡(luò)提供一個(gè)穩(wěn)定的流量。

漏桶算法的存儲(chǔ)桶主要由三個(gè)參數(shù)定義，分別是：桶的容量、水從桶中流出的速率、桶的初始充滿度。

其核心理念就如字面意思：一個(gè)會(huì)漏水的桶。

圖片來自 geeksforgeeks

Bursty Flow

在上圖中，水龍頭代表著突發(fā)流量(Bursty Flow)。當(dāng)網(wǎng)絡(luò)中存在突發(fā)流量，且無(wú)任何調(diào)控時(shí)，就會(huì)出現(xiàn)像 Bursty Data 處類似的場(chǎng)景。主機(jī)以 12 Mbps 的速率發(fā)送數(shù)據(jù)，時(shí)間持續(xù) 2s，總計(jì) 24 Mbits 數(shù)據(jù)。隨后主機(jī)暫停發(fā)送 5s，然后再以 2 Mbps 的速率發(fā)送數(shù)據(jù) 3s，最終總共發(fā)送了 6 Mbits 的數(shù)據(jù)。

因此主機(jī)在 10s 內(nèi)總共發(fā)送了 30 Mbits 的數(shù)據(jù)。但這里存在一個(gè)問題，就是數(shù)據(jù)的發(fā)送并不是平滑的，存在一個(gè)較大的波峰。若所有流量都是如此的傳輸方式，將會(huì) “旱的旱死澇的澇死”，對(duì)系統(tǒng)并不是特別的友好。

Fixed Flow

為了解決 Bursty Flow 場(chǎng)景的問題。漏桶(Leaky Bucket)出現(xiàn)了，漏桶具有固定的流出速率、固定的容量大小。

在上圖中，漏桶在相同的 10s 內(nèi)以 3 Mbps 的速率持續(xù)發(fā)送數(shù)據(jù)來平滑流量。若水(流量)來的過猛，但水流(漏水)不夠快時(shí)，其最終結(jié)果就是導(dǎo)致水直接溢出，呈現(xiàn)出來就是拒絕請(qǐng)求/排隊(duì)等待的表現(xiàn)。另外當(dāng) Buckets 空時(shí)，是會(huì)出現(xiàn)一次性倒入達(dá)到 Bucket 容量限制的水的可能性，此時(shí)也可能會(huì)出現(xiàn)波峰。

簡(jiǎn)單來講就是，一個(gè)漏桶，水流進(jìn)來，但漏桶只有固定的流速來流出水，若容量滿即拒絕，否則將持續(xù)保持流量流出。

令牌桶算法

令牌桶算法也是網(wǎng)絡(luò)中流量整形或速率限制時(shí)常用的一種算法，它的主要目的是控制發(fā)送到網(wǎng)絡(luò)上的數(shù)據(jù)的數(shù)目，并允許突發(fā)數(shù)據(jù)的發(fā)送。

令牌桶算法會(huì)以一個(gè)恒定的速率向桶里放入令牌，如果有新的請(qǐng)求進(jìn)來希望進(jìn)行處理，則必須要先從桶內(nèi)拿到一個(gè)可用的令牌，才能繼續(xù)被處理。若桶內(nèi)無(wú)令牌可取時(shí)，則拒絕請(qǐng)求/排隊(duì)等待。

圖片來自 gateoverflow

1. 每 1/r 秒新增一個(gè) token 到 buckets 中。
2. buckets 中最多可容納 b 個(gè)令牌。如果桶已滿，將丟棄這個(gè)新增的 token(也就是不需要新的 token)。
3. 當(dāng)主機(jī)傳輸 n bytes packets 時(shí)，buckets 中如果有 n 個(gè)令牌，則取到所需令牌，成功傳輸 n bytes。
4. 當(dāng)可用的 token 小于 n bytes 時(shí)，不會(huì)從 buckets 中取到任何 token，本次請(qǐng)求將被拒絕/排隊(duì)等待。

漏桶 vs 令牌桶

漏桶算法和令牌桶算法本質(zhì)上都是為了做流量整形(Traffic Shaping)或速率限制(Rate Limiting)，避免系統(tǒng)因?yàn)榇罅髁慷淮虮溃珒烧吆诵牟町愒谟谙蘖鞯姆较蚴窍喾吹摹?/p>

令牌桶限制的是流量的平均流入速率，并且允許一定程度的突然性流量，最大速率為桶的容量和生成 token 的速率。而漏桶限制的是流量的流出速率，是相對(duì)固定的。

因此也會(huì)相對(duì)的帶來一個(gè)問題，在某些場(chǎng)景中，漏桶算法并不能有效的使用網(wǎng)絡(luò)資源，因?yàn)槁┩暗穆┏鏊俾适窍鄬?duì)固定的，所以在網(wǎng)絡(luò)情況比較好，沒有擁塞的狀態(tài)下，漏桶依然是限制住的，并沒有辦法放開量。而令牌桶算法則不同，其能夠是限制平均速率的同時(shí)支持一定程度的突發(fā)流量。

總結(jié)

在軟件系統(tǒng)中，限流常常所代表的就是流量整形、速率限制，是一個(gè)非常常見的調(diào)控手段。一般我們會(huì)將其在初期集成到統(tǒng)一框架、網(wǎng)關(guān)、Mesh 中去。因此建議接觸業(yè)務(wù)的同學(xué)，都要對(duì)這一塊進(jìn)行考量，便于后續(xù)的快速使用/接入，畢竟業(yè)務(wù)的流量爆發(fā)總是來的比較突然，甚至可能是惡意攻擊。

而本文所提到的漏桶，令牌桶都是非常常見的手段，雖然兩者獨(dú)立出來分析了。但從軟件開發(fā)的角度來講，你認(rèn)為兩者是否可以融合，結(jié)合其優(yōu)勢(shì)呢?