[[337606]]

前言

我們先簡單回顧一下，訂單系統(tǒng)是整個(gè)電商交易平臺(tái)的核心，在它與內(nèi)部模塊、外部第三方系統(tǒng)打交道的過程中，需要完成很多額外的步驟：

• 為用戶積分
• 發(fā)放紅包卡券
• 庫存扣減
• 通知物流系統(tǒng)
• 發(fā)送短信通知

在引入 MQ 后，我們可以讓訂單系統(tǒng)僅僅完成最核心的功能，然后將發(fā)送消息到 MQ。比如需要進(jìn)行減庫存，就發(fā)送一個(gè)消息到庫存消息隊(duì)列中，然后庫存系統(tǒng)從這個(gè) MQ 里獲取消息再進(jìn)行處理就可以，把這些很耗時(shí)的步驟慢慢執(zhí)行，從而也實(shí)現(xiàn)了系統(tǒng)之間的解耦。

但 MQ 還有一個(gè)更加強(qiáng)大的功能：緩沖流量，削峰填谷，諸如雙11這樣的大促活動(dòng)，瞬時(shí)間涌入的大量下單請(qǐng)求有可能直接壓垮服務(wù)器，導(dǎo)致整個(gè)系統(tǒng)的癱瘓，通過使用 MQ 我們可以更好地解決流量突刺的問題。

本文就以秒殺場景為基礎(chǔ)，看完后會(huì)有更清晰的認(rèn)識(shí)。本文將會(huì)從以下幾個(gè)方面來講述相關(guān)知識(shí)，相信大家耐心看了之后肯定有收獲，碼字不易，別忘了「在看」，「轉(zhuǎn)發(fā)」哦。

• 經(jīng)典的秒殺場景
• 流量洪峰帶來的難點(diǎn)
• 使用 MQ 削峰填谷
• 升級(jí)整體架構(gòu)

正文

01 經(jīng)典的秒殺場景

秒殺場景一般出現(xiàn)在類電商的 APP 中，雙十一、618 這種打折大促已經(jīng)屢見不鮮，各種節(jié)日都能成為剁手的理由。

就連饑餓營銷也被各大公司玩的越來越6，像我自己喜歡球鞋，喜歡買AJ和椰子，有過搶鞋經(jīng)歷的同學(xué)一定知道有多痛苦，尤其是每次的結(jié)果都是這張圖。

每年的雙 11 活動(dòng)在零點(diǎn)之后會(huì)開啟一個(gè)特別大的折扣優(yōu)惠，比如前五分鐘下單買五件可以享受三折優(yōu)惠。

全中國無數(shù)的男生女生，在雙 11 之前幾天就會(huì)在購物車精挑細(xì)選大量的商品，零點(diǎn)一到，瘋狂點(diǎn)擊下單。

每個(gè)接口對(duì)應(yīng)的業(yè)務(wù)復(fù)雜度不同，有的接口一個(gè)請(qǐng)求可能要執(zhí)行五六次數(shù)據(jù)庫操作。即使我們用高配置的 16 核 32G 以及 SSD 固態(tài)硬盤的機(jī)器，當(dāng)流量洪峰到來時(shí)，CPU、磁盤、IO 等負(fù)載都會(huì)瞬間飆升，一段時(shí)間后，系統(tǒng)是無論如何扛不住持續(xù)到達(dá)的請(qǐng)求。

02 流量洪峰帶來的難點(diǎn)

經(jīng)典的秒殺場景主要有兩個(gè)特點(diǎn)：

(1)秒殺時(shí)大量用戶會(huì)在同一時(shí)間同時(shí)進(jìn)行搶購，網(wǎng)站瞬時(shí)訪問流量激增;

(2)秒殺一般是訪問請(qǐng)求量遠(yuǎn)遠(yuǎn)大于庫存數(shù)量，只有少部分用戶能夠秒殺成功。

隨之而來，對(duì)我們的系統(tǒng)就帶來一系列要求：

(1)短時(shí)間內(nèi)并發(fā)量激增，對(duì)系統(tǒng)負(fù)載壓力大，容易造成崩潰;

(2)真正能秒殺成功的還是少數(shù)，天然的讀多寫少場景，如何對(duì)流量進(jìn)行分配;

(3)分布式的環(huán)境下，如何做到一致性的處理;

(4)競爭資源有限，如何做到精準(zhǔn)的控制，準(zhǔn)時(shí)準(zhǔn)點(diǎn)，不能多買，不能少賣，不能重復(fù)買。

而在這么多難點(diǎn)中，我們首要任務(wù)就是去解決并發(fā)量激增的問題，如果到達(dá)的請(qǐng)求太多直接壓垮了服務(wù)器，那其他的功能根本無從談起。

03 使用 MQ 削峰填谷

MQ 除了可以使用異步的方式實(shí)現(xiàn)系統(tǒng)間的解耦，更可以在雙 11 這樣的秒殺活動(dòng)中，通過削峰填谷的方式，處理瞬時(shí)間涌入的大量請(qǐng)求。

什么是削峰填谷?

削峰填谷本身是電力行業(yè)的概念，電力企業(yè)通過必要的技術(shù)和管理手段，降低電網(wǎng)的高峰負(fù)荷，提高低谷負(fù)荷，平滑負(fù)荷曲線，提高負(fù)荷率，保證電網(wǎng)的穩(wěn)定運(yùn)行。

假設(shè)一個(gè)應(yīng)用，它能夠每秒處理 1000 個(gè)請(qǐng)求。如果在第一秒接收到 2000 個(gè)請(qǐng)求，而接下來的兩秒都沒有請(qǐng)求到達(dá)。

整個(gè)應(yīng)用必然面臨兩個(gè)問題：

(1)在第一秒被 2000 個(gè)請(qǐng)求直接壓垮;

(2)假設(shè)第一秒沒有被壓垮，它在這一秒時(shí)間內(nèi)只能處理 1000 請(qǐng)求，第二第三秒?yún)s完全空閑，浪費(fèi)了系統(tǒng)資源。

所以，我們可以通過 MQ 把請(qǐng)求突刺均攤到一段時(shí)間內(nèi)，讓系統(tǒng)負(fù)載保持在請(qǐng)求處理水位之內(nèi)，同時(shí)盡可能地處理更多請(qǐng)求，從而起到“削峰填谷”的效果。

紅色的部分是超出系統(tǒng)處理能力的部分，可以把紅色的那部分消息平攤到后面空閑時(shí)去處理，這樣既可以保證系統(tǒng)負(fù)載處在一個(gè)穩(wěn)定的水位，又可以盡可能地處理更多消息。通過配置流控規(guī)則，可以達(dá)到消息勻速處理的效果。

04 升級(jí)系統(tǒng)架構(gòu)

隨著使用應(yīng)用的用戶越來越多，系統(tǒng)面臨的壓力也會(huì)越來越大，無論是并發(fā)量還是數(shù)據(jù)量，你會(huì)發(fā)現(xiàn)整個(gè)系統(tǒng)各個(gè)模塊都需要進(jìn)行優(yōu)化。

一個(gè)高并發(fā)、大數(shù)據(jù)量的系統(tǒng)架構(gòu)，需要不斷的迭代和進(jìn)化，涉及到大量的技術(shù)方案、架構(gòu)重構(gòu)。

針對(duì)秒殺的場景，上游發(fā)起高并發(fā)的下單操作，由于下游處理能力有限，兩端速度不匹配。此時(shí)我們引入 MQ 可以對(duì)流量進(jìn)行緩沖，并實(shí)現(xiàn)削峰填谷。

上游速度很快，每秒發(fā)起五萬個(gè)請(qǐng)求也沒關(guān)系，它只管往 MQ 中發(fā)。下游系統(tǒng)雖然每秒只能處理 1000 個(gè)請(qǐng)求，但它完全可以 follow 自己的節(jié)奏，每隔一段時(shí)間，主動(dòng)拉取若干條信息，實(shí)施限流的效果，保護(hù)自身。

而在這個(gè)過程中，只需要引入 MQ 組件，對(duì)上下游的業(yè)務(wù)代碼并不用有太多的修改。

在接下來的文章我會(huì)更加詳細(xì)介紹，使用現(xiàn)在主流的消息中間件 RocketMQ 進(jìn)行實(shí)現(xiàn)，敬請(qǐng)期待~

本文轉(zhuǎn)載自微信公眾號(hào)「程序員大帝」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系 程序員大帝公眾號(hào)。