一、需求

1. 有多款商品，每款商品均100件，每人限每款商品最多購(gòu)買一件。
2. 在X月X日 X時(shí)X分0秒開啟購(gòu)買。在約定時(shí)間之前，只能看到產(chǎn)品頁(yè)面，購(gòu)買按鈕置灰。

二、活動(dòng)預(yù)估

1. 預(yù)計(jì)每種商品數(shù)萬(wàn)人參與
2. 活動(dòng)開始后半分鐘內(nèi)，預(yù)計(jì)每種商品收到10W次交易請(qǐng)求，預(yù)計(jì)總TPS：20W/s
3. 活動(dòng)開始半分鐘后，預(yù)計(jì)絕大多數(shù)商品已售罄，剩下的商品仍支持秒殺，預(yù)計(jì)總TPS：2000/s

三、系統(tǒng)現(xiàn)狀

1. 系統(tǒng)可保持長(zhǎng)期穩(wěn)定運(yùn)行的最大TPS：1000/s
2. 短時(shí)間「1分鐘內(nèi)」系統(tǒng)未拒絕服務(wù)的最高TPS：1500/s

四、設(shè)計(jì)預(yù)研

方案一：改造現(xiàn)有系統(tǒng)，微服務(wù)系統(tǒng)整體大幅增加TPS

優(yōu)點(diǎn)：

1. 大幅增加TPS后，業(yè)務(wù)系統(tǒng)可直接承載巨量交易請(qǐng)求，應(yīng)付秒殺需求會(huì)更加從容。

缺點(diǎn)：

1. 秒殺活動(dòng)次數(shù)少，改造成本、風(fēng)險(xiǎn)較大，性價(jià)比低
2. 改造后，系統(tǒng)架構(gòu)會(huì)更加復(fù)雜，可維護(hù)性降低

方案二：開發(fā)新應(yīng)用，承載該需求；改造現(xiàn)有應(yīng)用以支持新應(yīng)用

優(yōu)點(diǎn)：

1. 對(duì)現(xiàn)有業(yè)務(wù)系統(tǒng)改造小，成本低。
2. 使用新應(yīng)用承載秒殺交易請(qǐng)求，靈活度高，不用過(guò)多考慮向后兼容問(wèn)題。

缺點(diǎn)：

1. 需要一定程度犧牲用戶體驗(yàn)。

結(jié)論

基于成本和可行性考慮，采用方案二

五、架構(gòu)設(shè)計(jì)

5.1 現(xiàn)有架構(gòu)設(shè)計(jì)

1. 前臺(tái)應(yīng)用直接承接用戶訪問(wèn)、交易請(qǐng)求，無(wú)CDN服務(wù)。
2. 前臺(tái)應(yīng)用接收到交易請(qǐng)求后，直接RPC同步請(qǐng)求中臺(tái)應(yīng)用
3. 中臺(tái)應(yīng)用受到交易請(qǐng)求后，同步完成創(chuàng)建訂單、支付、扣減商品數(shù)、完成交易等業(yè)務(wù)流程
4. 前臺(tái)應(yīng)用接收到中臺(tái)應(yīng)用的處理結(jié)果，向用戶展示交易商品的物流信息。

5.2 最新架構(gòu)設(shè)計(jì)

5.2.1 架構(gòu)設(shè)計(jì)一覽圖

秒殺系統(tǒng)架構(gòu)

5.2.2服務(wù)模塊設(shè)計(jì)

1. 前端、客戶端隨機(jī)丟棄交易請(qǐng)求

1. 根據(jù)用戶查看商品詳情頁(yè)的次數(shù)，預(yù)估商品的熱門程度，對(duì)不同商品設(shè)定不同的丟棄比率，設(shè)計(jì)字段：discard，取值為 [0, 100)，作為商品屬性。
2. 前端、客戶端，在用戶提交交易請(qǐng)求時(shí)，生成 [0, 100] 范圍內(nèi)的隨機(jī)數(shù)，discard < 隨機(jī)數(shù)的訂單直接丟棄，但向用戶展示排隊(duì)頁(yè)面，排隊(duì)10秒后直接顯示交易失敗。

2. 提供CDN服務(wù)

1. 靜態(tài)資源均保存在CDN服務(wù)中
2. 前端展示的專門秒殺頁(yè)面，除了「交易發(fā)起」請(qǐng)求外，用戶的任何操作均不會(huì)請(qǐng)求到公司的微服務(wù)業(yè)務(wù)系統(tǒng)。

3. 開發(fā)專門的「秒殺應(yīng)用」，提供熔斷服務(wù)

1. 秒殺應(yīng)用直接承載前端、客戶端的交易請(qǐng)求，授權(quán)通過(guò)的請(qǐng)求發(fā)往前臺(tái)應(yīng)用處理，授權(quán)拒絕的請(qǐng)求直接攔截，返回交易失敗。
2. 秒殺應(yīng)用通過(guò)配置中心，實(shí)時(shí)獲取最新配置。可配置對(duì)交易的丟棄比率，開發(fā)同事在秒殺時(shí)間段內(nèi)，調(diào)整配置，保證發(fā)往業(yè)務(wù)系統(tǒng)的交易請(qǐng)求，TPS保持在 10000/s 以內(nèi)。
3. 秒殺應(yīng)用無(wú)數(shù)據(jù)庫(kù)，無(wú)狀態(tài)，水平擴(kuò)展后可成比例增加吞吐量。

4. 現(xiàn)有業(yè)務(wù)系統(tǒng)優(yōu)化吞吐

1. 前臺(tái)、中臺(tái)各應(yīng)用，通過(guò)優(yōu)化設(shè)計(jì)進(jìn)而優(yōu)化吞吐，有如下優(yōu)化方式：
   • 采用分庫(kù)分表等水平拆分方式，橫向擴(kuò)展數(shù)據(jù)庫(kù)，此時(shí)也可以大幅增加POD數(shù)了
   • 靜態(tài)數(shù)據(jù)緩存在Redis中，數(shù)據(jù)從Redis中取，保證不會(huì)讀取數(shù)據(jù)庫(kù)，后臺(tái)定時(shí)任務(wù)更新緩存。「保證緩存定時(shí)更新且無(wú)緩存擊穿」
2. 分庫(kù)分表策略：
   • 按照商品拆分?jǐn)?shù)據(jù)庫(kù)與應(yīng)用
   • 按照用戶id二次拆分?jǐn)?shù)據(jù)庫(kù)與應(yīng)用
3. 經(jīng)過(guò)上述優(yōu)化，至少可以將中臺(tái)業(yè)務(wù)系統(tǒng)的短時(shí)間「1分鐘內(nèi)」系統(tǒng)未拒絕服務(wù)的最高TPS，由2000/s提升至4000/s
4. 由于前臺(tái)應(yīng)用邏輯較簡(jiǎn)單，TPS可提升至10000/s，無(wú)需再優(yōu)化。
5. 由于木桶效應(yīng)，業(yè)務(wù)系統(tǒng)整體的短時(shí)間「1分鐘內(nèi)」系統(tǒng)未拒絕服務(wù)的最高TPS，為4000/s

5. 異步隊(duì)列

1. 前臺(tái)應(yīng)用效率較高，此處僅優(yōu)化中臺(tái)應(yīng)用即可。
2. 前臺(tái)應(yīng)用將秒殺交易請(qǐng)求均發(fā)往 Kafka，中臺(tái)應(yīng)用通過(guò) Kafka 消費(fèi)消息，進(jìn)行實(shí)際業(yè)務(wù)處理。
3. 由于業(yè)務(wù)高峰時(shí)間段最多僅有半分鐘 ~ 1分鐘，中臺(tái)應(yīng)用在 2 分鐘左右處理完全部交易也可以接受。
4. Kafka 的 TPS 為數(shù)十 W/s，承載前臺(tái) 5000/s ~ 10000/s 的TPS毫無(wú)壓力。
5. 經(jīng)此優(yōu)化，業(yè)務(wù)系統(tǒng)整體的短時(shí)間「1分鐘內(nèi)」系統(tǒng)未拒絕服務(wù)的最高TPS，可從 4000/s 提升至 10000/s

缺點(diǎn)：極端情況下，交易處理會(huì)較為緩慢。

6. 服務(wù)降級(jí)

1. 秒殺開始前半小時(shí)到秒殺結(jié)束后的半小時(shí)，這個(gè)時(shí)間段內(nèi)，部分服務(wù)降級(jí)
2. 時(shí)間段內(nèi)，不展示物流信息、不支持生成及展示發(fā)票，保證核心業(yè)務(wù)系統(tǒng)的穩(wěn)定