設(shè)定一個場景，假如一個商品接口在某段時間突然上升，會怎么辦？

生活中的例子來說，假設(shè)冰墩墩在當(dāng)天晚上上熱搜之后，迅速有十幾萬人去淘寶下單購買，此時并沒有做好對該商品的緩存預(yù)熱以及準(zhǔn)備，如何操作？

對于這個問題，在電商高并發(fā)系統(tǒng)中，對接口的保護一般采用：緩存、限流、降級 來操作。

假設(shè)該接口已經(jīng)接受過風(fēng)控的處理，過濾掉一半的機器人腳本請求，剩下都是人為的下單請求。

服務(wù)限流

限流 主要的目的是通過對并發(fā)訪問/請求進行限速，或者對一個時間窗口內(nèi)的請求進行限速，一旦達(dá)到限制速率則可以拒絕服務(wù)、排隊或等待、降級等處理。

限流算法

1. 漏斗算法

漏桶算法 是當(dāng)請求到達(dá)時直接放入漏桶，如果當(dāng)前容量已達(dá)到上限（限流值），則進行丟棄或其他策略（觸發(fā)限流策略）。漏桶以固定的速率（根據(jù)服務(wù)吞吐量）進行釋放訪問請求（即請求通過），直到漏桶為空。

漏斗算法的思想就是，不管你來多少請求，我的接口消費速度一定是小于等于流出速率的閾值的。

可以基于消息隊列來實現(xiàn)。

2. 令牌桶算法

令牌桶算法 是程序以v（v = 時間周期 / 限流值）的速度向令牌桶中增加令牌，直到令牌桶滿，請求到達(dá)時向令牌桶請求令牌，如果獲取成功則通過請求，如果獲取失敗觸發(fā)限流策略。

令牌桶算法和漏斗算法的思想差別在于，前者可以允許突發(fā)請求的發(fā)生。

3. 滑窗算法

滑窗算法 是將一個時間周期分為N個小周期，分別記錄每個小周期內(nèi)訪問次數(shù)，并且根據(jù)時間滑動刪除過期的小周期。

如下圖所示，假設(shè)時間周期為1分鐘，將1分鐘再分為2個小周期，統(tǒng)計每個小周期的訪問數(shù)量，則可以看到，第一個時間周期內(nèi)，訪問數(shù)量為75，第二個時間周期內(nèi)，訪問數(shù)量為100，如果一個時間周期內(nèi)所有的小周期總和超過100的話，則會觸發(fā)限流策略。

Sentinel的實現(xiàn) 和 TCP滑窗。

接入層限流

Nginx限流

Nginx 限流采用的是漏桶算法。

它可以根據(jù)客戶端特征，限制其訪問頻率，客戶端特征主要指 IP、UserAgent等。使用 IP 比 UserAgent 更可靠，因為 IP 無法造假，UserAgent 可隨意偽造。

本地接口限流

Semaphore

Java 并發(fā)庫 的 Semaphore 可以很輕松完成信號量控制，Semaphore 可以控制某個資源可被同時訪問的個數(shù)，通過 acquire() 獲取一個許可，如果沒有就等待，而 release() 釋放一個許可。

假如我們對外提供一個服務(wù)接口，允許最大并發(fā)數(shù)為40，我們可以這樣：

privatefinalSemaphorepermit=newSemaphore(40,true);

publicvoidprocess(){

try{
permit.acquire();
//TODO處理業(yè)務(wù)邏輯

}catch(InterruptedExceptione){
e.printStackTrace();
}finally{
permit.release();
}
}

具體的 Semaphore 實現(xiàn)參考源碼。

分布式接口限流

使用消息隊列

不管是用MQ中間件，或是Redis的List實現(xiàn)的消息隊列，都可以作為一個 緩沖隊列 來使用。思想就是基于漏斗算法。

當(dāng)對于一個接口請求達(dá)到一定閾值時，就可以啟用消息隊列來進行接口數(shù)據(jù)的緩沖，并根據(jù)服務(wù)的吞吐量來消費數(shù)據(jù)。

基于 Spring Boot + MyBatis Plus + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

服務(wù)降級

在接口做好風(fēng)控的前提下，發(fā)現(xiàn)了接口請求的并發(fā)量迅速上升，我們可以啟用兜底方案，進行服務(wù)降級。

一般服務(wù)降級應(yīng)該用來對一些 不重要 或 不緊急 的服務(wù)或任務(wù)進行服務(wù)的 延遲使用 或 暫停使用。

降級方案

停止邊緣業(yè)務(wù)

比如淘寶雙11前，就不可以查詢?nèi)齻€月前的訂單，對邊緣業(yè)務(wù)進行降級，保證核心業(yè)務(wù)的高可用。

拒絕請求

在接口請求并發(fā)量大于閾值，或是接口出現(xiàn)大量失敗請求等等突發(fā)情況，可以拒絕一些訪問請求。

拒絕策略

隨機拒絕：隨機拒絕超過閾值的請求 。

拒絕舊請求：按照請求的時間，優(yōu)先拒絕更早收到的請求。

拒絕非核心請求：根據(jù)系統(tǒng)業(yè)務(wù)設(shè)置核心請求清單，將非核心清單內(nèi)的請求拒絕掉。

恢復(fù)方案

在實現(xiàn)服務(wù)降級之后，對于突增流量我們可以繼續(xù)注冊多個消費者服務(wù)來應(yīng)對并發(fā)量，之后我們再對一些服務(wù)器進行慢加載。

降級具體實現(xiàn)參考其他文章。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

數(shù)據(jù)緩存

在接口做好風(fēng)控的前提下，發(fā)現(xiàn)了接口請求的并發(fā)量迅速上升，我們可以分以下幾個操作執(zhí)行：

對訪問請求使用分布式鎖進行阻塞。

在這個短時間中，我們可以將對應(yīng)操作行的熱點數(shù)據(jù)，緩存在緩存中間件中。

放行請求后，讓所有請求優(yōu)先操作緩存數(shù)據(jù)。

再將操作的結(jié)果通過消息隊列發(fā)送給消費接口慢慢消費。

緩存問題

假設(shè)我們操作的是一個庫存接口，此時數(shù)據(jù)庫中只有100個庫存。

那假如此時我們將一條數(shù)據(jù)放入緩存中，如果所有的請求都來訪問這個緩存，那它還是被打掛，我們該怎么操作？

讀寫分離

第一種想法，讀寫分離。

使用Redis的哨兵集群模式來進行主從復(fù)制的讀寫分離操作。讀的操作肯定大于寫操作，等庫存被消費到0時，讀操作直接快速失敗。

負(fù)載均衡

第二種想法，負(fù)載均衡。

在緩存數(shù)據(jù)后，如果所有請求都來緩存中操作這個庫存，不管是加悲觀鎖還是樂觀鎖，并發(fā)率都很低，此時我們可以對這個庫存進行拆分。

我們可以參照 ConcurrentHashMap 中的 counterCells 變量的設(shè)計思想，將100個庫存拆分到10個緩存服務(wù)中，每個緩存服務(wù)有10個緩存，然后我們再對請求進行負(fù)載均衡到各個緩存服務(wù)上。

但是這種方式會有問題，如果大部分用戶被hash到同一個緩存上，導(dǎo)致其他緩存沒有被消費，卻返回沒有庫存，這是不合理的。

page cache

第三種想法，page cache。

大部分軟件架構(gòu)其實都用到了這種方法，比如linux內(nèi)核的硬盤寫入、mysql的刷盤等等，即將短時間內(nèi)的寫操作聚合結(jié)果寫入，所有的寫操作在緩存內(nèi)完成。

審核編輯：湯梓紅