秒殺系統架構分析

　　所謂"秒殺"，就是網(wǎng)絡(luò )賣(mài)家發(fā)布一些超低價(jià)格的商品，所有買(mǎi)家在同一時(shí)間網(wǎng)上搶購的一種銷(xiāo)售方式。下面整理了關(guān)于秒殺系統架構分析的文章，歡迎大家閱讀!

　　1 秒殺業(yè)務(wù)分析

　　正常電子商務(wù)流程

　　(1)查詢(xún)商品;(2)創(chuàng )建訂單;(3)扣減庫存;(4)更新訂單;(5)付款;(6)賣(mài)家發(fā)貨

　　秒殺業(yè)務(wù)的特性

　　(1)低廉價(jià)格;(2)大幅推廣;(3)瞬時(shí)售空;(4)一般是定時(shí)上架;(5)時(shí)間短、瞬時(shí)并發(fā)量高;

　　2 秒殺技術(shù)挑戰

　　假設某網(wǎng)站秒殺活動(dòng)只推出一件商品，預計會(huì )吸引1萬(wàn)人參加活動(dòng)，也就說(shuō)最大并發(fā)請求數是10000，秒殺系統需要面對的技術(shù)挑戰有：

　　對現有網(wǎng)站業(yè)務(wù)造成沖擊

　　秒殺活動(dòng)只是網(wǎng)站營(yíng)銷(xiāo)的一個(gè)附加活動(dòng)，這個(gè)活動(dòng)具有時(shí)間短，并發(fā)訪(fǎng)問(wèn)量大的特點(diǎn)，如果和網(wǎng)站原有應用部署在一起，必然會(huì )對現有業(yè)務(wù)造成沖擊，稍有不慎可能導致整個(gè)網(wǎng)站癱瘓。

　　解決方案：將秒殺系統獨立部署，甚至使用獨立域名，使其與網(wǎng)站完全隔離。

　　高并發(fā)下的應用、數據庫負載

　　用戶(hù)在秒殺開(kāi)始前，通過(guò)不停刷新瀏覽器頁(yè)面以保證不會(huì )錯過(guò)秒殺，這些請求如果按照一般的網(wǎng)站應用架構，訪(fǎng)問(wèn)應用服務(wù)器、連接數據庫，會(huì )對應用服務(wù)器和數據庫服務(wù)器造成負載壓力。

　　解決方案：重新設計秒殺商品頁(yè)面，不使用網(wǎng)站原來(lái)的商品詳細頁(yè)面，頁(yè)面內容靜態(tài)化，用戶(hù)請求不需要經(jīng)過(guò)應用服務(wù)。

　　突然增加的網(wǎng)絡(luò )及服務(wù)器帶寬

　　假設商品頁(yè)面大小200K(主要是商品圖片大小)，那么需要的網(wǎng)絡(luò )和服務(wù)器帶寬是2G(200K×10000)，這些網(wǎng)絡(luò )帶寬是因為秒殺活動(dòng)新增的，超過(guò)網(wǎng)站平時(shí)使用的帶寬。

　　解決方案：因為秒殺新增的網(wǎng)絡(luò )帶寬，必須和運營(yíng)商重新購買(mǎi)或者租借。為了減輕網(wǎng)站服務(wù)器的壓力，需要將秒殺商品頁(yè)面緩存在CDN，同樣需要和CDN服務(wù)商臨時(shí)租借新增的出口帶寬。

　　直接下單

　　秒殺的游戲規則是到了秒殺才能開(kāi)始對商品下單購買(mǎi)，在此時(shí)間點(diǎn)之前，只能瀏覽商品信息，不能下單。而下單頁(yè)面也是一個(gè)普通的URL，如果得到這個(gè)URL，不用等到秒殺開(kāi)始就可以下單了。

　　解決方案：為了避免用戶(hù)直接訪(fǎng)問(wèn)下單頁(yè)面URL，需要將改URL動(dòng)態(tài)化，即使秒殺系統的開(kāi)發(fā)者也無(wú)法在秒殺開(kāi)始前訪(fǎng)問(wèn)下單頁(yè)面的URL。辦法是在下單頁(yè)面URL加入由服務(wù)器端生成的隨機數作為參數，在秒殺開(kāi)始的時(shí)候才能得到。

　　如何控制秒殺商品頁(yè)面購買(mǎi)按鈕的點(diǎn)亮

　　購買(mǎi)按鈕只有在秒殺開(kāi)始的時(shí)候才能點(diǎn)亮，在此之前是灰色的。如果該頁(yè)面是動(dòng)態(tài)生成的，當然可以在服務(wù)器端構造響應頁(yè)面輸出，控制該按鈕是灰色還 是點(diǎn)亮，但是為了減輕服務(wù)器端負載壓力，更好地利用CDN、反向代理等性能優(yōu)化手段，該頁(yè)面被設計為靜態(tài)頁(yè)面，緩存在CDN、反向代理服務(wù)器上，甚至用戶(hù)瀏覽器上。秒殺開(kāi)始時(shí)，用戶(hù)刷新頁(yè)面，請求根本不會(huì )到達應用服務(wù)器。

　　解決方案：使用JavaScript腳本控制，在秒殺商品靜態(tài)頁(yè)面中加入一個(gè)JavaScript文件引用，該JavaScript文件中包含 秒殺開(kāi)始標志為否;當秒殺開(kāi)始的時(shí)候生成一個(gè)新的JavaScript文件(文件名保持不變，只是內容不一樣)，更新秒殺開(kāi)始標志為是，加入下單頁(yè)面的URL及隨機數參數(這個(gè)隨機數只會(huì )產(chǎn)生一個(gè)，即所有人看到的URL都是同一個(gè)，服務(wù)器端可以用redis這種分布式緩存服務(wù)器來(lái)保存隨機數)，并被用戶(hù)瀏覽器加載，控制秒殺商品頁(yè)面的展示。這個(gè)JavaScript文件的加載可以加上隨機版本號(例如xx.js?v=32353823)，這樣就不會(huì )被瀏覽器、CDN和反向代理服務(wù)器緩存。

　　這個(gè)JavaScript文件非常小，即使每次瀏覽器刷新都訪(fǎng)問(wèn)JavaScript文件服務(wù)器也不會(huì )對服務(wù)器集群和網(wǎng)絡(luò )帶寬造成太大壓力。

　　如何只允許第一個(gè)提交的訂單被發(fā)送到訂單子系統

　　由于最終能夠成功秒殺到商品的用戶(hù)只有一個(gè)，因此需要在用戶(hù)提交訂單時(shí)，檢查是否已經(jīng)有訂單提交。如果已經(jīng)有訂單提交成功，則需要更新 JavaScript文件，更新秒殺開(kāi)始標志為否，購買(mǎi)按鈕變灰。事實(shí)上，由于最終能夠成功提交訂單的用戶(hù)只有一個(gè)，為了減輕下單頁(yè)面服務(wù)器的負載壓力， 可以控制進(jìn)入下單頁(yè)面的入口，只有少數用戶(hù)能進(jìn)入下單頁(yè)面，其他用戶(hù)直接進(jìn)入秒殺結束頁(yè)面。

　　解決方案：假設下單服務(wù)器集群有10臺服務(wù)器，每臺服務(wù)器只接受最多10個(gè)下單請求。在還沒(méi)有人提交訂單成功之前，如果一臺服務(wù)器已經(jīng)有十單了，而有的一單都沒(méi)處理，可能出現的用戶(hù)體驗不佳的場(chǎng)景是用戶(hù)第一次點(diǎn)擊購買(mǎi)按鈕進(jìn)入已結束頁(yè)面，再刷新一下頁(yè)面，有可能被一單都沒(méi)有處理的服務(wù)器處理，進(jìn)入了填寫(xiě)訂單的頁(yè)面，可以考慮通過(guò)cookie的方式來(lái)應對，符合一致性原則。當然可以采用最少連接的負載均衡算法，出現上述情況的概率大大降低。

　　如何進(jìn)行下單前置檢查

　　下單服務(wù)器檢查本機已處理的下單請求數目：

　　如果超過(guò)10條，直接返回已結束頁(yè)面給用戶(hù);

　　如果未超過(guò)10條，則用戶(hù)可進(jìn)入填寫(xiě)訂單及確認頁(yè)面;

　　檢查全局已提交訂單數目：

　　已超過(guò)秒殺商品總數，返回已結束頁(yè)面給用戶(hù);

　　未超過(guò)秒殺商品總數，提交到子訂單系統;

　　秒殺一般是定時(shí)上架

　　該功能實(shí)現方式很多。不過(guò)目前比較好的方式是：提前設定好商品的上架時(shí)間，用戶(hù)可以在前臺看到該商品，但是無(wú)法點(diǎn)擊“立即購買(mǎi)”的按鈕。但是需要考慮的是，有人可以繞過(guò)前端的限制，直接通過(guò)URL的方式發(fā)起購買(mǎi)，這就需要在前臺商品頁(yè)面，以及bug頁(yè)面到后端的數據庫，都要進(jìn)行時(shí)鐘同步。越在后端控制，安全性越高。

　　定時(shí)秒殺的話(huà)，就要避免賣(mài)家在秒殺前對商品做編輯帶來(lái)的不可預期的影響。這種特殊的變更需要多方面評估。一般禁止編輯，如需變更，可以走數據訂正多的流程。

　　減庫存的操作

　　有兩種選擇，一種是拍下減庫存 另外一種是付款減庫存;目前采用的“拍下減庫存”的方式，拍下就是一瞬間的事，對用戶(hù)體驗會(huì )好些。

　　庫存會(huì )帶來(lái)“超賣(mài)”的問(wèn)題：售出數量多于庫存數量

　　由于庫存并發(fā)更新的問(wèn)題，導致在實(shí)際庫存已經(jīng)不足的情況下，庫存依然在減，導致賣(mài)家的商品賣(mài)得件數超過(guò)秒殺的預期。方案：采用樂(lè )觀(guān)鎖

　　auction_auctions set

　　quantity = #inQuantity#

　　where auction_id = #itemId# and quantity = #dbQuantity#

　　秒殺器的應對

　　秒殺器一般下單個(gè)購買(mǎi)及其迅速，根據購買(mǎi)記錄可以甄別出一部分�？梢酝ㄟ^(guò)校驗碼達到一定的方法，這就要求校驗碼足夠安全，不被破解，采用的方式有：秒殺專(zhuān)用驗證碼，電視公布驗證碼，秒殺答題。

　　3 秒殺架構原則

　　盡量將請求攔截在系統上游

　　傳統秒殺系統之所以?huà)�，請求都壓倒了后端數據層，數據讀寫(xiě)鎖沖突嚴重，并發(fā)高響應慢，幾乎所有請求都超時(shí)，流量雖大，下單成功的有效流量甚小【一趟火車(chē)其實(shí)只有2000張票，200w個(gè)人來(lái)買(mǎi)，基本沒(méi)有人能買(mǎi)成功，請求有效率為0】。

　　讀多寫(xiě)少的常用多使用緩存

　　這是一個(gè)典型的讀多寫(xiě)少的應用場(chǎng)景【一趟火車(chē)其實(shí)只有2000張票，200w個(gè)人來(lái)買(mǎi)，最多2000個(gè)人下單成功，其他人都是查詢(xún)庫存，寫(xiě)比例只有0.1%，讀比例占99.9%】，非常適合使用緩存。

【秒殺系統架構分析】相關(guān)文章：

系統架構師的就業(yè)前景分析01-11

基于Web的MES系統安全架構設計及分析10-16

如何搭建系統CSS架構12-31

系統架構設計模式大全08-22

物流管理的合理架構分析10-02

系統架構師是做什么的12-30

如何成為優(yōu)秀的系統架構師06-03

圖書(shū)檢索系統體系架構研究12-05

基于云架構的系統安全設計08-08

系統架構設計師要素01-11