秒殺系統架構優化思路

2022-03-13 10:48:15 字數 1694 閱讀 4241

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

上週參加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)讀多寫少的常用多使用快取

秒殺系統架構優化思路

在 京東等電商類平台面試中,容易碰到乙個很常見的場景題 秒殺場景。本渣作者不敢瞎寫,附上兩篇 標準答案 希望小夥伴們可以從中學習到東西,也祝面試順利。本渣認為,類似問題有幾個考點 全域性思考能力和把控能力,包括從前端 網路 閘道器 後端 儲存等一整個資訊傳輸互動線路都有優化的點。架構設計原則 有效控...

秒殺系統架構優化思路

一 為什麼難 秒殺系統難做的原因 庫存只有乙份,所有人會在集中的時間讀和寫這些資料。例如小公尺手機每週二的秒殺,可能手機只有1萬部,但瞬時進入的流量可能是幾百幾千萬。又例如12306搶票,亦與秒殺類似,瞬時流量更甚。二 常見架構 流量到了億級別,常見站點架構如上 1 瀏覽器端,最上層,會執行到一些j...

秒殺系統架構優化思路

一 秒殺業務為什麼難做 1 im系統,例如qq或者微博,每個人都讀自己的資料 好友列表 群列表 個人資訊 2 微博系統,每個人讀你關注的人的資料,乙個人讀多個人的資料 3 秒殺系統,庫存只有乙份,所有人會在集中的時間讀和寫這些資料,多個人讀乙個資料。例如 小公尺手機每週二的秒殺,可能手機只有1萬部,...