資訊專欄INFORMATION COLUMN
摘要：動態(tài)生成隨機下單頁面的為了避免用戶直接訪問下單需要將動態(tài)化，用隨機數(shù)作為參數(shù)，只能秒殺開始的時候才生成。該文件不被緩存的做法隨機數(shù)。淺談秒殺系統(tǒng)架構(gòu)設(shè)計如何只允許，第一個提交的單進入訂單系統(tǒng)。未超過秒殺商品總數(shù)，提交到子訂單系統(tǒng)。
秒殺是電子商務(wù)網(wǎng)站常見的一種營銷手段。
原則
不要整個系統(tǒng)宕機。
即使系統(tǒng)故障，也不要將錯誤數(shù)據(jù)展示出來。
盡量保持公平公正。
實現(xiàn)效果
秒殺開始前，搶購按鈕為活動未開始。
秒殺開始時，搶購按鈕可以點擊下單。
秒殺結(jié)束后，按鈕按鈕變成秒殺已結(jié)束。
技術(shù)攻關(guān)
短時間內(nèi)的大訪問量對現(xiàn)有網(wǎng)站業(yè)務(wù)造成的沖擊。
秒殺是一個網(wǎng)站營銷的一個附加活動，時間短，并發(fā)量大。
如果和網(wǎng)站原有應(yīng)用部署在一起，必然會對現(xiàn)有業(yè)務(wù)造成沖擊，稍有不慎可能導(dǎo)致整個網(wǎng)站癱瘓。
高并發(fā)下對服務(wù)器數(shù)據(jù)庫造成的極大負載壓力。
用戶秒殺開始前，通過不斷刷新瀏覽器來保證不會錯過秒殺活動。
頻繁的訪問程序、數(shù)據(jù)庫會對應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器造成負載壓力。
網(wǎng)絡(luò)帶寬的問題比超過平時好多倍。
如果秒殺頁面的大小為200K，如果最大并發(fā)數(shù)為10000次，那么需要的網(wǎng)絡(luò)和服務(wù)器帶寬是2G（200K×10000）。
這些網(wǎng)絡(luò)帶寬是因為秒殺活動新增的，超過網(wǎng)站平時使用的帶寬。
避免直接下單。
秒殺的游戲規(guī)則是到了秒殺才能開始對商品下單購買，在此時間點之前，只能瀏覽信息不可下單。
而下單頁面也是一個普通的URL，如果得到這個URL，不用等到秒殺開始就可以下單了。
應(yīng)對策略
秒殺系統(tǒng)獨立部署
為了避免短時間內(nèi)的大訪問量對現(xiàn)有網(wǎng)站業(yè)務(wù)造成的沖擊，可以將秒殺系統(tǒng)獨立部署。
如果需要還可以使用獨立域名，使其與網(wǎng)站完全隔離。
即使秒殺系統(tǒng)崩潰了，也不會對網(wǎng)站造成影響。
秒殺商品頁面靜態(tài)化
將商品描述、參數(shù)、詳情，全部寫到一個靜態(tài)頁面，不用進行程序的邏輯處理，不需訪問數(shù)據(jù)庫。
不用部署動態(tài)的服務(wù)器和數(shù)據(jù)庫服務(wù)器。
租借秒殺活動的網(wǎng)絡(luò)帶寬
因為秒殺新增的網(wǎng)絡(luò)帶寬，必須和運營商重新購買或租借帶寬。
為了減輕服務(wù)器的壓力，需要將秒殺商品頁面緩存在CDN,同樣CDN服務(wù)器也需要臨時租借帶寬。
動態(tài)生成隨機下單頁面的URL
為了避免用戶直接訪問下單URL,需要將URL動態(tài)化，用隨機數(shù)作為參數(shù)，只能秒殺開始的時候才生成。
架構(gòu)設(shè)計
如何控制秒殺商品頁面搶購按鈕的可用/禁用。
購買按鈕只有在秒殺開始的時候才能點亮，在此之前是灰色的，顯示活動未開始。 如果頁面是動態(tài)生成的，每次刷新都要請求服務(wù)器，那么勢必造成服務(wù)端的負載壓力。 如果頁面是靜態(tài)頁面的話，可以將頁面緩存在CDN，反向代理服務(wù)器上，甚至用戶瀏覽器上。 但是這樣，秒殺開始時，用戶刷新頁面，根本請求不到應(yīng)用服務(wù)器。 解決方案： 使用JS腳本控制，在頁面中引用一個JS文件(文件極小)，但是該文件不要被緩存。 該JS的作用是，包含秒殺開始標志，修改樣式，生成下單頁面的URL及隨機參數(shù)。 該JS文件不被緩存的做法：xxx.js?v=隨機數(shù)。 會有一臺服務(wù)器進行監(jiān)控(定時上下架)： 當秒殺活動開始時推送該文件。 當秒殺活動結(jié)束時推送文件，標示結(jié)束標志，修改樣式。 如下圖。
淺談秒殺系統(tǒng)架構(gòu)設(shè)計-1
如何只允許，第一個提交的單進入訂單系統(tǒng)。
由于秒殺到商品的用戶只有一個，因此需要在提交訂單時，進行下單前置檢查。 如果已經(jīng)有訂單提交成功，表示活動結(jié)束，進入秒殺結(jié)束頁面。 事實上，訂單數(shù)只能有一個，為了減輕下單頁面服務(wù)器的負載壓力，可以控制進入下單頁面的入口。 只有少數(shù)用戶能進入下單頁面，其他用戶直接進入秒殺結(jié)束頁面。 （前置檢查邏輯）檢查本機已處理的下單請求數(shù)目： 如果超過10條，直接返回已結(jié)束頁面給用戶。 如果未超過10條，則用戶可進入填寫訂單及確認頁面。 （前置檢查邏輯）檢查全局已提交訂單數(shù)目： 已超過秒殺商品總數(shù)，返回秒殺結(jié)束頁面。 未超過秒殺商品總數(shù)，提交到子訂單系統(tǒng)。 如下圖。
淺談秒殺系統(tǒng)架構(gòu)設(shè)計-2
減庫存的操作
拍下減庫存(用戶體驗好)
付款減庫存
下訂單盡可能簡單，購買數(shù)據(jù)為1且不可編輯，送貨地址和付款方式為空或用戶默認，允許訂單提交后修改。
文章借鑒書籍《大型網(wǎng)站技術(shù)架構(gòu)》。
推薦閱讀系統(tǒng)的講解 - SSO 單點登錄
系統(tǒng)的講解 - PHP WEB 安全防御
系統(tǒng)的講解 - PHP 緩存技術(shù)
系統(tǒng)的講解 - PHP 接口簽名驗證
系統(tǒng)的講解 - PHP 浮點數(shù)高精度運算
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/21960.html
摘要：淺談秒殺系統(tǒng)架構(gòu)設(shè)計后端掘金秒殺是電子商務(wù)網(wǎng)站常見的一種營銷手段。這兩個項目白話網(wǎng)站架構(gòu)演進后端掘金這是白話系列的文章。 淺談秒殺系統(tǒng)架構(gòu)設(shè)計 - 后端 - 掘金秒殺是電子商務(wù)網(wǎng)站常見的一種營銷手段。 不要整個系統(tǒng)宕機。 即使系統(tǒng)故障，也不要將錯誤數(shù)據(jù)展示出來。 盡量保持公平公正。 實現(xiàn)效果 秒殺開始前，搶購按鈕為活動未開始。 秒殺開始時，搶購按鈕可以點擊下單。 秒殺結(jié)束后，按鈕按鈕變...
摘要：作為面試官，我是如何甄別應(yīng)聘者的包裝程度語言和等其他語言的對比分析和主從復(fù)制的原理詳解和持久化的原理是什么面試中經(jīng)常被問到的持久化與恢復(fù)實現(xiàn)故障恢復(fù)自動化詳解哨兵技術(shù)查漏補缺最易錯過的技術(shù)要點大掃盲意外宕機不難解決，但你真的懂數(shù)據(jù)恢復(fù)嗎每秒 作為面試官，我是如何甄別應(yīng)聘者的包裝程度Go語言和Java、python等其他語言的對比分析 Redis和MySQL Redis：主從復(fù)制的原理詳...
摘要：作為面試官，我是如何甄別應(yīng)聘者的包裝程度語言和等其他語言的對比分析和主從復(fù)制的原理詳解和持久化的原理是什么面試中經(jīng)常被問到的持久化與恢復(fù)實現(xiàn)故障恢復(fù)自動化詳解哨兵技術(shù)查漏補缺最易錯過的技術(shù)要點大掃盲意外宕機不難解決，但你真的懂數(shù)據(jù)恢復(fù)嗎每秒 作為面試官，我是如何甄別應(yīng)聘者的包裝程度Go語言和Java、python等其他語言的對比分析 Redis和MySQL Redis：主從復(fù)制的原理詳...
摘要：幾個月后，申請了碼云的通過了。隨著年齡的增長，你會覺得技術(shù)不再是第一位，技術(shù)永遠是為業(yè)務(wù)來服務(wù)的。 showImg(https://segmentfault.com/img/bVbuy3x?w=720&h=405); 2019年已過去大半年，差不多也是這個時候，提交了分布式秒殺系統(tǒng)的第一版，查看了一下提交記錄，居然是2018年5月12日。 對于我來說，這個項目可能就是個偶然，你想想一個...
閱讀 1262·2021-09-04 16:41
閱讀 2428·2021-09-02 10:18
閱讀 927·2019-08-29 16:40
閱讀 2624·2019-08-29 16:14
閱讀 918·2019-08-26 13:41
閱讀 1311·2019-08-26 12:24
閱讀 742·2019-08-26 10:24
閱讀 2882·2019-08-23 17:54
