- 相關推薦
秒殺系統(tǒng)架構分析
所謂"秒殺",就是網(wǎng)絡賣家發(fā)布一些超低價格的商品,所有買家在同一時間網(wǎng)上搶購的一種銷售方式。下面整理了關于秒殺系統(tǒng)架構分析的文章,歡迎大家閱讀!
1 秒殺業(yè)務分析
正常電子商務流程
(1)查詢商品;(2)創(chuàng)建訂單;(3)扣減庫存;(4)更新訂單;(5)付款;(6)賣家發(fā)貨
秒殺業(yè)務的特性
(1)低廉價格;(2)大幅推廣;(3)瞬時售空;(4)一般是定時上架;(5)時間短、瞬時并發(fā)量高;
2 秒殺技術挑戰(zhàn)
假設某網(wǎng)站秒殺活動只推出一件商品,預計會吸引1萬人參加活動,也就說最大并發(fā)請求數(shù)是10000,秒殺系統(tǒng)需要面對的技術挑戰(zhàn)有:
對現(xiàn)有網(wǎng)站業(yè)務造成沖擊
秒殺活動只是網(wǎng)站營銷的一個附加活動,這個活動具有時間短,并發(fā)訪問量大的特點,如果和網(wǎng)站原有應用部署在一起,必然會對現(xiàn)有業(yè)務造成沖擊,稍有不慎可能導致整個網(wǎng)站癱瘓。
解決方案:將秒殺系統(tǒng)獨立部署,甚至使用獨立域名,使其與網(wǎng)站完全隔離。
高并發(fā)下的應用、數(shù)據(jù)庫負載
用戶在秒殺開始前,通過不停刷新瀏覽器頁面以保證不會錯過秒殺,這些請求如果按照一般的網(wǎng)站應用架構,訪問應用服務器、連接數(shù)據(jù)庫,會對應用服務器和數(shù)據(jù)庫服務器造成負載壓力。
解決方案:重新設計秒殺商品頁面,不使用網(wǎng)站原來的商品詳細頁面,頁面內容靜態(tài)化,用戶請求不需要經(jīng)過應用服務。
突然增加的網(wǎng)絡及服務器帶寬
假設商品頁面大小200K(主要是商品圖片大小),那么需要的網(wǎng)絡和服務器帶寬是2G(200K×10000),這些網(wǎng)絡帶寬是因為秒殺活動新增的,超過網(wǎng)站平時使用的帶寬。
解決方案:因為秒殺新增的網(wǎng)絡帶寬,必須和運營商重新購買或者租借。為了減輕網(wǎng)站服務器的壓力,需要將秒殺商品頁面緩存在CDN,同樣需要和CDN服務商臨時租借新增的出口帶寬。
直接下單
秒殺的游戲規(guī)則是到了秒殺才能開始對商品下單購買,在此時間點之前,只能瀏覽商品信息,不能下單。而下單頁面也是一個普通的URL,如果得到這個URL,不用等到秒殺開始就可以下單了。
解決方案:為了避免用戶直接訪問下單頁面URL,需要將改URL動態(tài)化,即使秒殺系統(tǒng)的開發(fā)者也無法在秒殺開始前訪問下單頁面的URL。辦法是在下單頁面URL加入由服務器端生成的隨機數(shù)作為參數(shù),在秒殺開始的時候才能得到。
如何控制秒殺商品頁面購買按鈕的點亮
購買按鈕只有在秒殺開始的時候才能點亮,在此之前是灰色的。如果該頁面是動態(tài)生成的,當然可以在服務器端構造響應頁面輸出,控制該按鈕是灰色還 是點亮,但是為了減輕服務器端負載壓力,更好地利用CDN、反向代理等性能優(yōu)化手段,該頁面被設計為靜態(tài)頁面,緩存在CDN、反向代理服務器上,甚至用戶瀏覽器上。秒殺開始時,用戶刷新頁面,請求根本不會到達應用服務器。
解決方案:使用JavaScript腳本控制,在秒殺商品靜態(tài)頁面中加入一個JavaScript文件引用,該JavaScript文件中包含 秒殺開始標志為否;當秒殺開始的時候生成一個新的JavaScript文件(文件名保持不變,只是內容不一樣),更新秒殺開始標志為是,加入下單頁面的URL及隨機數(shù)參數(shù)(這個隨機數(shù)只會產(chǎn)生一個,即所有人看到的URL都是同一個,服務器端可以用redis這種分布式緩存服務器來保存隨機數(shù)),并被用戶瀏覽器加載,控制秒殺商品頁面的展示。這個JavaScript文件的加載可以加上隨機版本號(例如xx.js?v=32353823),這樣就不會被瀏覽器、CDN和反向代理服務器緩存。
這個JavaScript文件非常小,即使每次瀏覽器刷新都訪問JavaScript文件服務器也不會對服務器集群和網(wǎng)絡帶寬造成太大壓力。
如何只允許第一個提交的訂單被發(fā)送到訂單子系統(tǒng)
由于最終能夠成功秒殺到商品的用戶只有一個,因此需要在用戶提交訂單時,檢查是否已經(jīng)有訂單提交。如果已經(jīng)有訂單提交成功,則需要更新 JavaScript文件,更新秒殺開始標志為否,購買按鈕變灰。事實上,由于最終能夠成功提交訂單的用戶只有一個,為了減輕下單頁面服務器的負載壓力, 可以控制進入下單頁面的入口,只有少數(shù)用戶能進入下單頁面,其他用戶直接進入秒殺結束頁面。
解決方案:假設下單服務器集群有10臺服務器,每臺服務器只接受最多10個下單請求。在還沒有人提交訂單成功之前,如果一臺服務器已經(jīng)有十單了,而有的一單都沒處理,可能出現(xiàn)的用戶體驗不佳的場景是用戶第一次點擊購買按鈕進入已結束頁面,再刷新一下頁面,有可能被一單都沒有處理的服務器處理,進入了填寫訂單的頁面,可以考慮通過cookie的方式來應對,符合一致性原則。當然可以采用最少連接的負載均衡算法,出現(xiàn)上述情況的概率大大降低。
如何進行下單前置檢查
下單服務器檢查本機已處理的下單請求數(shù)目:
如果超過10條,直接返回已結束頁面給用戶;
如果未超過10條,則用戶可進入填寫訂單及確認頁面;
檢查全局已提交訂單數(shù)目:
已超過秒殺商品總數(shù),返回已結束頁面給用戶;
未超過秒殺商品總數(shù),提交到子訂單系統(tǒng);
秒殺一般是定時上架
該功能實現(xiàn)方式很多。不過目前比較好的方式是:提前設定好商品的上架時間,用戶可以在前臺看到該商品,但是無法點擊“立即購買”的按鈕。但是需要考慮的是,有人可以繞過前端的限制,直接通過URL的方式發(fā)起購買,這就需要在前臺商品頁面,以及bug頁面到后端的數(shù)據(jù)庫,都要進行時鐘同步。越在后端控制,安全性越高。
定時秒殺的話,就要避免賣家在秒殺前對商品做編輯帶來的不可預期的影響。這種特殊的變更需要多方面評估。一般禁止編輯,如需變更,可以走數(shù)據(jù)訂正多的流程。
減庫存的操作
有兩種選擇,一種是拍下減庫存 另外一種是付款減庫存;目前采用的“拍下減庫存”的方式,拍下就是一瞬間的事,對用戶體驗會好些。
庫存會帶來“超賣”的問題:售出數(shù)量多于庫存數(shù)量
由于庫存并發(fā)更新的問題,導致在實際庫存已經(jīng)不足的情況下,庫存依然在減,導致賣家的商品賣得件數(shù)超過秒殺的預期。方案:采用樂觀鎖
auction_auctions set
quantity = #inQuantity#
where auction_id = #itemId# and quantity = #dbQuantity#
秒殺器的應對
秒殺器一般下單個購買及其迅速,根據(jù)購買記錄可以甄別出一部分?梢酝ㄟ^校驗碼達到一定的方法,這就要求校驗碼足夠安全,不被破解,采用的方式有:秒殺專用驗證碼,電視公布驗證碼,秒殺答題。
3 秒殺架構原則
盡量將請求攔截在系統(tǒng)上游
傳統(tǒng)秒殺系統(tǒng)之所以掛,請求都壓倒了后端數(shù)據(jù)層,數(shù)據(jù)讀寫鎖沖突嚴重,并發(fā)高響應慢,幾乎所有請求都超時,流量雖大,下單成功的有效流量甚小【一趟火車其實只有2000張票,200w個人來買,基本沒有人能買成功,請求有效率為0】。
讀多寫少的常用多使用緩存
這是一個典型的讀多寫少的應用場景【一趟火車其實只有2000張票,200w個人來買,最多2000個人下單成功,其他人都是查詢庫存,寫比例只有0.1%,讀比例占99.9%】,非常適合使用緩存。
【秒殺系統(tǒng)架構分析】相關文章:
基于Web的MES系統(tǒng)安全架構設計及分析10-16
如何搭建系統(tǒng)CSS架構12-31
系統(tǒng)架構設計模式大全08-22
物流管理的合理架構分析10-02
系統(tǒng)架構師是做什么的12-30
圖書檢索系統(tǒng)體系架構研究12-05
基于云架構的系統(tǒng)安全設計08-08
系統(tǒng)架構設計師要素01-11