秒殺系統架構優化思路

《秒殺系統架構優化思路》

上周參加qcon，有個兄弟分享秒殺系統的優化，其觀點有些贊同，大部分觀點卻并不同意，結合自己的經驗，談談自己的一些看法。

一、為什麼難

秒殺系統難做的原因：庫存隻有一份，所有人會在集中的時間讀和寫這些資料。

例如小米手機每周二的秒殺，可能手機隻有1萬部，但瞬時進入的流量可能是幾百幾千萬。

又例如12306搶票，亦與秒殺類似，瞬時流量更甚。

二、常見架構

流量到了億級别，常見站點架構如上：

1）浏覽器端，最上層，會執行到一些js代碼

2）站點層，這一層會通路後端資料，拼html頁面傳回給浏覽器

3）服務層，向上遊屏蔽底層資料細節

4）資料層，最終的庫存是存在這裡的，mysql是一個典型

三、優化方向

1）将請求盡量攔截在系統上遊：傳統秒殺系統之是以挂，請求都壓倒了後端資料層，資料讀寫鎖沖突嚴重，并發高響應慢，幾乎所有請求都逾時，流量雖大，下單成功的有效流量甚小【一趟火車其實隻有2000張票，200w個人來買，基本沒有人能買成功，請求有效率為0】

2）充分利用緩存：這是一個典型的讀多寫少的應用場景【一趟火車其實隻有2000張票，200w個人來買，最多2000個人下單成功，其他人都是查詢庫存，寫比例隻有0.1%，讀比例占99.9%】，非常适合使用緩存

四、優化細節

4.1）浏覽器層請求攔截

點選了“查詢”按鈕之後，系統那個卡呀，進度條漲的慢呀，作為使用者，我會不自覺的再去點選“查詢”，繼續點，繼續點，點點點。。。有用麼？平白無故的增加了系統負載（一個使用者點5次，80%的請求是這麼多出來的），怎麼整？

a）産品層面，使用者點選“查詢”或者“購票”後，按鈕置灰，禁止使用者重複送出請求

b）js層面，限制使用者在x秒之内隻能送出一次請求

如此限流，80%流量已攔。

4.2）站點層請求攔截與頁面緩存

浏覽器層的請求攔截，隻能攔住小白使用者（不過這是99%的使用者喲），高端的程式員根本不吃這一套，寫個for循環，直接調用你後端的http請求，怎麼整？

a）同一個uid，限制通路頻度，做頁面緩存，x秒内到達站點層的請求，均傳回同一頁面

b）同一個item的查詢，例如手機車次，做頁面緩存，x秒内到達站點層的請求，均傳回同一頁面

如此限流，又有99%的流量會被攔截在站點層

4.3）服務層請求攔截與資料緩存

站點層的請求攔截，隻能攔住普通程式員，進階黑客，假設他控制了10w台殭屍電腦（并且假設買票不需要實名認證），這下uid的限制不行了吧？怎麼整？

a）大哥，我是服務層，我清楚的知道小米隻有1萬部手機，我清楚的知道一列火車隻有2000張車票，我透10w個請求去資料庫有什麼意義呢？對于寫請求，做請求隊列，每次隻透有限的寫請求去資料層，如果均成功再放下一批，如果庫存不夠則隊列裡的寫請求全部傳回“已售完”

b）對于讀請求，還要我說麼？cache抗，不管是memcached還是redis，單機抗個每秒10w應該都是沒什麼問題的

如此限流，隻有非常少的寫請求，和非常少的讀緩存mis的請求會透到資料層去，又有99.9%的請求被攔住了

4.4）資料層閑庭信步

到了資料這一層，幾乎就沒有什麼請求了，單機也能扛得住，還是那句話，庫存是有限的，小米的産能有限，透這麼多請求來資料庫沒有意義。

五、總結

沒什麼總結了，上文應該描述的非常清楚了，對于秒殺系統，再次重複下筆者的兩個架構優化思路：

1）盡量将請求攔截在系統上遊

2）讀多寫少的常用多使用緩存