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

 

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

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

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

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

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