電商類APP開發如何做好秒殺活動

 

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

 

優化方向有兩個：

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

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

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

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