做秒殺方案亦是如此，秒殺活動(dòng)經(jīng)常會(huì)引發(fā)高并發(fā)、系統(tǒng)宕機(jī)和庫存超賣的棘手問題，作為開發(fā)者，我們該如何在保證系統(tǒng)穩(wěn)定性的同時(shí)，防止業(yè)務(wù)風(fēng)險(xiǎn)呢？

本篇聊聊秒殺方案的幾個(gè)原則和注意點(diǎn)，腦圖見文末。

原則

縱觀多種秒殺方案，沒有相同的，但是這些方案都遵守了相同的原則。具體原則如下：

(1) 保護(hù)數(shù)據(jù)庫

秒殺場景下，一定要優(yōu)先保護(hù)數(shù)據(jù)庫，這是重中之重。一旦數(shù)據(jù)庫宕機(jī)，那系統(tǒng)徹底癱瘓，會(huì)給業(yè)務(wù)和口碑造成損失。保護(hù)數(shù)據(jù)庫要注意如下幾點(diǎn)：

• 在應(yīng)用層需要將不合格的請求全部攔截，避免邏輯觸達(dá)到數(shù)據(jù)庫。
• 評(píng)估并發(fā)數(shù)，QPS等，給應(yīng)用設(shè)置合理的數(shù)據(jù)庫連接池?cái)?shù)量，避免將數(shù)據(jù)庫的連接耗盡。
• 監(jiān)控?cái)?shù)據(jù)庫，觀測數(shù)據(jù)庫的CPU、內(nèi)存等壓力，觀測慢SQL等，一旦出現(xiàn)問題，及時(shí)作出響應(yīng)。

(2) 保護(hù)應(yīng)用系統(tǒng)

應(yīng)用系統(tǒng)也是要保護(hù)的對(duì)象，不管是單體還是微服務(wù)，系統(tǒng)盡量不宕機(jī)。保護(hù)系統(tǒng)要注意這幾點(diǎn)：

• 如果有條件的話，將秒殺系統(tǒng)的BFF層做成獨(dú)立的服務(wù)，這樣就算本服務(wù)掛了，也不影響別的服務(wù)。
• 評(píng)估秒殺活動(dòng)的訪問量，適當(dāng)擴(kuò)大部分微服務(wù)的負(fù)載數(shù)量，從而提高系統(tǒng)的響應(yīng)能力。

(3) 提前退出

秒殺系統(tǒng)一旦對(duì)外開放，肯定會(huì)招來不少羊毛黨，甚至惡意攻擊。所以，在處理邏輯時(shí)，一定要做前置校驗(yàn)，一旦發(fā)現(xiàn)非法請求，直接中斷。

如果有條件的話，也要做一些攻擊型測試和壓力測試，看看能否攔住非法請求，看看系統(tǒng)能否承受住壓力。

(4) 不超賣

秒殺場景下的商品，一般都是賠本賺吆喝，真的是賣一單虧一單。一般秒殺的商品、價(jià)格、庫存，都是公司的運(yùn)營和管理層溝通確認(rèn)的結(jié)果。

為了將虧損控制在合理的范圍，要嚴(yán)格按照既定的庫存去售賣，一定不能出現(xiàn)超賣的情況。

前端主要注意點(diǎn)

秒殺場景下，前端有一些注意點(diǎn)，如下：

• 頁面靜態(tài)化：不管是在PC、H5、小程序還是APP，頁面盡量靜態(tài)化，能走緩存的走緩存，盡量少的去請求接口。
• CDN：將涉及到的js、圖片、html等靜態(tài)資源，提前刷到CDN中，加快訪問速度。
• 從緩存讀取數(shù)據(jù)：秒殺場景下用到的接口要和常規(guī)接口區(qū)分開，秒殺場景下的接口盡量是從Redis緩存中讀取數(shù)據(jù)，然后響應(yīng)給前端。前端也需要判斷哪些數(shù)據(jù)可以存入前端緩存中，避免下次重復(fù)調(diào)接口獲取。
• 前端做攔截：前端頁面也要做一些攔截動(dòng)作，過濾非法請求。雖然作用不大，只防君子不防小人，但是也要做。一切能提前攔截掉非法請求的動(dòng)作，都要做。

后端主要注意點(diǎn)

后端的注意事項(xiàng)較多，大致如下：

(1) 彈性增加服務(wù)器：根據(jù)自身的整體部署情況，適當(dāng)擴(kuò)大負(fù)載。比如混合云部署的方式，可以按需臨時(shí)租用幾臺(tái)云廠商的云服務(wù)器，等活動(dòng)結(jié)束立馬釋放云服務(wù)器，這樣成本最小。

(2) 限流和降級(jí)：不管是在秒殺場景，還是其余場景，保護(hù)系統(tǒng)的手段就是限流、降級(jí)、熔斷。不管擱在什么時(shí)候，都是這三板斧。

(3) 前置校驗(yàn)：前置校驗(yàn)可以最大程度的攔住非法請求。比如校驗(yàn)惡意的重復(fù)IP、校驗(yàn)用戶的重復(fù)下單、校驗(yàn)庫存等等。

(4) 緩存預(yù)熱：對(duì)于秒殺的商品信息和庫存，需要提前做緩存預(yù)熱，比如將數(shù)據(jù)提前刷到Redis緩存中。

(5) 定時(shí)任務(wù)：

• 及時(shí)釋放庫存：一般場景下，可能半小時(shí)才會(huì)取消未支付的訂單。但在秒殺場景下，由于庫存有限，避免惡意占庫存，所以允許訂單未支付的時(shí)間就要減少，比如3分鐘。這種場景下，可以用定時(shí)任務(wù)及時(shí)取消訂單，或者，采用消息隊(duì)列的定時(shí)消息方案（比如RocketMQ的延遲消息）。
• 校準(zhǔn)緩存的庫存：下單會(huì)占用庫存，取消訂單會(huì)釋放庫存。如果庫存預(yù)熱到了Redis，則需要有個(gè)定時(shí)任務(wù)去校準(zhǔn)Redis里的庫存數(shù)量。

(6) 下單和減庫存：

• 樂觀鎖減庫存：更新數(shù)據(jù)庫里的庫存數(shù)量時(shí)，一定要使用樂觀鎖方案去避免超賣，類似update ttt set stock = xxx where product_id = yyy and stock = zzz;。
• 同步或異步：在走完前置邏輯后，則會(huì)進(jìn)入到下單和減庫存邏輯，此時(shí)，可以用同步方式直接調(diào)用，也可以用異步丟入到MQ的方式。具體采用哪種方式，需要根據(jù)系統(tǒng)的吞吐量去做評(píng)估。

總結(jié)

本文主要聊了秒殺方案的幾個(gè)原則和前后端注意事項(xiàng)。方案千千萬，原則就這么幾個(gè)。最后，貼上一張腦圖方便記憶。