秒殺系統(tǒng)為什么難做？

根本原因，是庫(kù)存訪(fǎng)問(wèn)集中在一個(gè)地方，所有請(qǐng)求會(huì)在集中的時(shí)間讀寫(xiě)庫(kù)存數(shù)據(jù)，導(dǎo)致系統(tǒng)鎖死。

比如說(shuō)：華為搶手機(jī)，可能庫(kù)存只有5K部，但瞬時(shí)進(jìn)入的流量可能是十萬(wàn)百萬(wàn)。

又比如說(shuō)，12306搶票，余票很少，瞬時(shí)流量會(huì)更高。

怎么優(yōu)化？

最核心的優(yōu)化思路是：盡量將請(qǐng)求攔截在系統(tǒng)的上游，而不要壓到庫(kù)存數(shù)據(jù)。

怎么攔截？

常見(jiàn)的分層架構(gòu)如上，從上到下逐層攔截。

首先，端上攔截。

• 產(chǎn)品層面：用戶(hù)點(diǎn)擊“查詢(xún)”或者“搶購(gòu)”后，按鈕置灰，禁止用戶(hù)重復(fù)提交請(qǐng)求。
• 技術(shù)層面：前APP端，或者H5端，限制同一個(gè)用戶(hù)在10秒之內(nèi)只能向服務(wù)端提交一次請(qǐng)求，重復(fù)的請(qǐng)求前端直接返回。

如此限流，可攔截不少流量。

有人要說(shuō)了，這個(gè)可行嗎？端上攔截，只能攔住小白用戶(hù)，大部分流量都是程序員抓包寫(xiě)腳本，for循環(huán)，直接調(diào)用后端的HTTP接口訪(fǎng)問(wèn)，那怎么辦？

第二步，web-server站點(diǎn)層攔截。

秒殺類(lèi)的電商場(chǎng)景，用戶(hù)需要登錄，登錄就有token，有uid的唯一標(biāo)識(shí)。

在站點(diǎn)層，同一個(gè)uid，做限速，限制同一個(gè)用戶(hù)在10秒之內(nèi)只能向service提交一次請(qǐng)求，重復(fù)的請(qǐng)求直接返回。

如此限流，用腳本寫(xiě)for循環(huán)搶購(gòu)的請(qǐng)求，99%又被攔住了。

又有人要說(shuō)了，同一個(gè)uid確實(shí)被攔住了，那萬(wàn)一有一個(gè)黑客，控制了10W個(gè)賬號(hào)，10W個(gè)uid同時(shí)搶手機(jī)，該怎么辦呢？

第三步，service服務(wù)層攔截。

系統(tǒng)上線(xiàn)，一般都做過(guò)壓測(cè)，對(duì)service的服務(wù)能力是清楚的，假如每秒只能服務(wù)1W的吞吐，中間可以加一個(gè)MQ，采用拉模式來(lái)做削峰填谷，service根據(jù)自己的服務(wù)能力去處理請(qǐng)求，對(duì)自己實(shí)施保護(hù)。

又有人要說(shuō)了，萬(wàn)一沒(méi)做過(guò)壓測(cè)，不知道service的服務(wù)能力怎么辦？

業(yè)務(wù)層面，我們知道手機(jī)的庫(kù)存量，假如庫(kù)存只有5K部手機(jī)，放過(guò)去10W個(gè)請(qǐng)求，沒(méi)有意義。還是加一個(gè)MQ，還是采用拉模式來(lái)做削峰填谷，service根據(jù)庫(kù)存情況去處理請(qǐng)求，對(duì)自己實(shí)施保護(hù)。

如此限流，只有非常少的讀寫(xiě)請(qǐng)求，會(huì)壓到后端數(shù)據(jù)層。

最后，數(shù)據(jù)層怎么優(yōu)化？

如果做了前端，站點(diǎn)層，服務(wù)層的優(yōu)化，數(shù)據(jù)庫(kù)上的壓力就很小了：

• 沒(méi)有數(shù)據(jù)量大的問(wèn)題，不需要做水平切分；
• 沒(méi)有吞吐量大的問(wèn)題，系統(tǒng)根據(jù)自身壓力，根據(jù)業(yè)務(wù)庫(kù)存來(lái)保護(hù)自己；

數(shù)據(jù)庫(kù)層閑庭信步，最多加加緩存抗一下查詢(xún)壓力，單機(jī)也能扛得住。

如果有多SKU，可以根據(jù)壓力情況與SKU情況加機(jī)器拆分，總之系統(tǒng)具備線(xiàn)性擴(kuò)容能力。

總結(jié)

還是那句話(huà)：盡量將請(qǐng)求攔截在系統(tǒng)的上游，而不要壓到庫(kù)存數(shù)據(jù)。

知其然，知其所以然。

思路比結(jié)論更重要。