業(yè)務(wù)專(zhuān)線：15989169178
在開(kāi)發(fā)高并發(fā)系統(tǒng)的時(shí)候，我們一般通過(guò)三種方式去保障系統(tǒng)服務(wù)穩(wěn)定：服務(wù)降級(jí)、服務(wù)限流和緩存。對(duì)于緩存在實(shí)際開(kāi)發(fā)中使用的比較多，這個(gè)是大家的共識(shí)沒(méi)有什么異議的。今天我們的主角是服務(wù)限流，在此之前我們先來(lái)看下服務(wù)限流 和 服務(wù)降級(jí) 的區(qū)別：
服務(wù)降級(jí)
服務(wù)降級(jí)是在服務(wù)器壓力陡增的情況下，利用現(xiàn)有的資源，關(guān)閉一些服務(wù)接口或者頁(yè)面，以此來(lái)釋放服務(wù)器資源保證核心任務(wù)的正常運(yùn)行。
服務(wù)限流
限流本質(zhì)上是減少流量的訪問(wèn)，而服務(wù)的處理能力不變；而對(duì)于服務(wù)降級(jí)來(lái)說(shuō)是降低了部分服務(wù)的處理能力，增加另一部分服務(wù)處理能力，訪問(wèn)量不變。
本篇文章中說(shuō)到的服務(wù)限流不是 nginx 層面的限流，而是業(yè)務(wù)代碼中的邏輯限流。
那么，我們?yōu)槭裁匆?wù)限流？
從服務(wù)調(diào)用方來(lái)說(shuō)，可以把服務(wù)簡(jiǎn)單的劃分為以下幾種類(lèi)型的服務(wù)
1.與用戶打交道的服務(wù)
比如 web 服務(wù)，對(duì)外 API,這種類(lèi)型的服務(wù)有以下幾種可能會(huì)導(dǎo)致服務(wù)器壓力變大：
用戶增長(zhǎng)過(guò)快
熱點(diǎn)事件
惡意的攻擊/刷單
爬蟲(chóng)
這些情況都是無(wú)法預(yù)知的，我們不知道什么時(shí)候請(qǐng)求流量會(huì)突增，如果真的要是碰到這種情況，擴(kuò)容根本是來(lái)不及的
2.對(duì)內(nèi)的 RPC 服務(wù)
一個(gè)服務(wù) A 的接口可能會(huì)被其他 BCDE 多個(gè)服務(wù)調(diào)用，如果其中一個(gè)服務(wù)的流量突增比如 B 服務(wù)，導(dǎo)致 A 服務(wù)壓力變大甚至掛掉，那么這個(gè)時(shí)候也不能給 CDE 服務(wù)提供服務(wù)。
這種情況在實(shí)際開(kāi)發(fā)中時(shí)常發(fā)生。
常見(jiàn)的限流算法
下面我們來(lái)看幾種實(shí)際業(yè)務(wù)場(chǎng)景中常用的幾種限流算法：計(jì)數(shù)器算法、漏桶算法、令牌桶算法。
計(jì)數(shù)器算法
計(jì)數(shù)器算法應(yīng)該是最簡(jiǎn)單，最容易想到的限流策略。限流的本質(zhì)是限制某一個(gè) API 在某個(gè)維度單位時(shí)間內(nèi)處理請(qǐng)求的次數(shù)。我們可以設(shè)置一個(gè)計(jì)數(shù)器對(duì)某一時(shí)間段內(nèi)的請(qǐng)求進(jìn)行計(jì)數(shù)，當(dāng)請(qǐng)求量超過(guò)事先設(shè)定好的閾值，拒絕用戶的請(qǐng)求。比如限流的 QPS 是100，算法的實(shí)現(xiàn)思路是從第一個(gè)請(qǐng)求進(jìn)來(lái)開(kāi)始計(jì)數(shù)，在接下來(lái)的 1s 內(nèi)，每來(lái)一個(gè)請(qǐng)求計(jì)數(shù)器自動(dòng)加 1，如果累加的數(shù)字超過(guò) 100，那么后續(xù)的請(qǐng)求就會(huì)被拒絕，等到 1s 結(jié)束后，計(jì)數(shù)器開(kāi)始重置為 0，重新開(kāi)始計(jì)數(shù)。
這種方式存在弊端
弊端1：如果在 1s 的前 10ms 請(qǐng)求數(shù)已經(jīng)達(dá)到了 100，那么剩下的 990ms，服務(wù)調(diào)用方就要眼巴巴的看著請(qǐng)求被拒絕。
弊端2：如果有一個(gè)惡意的用戶在 999ms 的時(shí)候瞬間發(fā)送了 100 次請(qǐng)求，并且又在 1000ms 時(shí)瞬間發(fā)送了 100 次請(qǐng)求，那么其實(shí)這個(gè)用戶在 1s 內(nèi)發(fā)送了 200 次請(qǐng)求。利用時(shí)間窗口的重置節(jié)點(diǎn)處突發(fā)請(qǐng)求，可以瞬間超過(guò)我們服務(wù)本身能承受的壓力，瞬間壓垮服務(wù)。
針對(duì)計(jì)數(shù)器算法的漏洞一個(gè)比較經(jīng)典的處理方案是采用 滑動(dòng)窗口。比如我們把上面的 1min 內(nèi) 100 次請(qǐng)求上限看成是一個(gè)大的時(shí)間窗口，然后把這個(gè)窗口進(jìn)一步細(xì)分，比如每 10 s 一個(gè)小窗口，該窗口的頻率上限同樣設(shè)置成 100，這樣大窗口包含 16 個(gè)小窗口，并且每過(guò) 10s 大窗口就移動(dòng)一個(gè)小窗口長(zhǎng)度。如果一個(gè)惡意用戶在 09:59:30~09:59:59 之間發(fā)送了 100 次請(qǐng)求，等到了10:00:00~10:00:30 時(shí) 100 次計(jì)數(shù)仍然是有效的，所以，這個(gè)時(shí)間段新的請(qǐng)求仍然會(huì)被拒絕。
漏桶算法
漏桶算法是限流方面比較經(jīng)典的算法。可以把該算法聯(lián)想成一個(gè)具體的漏桶模型，漏桶始終以一個(gè)恒定的速率往外排水，如果桶被裝滿的話則后來(lái)涌入的水會(huì)溢出。對(duì)應(yīng)到接口限流來(lái)說(shuō)，用戶的請(qǐng)求可以看做是水，不管用戶的請(qǐng)求量有多大多不均衡，能夠被處理的請(qǐng)求速率是恒定的，而且能夠接受的請(qǐng)求數(shù)也是有上限的，超出上限的請(qǐng)求會(huì)被拒絕，在算法實(shí)現(xiàn)方面可以準(zhǔn)備一個(gè)隊(duì)列來(lái)作為漏桶的實(shí)現(xiàn)，用這個(gè)隊(duì)列保存請(qǐng)求，通過(guò)一個(gè)線程池定期從隊(duì)列中獲取請(qǐng)求并執(zhí)行，也可以一次性獲取多個(gè)并發(fā)請(qǐng)求，如下圖：
漏桶算法也存在一個(gè)弊端：無(wú)法應(yīng)對(duì)短時(shí)間的突發(fā)流量
令牌桶算法
在令牌桶算法中，存在一個(gè)桶，用來(lái)存放固定數(shù)量的令牌。算法中存在一種機(jī)制，以一定的速率往桶中放令牌。每次請(qǐng)求調(diào)用需要先獲取令牌，只有拿到令牌才有機(jī)會(huì)繼續(xù)執(zhí)行，否則請(qǐng)求選擇等待或者服務(wù)直接拒絕請(qǐng)求。
放令牌這個(gè)動(dòng)作是持續(xù)不斷的進(jìn)行，如果桶中令牌數(shù)量達(dá)到上限，就丟棄令牌，所以，會(huì)存在這樣的一種情況，桶中一直有大量的令牌，這時(shí)進(jìn)來(lái)的請(qǐng)求就可以直接拿到令牌執(zhí)行。比如我們把 QPS 設(shè)置成 100，那么限流器完成初始化 1s 后，桶中已經(jīng)有 100 個(gè)令牌，這時(shí)候服務(wù)還未完全啟動(dòng)好，等啟動(dòng)完成功對(duì)外提供服務(wù)時(shí)，該限流器可以抵擋瞬時(shí)的 100 個(gè)請(qǐng)求。所以，當(dāng)桶中沒(méi)有令牌時(shí)請(qǐng)求才會(huì)等待或者被拒絕，當(dāng)沒(méi)有請(qǐng)求申請(qǐng)令牌時(shí)，那么這個(gè)令牌桶會(huì)溢出。在這里令牌桶類(lèi)似一個(gè) buffer,請(qǐng)求密度比較低或者處于冷卻狀態(tài)下，令牌桶會(huì)溢出，當(dāng)請(qǐng)求流量突增時(shí)，則過(guò)去積累的結(jié)余資源直接可以拿來(lái)借用，從這里可以看出這點(diǎn)彌補(bǔ)了漏桶算法的不足。
實(shí)現(xiàn)思路：可以準(zhǔn)備一個(gè)隊(duì)列，用于存放令牌，另外通過(guò)一個(gè)線程池定期生成令牌存放到隊(duì)列中，沒(méi)來(lái)一個(gè)請(qǐng)求就從隊(duì)列中取出一個(gè)令牌，并繼續(xù)執(zhí)行。
上面我們提到的限流算法主要是針對(duì)于單機(jī)限流，實(shí)際業(yè)務(wù)場(chǎng)景更加的復(fù)雜，業(yè)務(wù)的需求五花八門(mén)，簡(jiǎn)單的單機(jī)限流很難滿足需求。
比如為了限制某個(gè)資源被某個(gè)用戶訪問(wèn)的次數(shù)，10 s 只能訪問(wèn) 3 次，或者一天只能訪問(wèn) 100 次，這種需求通過(guò)單機(jī)限流是無(wú)法實(shí)現(xiàn)的，這時(shí)就需要通過(guò)集群限流的方式實(shí)現(xiàn)。
如何實(shí)現(xiàn)?為了實(shí)現(xiàn)對(duì)訪問(wèn)次數(shù)的限制，肯定需要一個(gè)計(jì)數(shù)器，那么我們需要把這個(gè)計(jì)數(shù)器放在哪里呢？因?yàn)檫@個(gè)限流是在集群層面實(shí)現(xiàn)的，集群形式存在的情況才需要分布式限流，由于 redis 天生對(duì)分布式支持非常友好，所以 redis 成了一個(gè)很好的選擇。
大致思路：每次有相關(guān)的操作時(shí)候，我們就向 redis 服務(wù)器發(fā)送一個(gè) incr 命令。比如限制某個(gè)用戶訪問(wèn)接口的次數(shù)，當(dāng)用戶請(qǐng)求過(guò)來(lái)時(shí)我們使用用戶 ID 和 接口名稱生成對(duì)應(yīng) key,每次該用戶訪問(wèn)這個(gè)接口時(shí)，只需要對(duì)這個(gè) key 增加 1，并且給這個(gè) key 設(shè)置有效期，這樣就可以簡(jiǎn)單的實(shí)現(xiàn)指定時(shí)間內(nèi)的訪問(wèn)效率。
