場(chǎng)景
你的商城正在策劃了一期秒殺活動(dòng)，活動(dòng)在第五天的 00:00 開(kāi)始，僅限前 200 名，那么秒殺即將開(kāi)始時(shí)，后臺(tái)會(huì)顯示用戶正在瘋狂地刷新 APP 或者瀏覽器來(lái)保證自己能夠盡量早的看到商品。
現(xiàn)象
- 只有固定人數(shù)的人可以購(gòu)買成功
- QPS典型的瞬間波峰
- 用戶對(duì)請(qǐng)求結(jié)果延遲感稍微放寬松
面對(duì)的挑戰(zhàn)
- 現(xiàn)有業(yè)務(wù)的影響（獨(dú)立域名、服務(wù)解決）
- 高并發(fā)時(shí)，應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)壓力
- 超賣，賣出產(chǎn)品數(shù)量多于已有數(shù)量
- 刷單，每個(gè)用戶搶到多個(gè)訂單
- 無(wú)效刷新點(diǎn)擊，用戶在系統(tǒng)卡頓時(shí)，會(huì)進(jìn)行連續(xù)點(diǎn)擊
- 時(shí)延 ，需要2-3s內(nèi)返回結(jié)果，不能直接返回404
設(shè)計(jì)核心關(guān)注點(diǎn)
- 有效數(shù)據(jù)總是少量，需要在上層攔截住大部分無(wú)效數(shù)據(jù)
- 使用隊(duì)列，進(jìn)行異步處理、解耦合、削峰填谷
數(shù)據(jù)流向圖
image.png
各個(gè)層次優(yōu)化方案
1 瀏覽器層面
- 按鈕置灰
- 限時(shí)提交一次，x秒內(nèi)只允許提交一次請(qǐng)求
- 頁(yè)面內(nèi)容靜態(tài)化
- 下單URL動(dòng)態(tài)化
2 Nginx層面
- 由于登錄屬性，可對(duì)uid做請(qǐng)求計(jì)數(shù)和去重，限制訪問(wèn)次數(shù)，做頁(yè)面緩存。（分布式中同uid多后端無(wú)法去重）
3 業(yè)務(wù)服務(wù)層面
- 通過(guò)隊(duì)列只接受固定請(qǐng)求數(shù)，每次透?jìng)鞴潭〝?shù)量到數(shù)據(jù)層進(jìn)行請(qǐng)求
- 多于固定數(shù)的請(qǐng)求，直接返回秒殺完畢
- 業(yè)務(wù)邏輯異步，比如下單業(yè)務(wù)、支付業(yè)務(wù)、統(tǒng)計(jì)數(shù)據(jù)業(yè)務(wù)等
4 數(shù)據(jù)層面
- 悠哉悠哉的工作即可
Q&A
1 架構(gòu)中，其實(shí)壓力最大的反而是站點(diǎn)層，假設(shè)真實(shí)有效的請(qǐng)求數(shù)有1000萬(wàn)，不太可能限制請(qǐng)求連接數(shù)吧，那么這部分的壓力怎么處理？
- 站點(diǎn)層是可以通過(guò)加機(jī)器擴(kuò)。
- 如果機(jī)器不夠，進(jìn)行降級(jí)，避免整個(gè)系統(tǒng)崩潰。
2 “控制了10w個(gè)肉雞，手里有10w個(gè)uid，同時(shí)發(fā)請(qǐng)求” 這個(gè)問(wèn)題怎么解決哈？
- 服務(wù)層寫(xiě)請(qǐng)求隊(duì)列控制
3 如果隊(duì)列處理失敗，如何處理？肉雞把隊(duì)列被撐爆了怎么辦？
- 隊(duì)列失敗概率很低。最壞的情況下，緩存了若干請(qǐng)求之后，后續(xù)請(qǐng)求都直接返回“結(jié)束”
4 站點(diǎn)層過(guò)濾的話，怎么處理多臺(tái)服務(wù)器集群經(jīng)過(guò)負(fù)載均衡器將相同用戶的響應(yīng)分布到不同服務(wù)器的情況呢？還是說(shuō)將站點(diǎn)層的過(guò)濾放到負(fù)載均衡前？
- 在nginx層做負(fù)載均衡，讓一個(gè)uid的請(qǐng)求盡量落到同一個(gè)機(jī)器上
5 不同的用戶瀏覽同一個(gè)商品 落在不同的緩存實(shí)例顯示的庫(kù)存完全不一樣 請(qǐng)問(wèn)怎么做緩存數(shù)據(jù)一致或者是允許臟讀？
- 目前的架構(gòu)設(shè)計(jì)，請(qǐng)求落到不同的站點(diǎn)上，數(shù)據(jù)可能不一致（頁(yè)面緩存不一樣），這個(gè)業(yè)務(wù)場(chǎng)景能接受。但數(shù)據(jù)庫(kù)層面真實(shí)數(shù)據(jù)是沒(méi)問(wèn)題的。
