秒殺活動(dòng)在電商類的APP開發(fā)中很常見，秒殺功能不同于其他功能，它對(duì)于系統(tǒng)的性能要求非常高。例如：小米手機(jī)每周二的秒殺，可能手機(jī)只有1萬部，但瞬時(shí)進(jìn)入的流量可能是幾百幾千萬。又例如：12306搶票，票是有限的，庫存一份，瞬時(shí)流量非常多，都讀相同的庫存。讀寫沖突，鎖非常嚴(yán)重，這是秒殺業(yè)務(wù)難的地方。那我們?cè)趺磧?yōu)化秒殺業(yè)務(wù)的架構(gòu)呢？

 

優(yōu)化方向有兩個(gè)：

（1）將請(qǐng)求盡量攔截在系統(tǒng)上游（不要讓鎖沖突落到數(shù)據(jù)庫上去）。傳統(tǒng)秒殺系統(tǒng)之所以掛，請(qǐng)求都?jí)旱沽撕蠖藬?shù)據(jù)層，數(shù)據(jù)讀寫鎖沖突嚴(yán)重，并發(fā)高響應(yīng)慢，幾乎所有請(qǐng)求都超時(shí)，流量雖大，下單成功的有效流量甚小。以12306為例，一趟火車其實(shí)只有2000張票，200w個(gè)人來買，基本沒有人能買成功，請(qǐng)求有效率為0。

（2）充分利用緩存，秒殺買票，這是一個(gè)典型的讀多些少的應(yīng)用場(chǎng)景，大部分請(qǐng)求是車次查詢，票查詢，下單和支付才是寫請(qǐng)求。一趟火車其實(shí)只有2000張票，200w個(gè)人來買，最多2000個(gè)人下單成功，其他人都是查詢庫存，寫比例只有0.1%，讀比例占99.9%，非常適合使用緩存來優(yōu)化。好，后續(xù)講講怎么個(gè)“將請(qǐng)求盡量攔截在系統(tǒng)上游”法，以及怎么個(gè)“緩存”法，講講細(xì)節(jié)。

常見的站點(diǎn)架構(gòu)基本是這樣的：
（1）瀏覽器端，最上層，會(huì)執(zhí)行到一些JS代碼
（2）站點(diǎn)層，這一層會(huì)訪問后端數(shù)據(jù)，拼html頁面返回給瀏覽器
（3）服務(wù)層，向上游屏蔽底層數(shù)據(jù)細(xì)節(jié)，提供數(shù)據(jù)訪問
（4）數(shù)據(jù)層，最終的庫存是存在這里的，mysql是一個(gè)典型（當(dāng)然還有會(huì)緩存）
 

再次重復(fù)下APP開發(fā)中常見的秒殺系統(tǒng)的兩個(gè)架構(gòu)優(yōu)化思路：
（1）盡量將請(qǐng)求攔截在系統(tǒng)上游（越上游越好）；
（2）讀多寫少的常用多使用緩存（緩存抗讀壓力）；
瀏覽器和APP：做限速
站點(diǎn)層：按照uid做限速，做頁面緩存
服務(wù)層：按照業(yè)務(wù)做寫請(qǐng)求隊(duì)列控制流量，做數(shù)據(jù)緩存
數(shù)據(jù)層：閑庭信步
最后：結(jié)合業(yè)務(wù)做優(yōu)化