來自個(gè)人博客 秒殺活動(dòng)的設(shè)計(jì)業(yè)務(wù)的基本說明
運(yùn)營評估最高的并發(fā)會達(dá)到 10W(根據(jù)推廣的力度,以及以往的經(jīng)驗(yàn))
業(yè)務(wù)現(xiàn)有的服務(wù)器架構(gòu) 反向代理 4臺,前端機(jī) 8臺, db 2臺(主從),redis 2臺(主從)以下是服務(wù)器架構(gòu)圖
動(dòng)靜分離html 等靜態(tài)文件上CDN ,這方面壓力不大
后臺程序動(dòng)態(tài)接口,必須支持高并發(fā),用戶體驗(yàn)必須做好
后端程序優(yōu)化點(diǎn)(歡迎大家補(bǔ)充)
程序盡可能的減少加載的文件
程序減少不必要的網(wǎng)絡(luò)請求
redis 隊(duì)列來作 異步方式實(shí)現(xiàn)
// 后臺進(jìn)程消費(fèi)隊(duì)列 個(gè)人使用brpoplpush方法 取出數(shù)據(jù)并用存入另外隊(duì)列作數(shù)據(jù)備份 $block_expire_time = 0; # 設(shè)置阻塞等待時(shí)間為永久 $redis->brpoplpush($key, $backup_key, $block_expire_time);
redis 緩存
前端點(diǎn)擊按鈕請求后變灰,防止用戶重復(fù)點(diǎn)擊
靜態(tài)文件上CDN
nginx的最大連接數(shù)設(shè)置為550,防止連接數(shù)過大時(shí)全部到php,導(dǎo)致php服務(wù)掛了
針對每個(gè)用戶加并發(fā)鎖(redis),防止高并發(fā)情況判斷條件被繞過,程序執(zhí)行完后解鎖。
$lock_status = $redis->set($lock_key, 1, array("NX", "EX"=>$expire_time));高并發(fā)下獎(jiǎng)品超發(fā)問題
個(gè)人設(shè)計(jì)的方案:提前把每個(gè)獎(jiǎng)品放入 redis隊(duì)列,每個(gè)key一個(gè)獎(jiǎng)品,隊(duì)列的長度是獎(jiǎng)品的數(shù)量,可以保證獎(jiǎng)品不會超發(fā)放
另外,假設(shè)使用
悲觀鎖,在更新數(shù)據(jù)的時(shí)候加鎖,其它的都為等待狀態(tài),不合適秒殺場景
樂觀鎖 基本是采用帶版本號更新,版本號匹配才能更新,其它的回滾,雖然保證的數(shù)據(jù)的安全不超發(fā)放,但是在高并發(fā)場景下,DB只有兩臺的時(shí)候,超過mysql 進(jìn)程堆積肯定會的, 超過最大連接數(shù)是怎么辦,一系列的問題需要解決,所以該方案不合適
在平均響應(yīng)時(shí)間300ms內(nèi),單臺qps 750 左右(保持300ms是公司壓測試的規(guī)范指標(biāo))
10臺機(jī)器(后面新增2臺到 8+2)一秒鐘能處理: 10 * 750 = 7500
保守的并發(fā)只有7500,與10w 差距大,需要在執(zhí)行方案上解決,公司不可無限的申請web機(jī)器。
解決10W并發(fā)問題(資源有限的情況)方案
在代理層做處理,根據(jù)權(quán)重?fù)醯?3%的量,返回800(自定義),前端判斷是否為800,是則提示火爆用戶重試(對應(yīng)的方案設(shè)置友好一些)
接口程序不連接查詢mysql數(shù)據(jù)庫
獎(jiǎng)品的數(shù)據(jù)存放redis隊(duì)列,每個(gè)獎(jiǎng)品一個(gè)key,隊(duì)列長度是獎(jiǎng)品的數(shù)量
用戶成功領(lǐng)取紅包(或搶購)時(shí)的代碼流程(不包括業(yè)務(wù)限制與防刷),從隊(duì)列獲取獎(jiǎng)品成功,再入隊(duì)列(此隊(duì)列后臺消費(fèi)入庫),返回給用戶領(lǐng)取成功。在用戶體驗(yàn)上有所提升,但如果后臺隊(duì)列堆積太多,未能消費(fèi)完成,用戶查看的紅包時(shí)是沒有對應(yīng)記錄的,所以針對自己的需求作對應(yīng)的優(yōu)化。
活動(dòng)流程圖(開爺畫的)文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/39474.html
摘要:即使秒殺系統(tǒng)崩潰了,也不會對網(wǎng)站造成影響。動(dòng)態(tài)生成隨機(jī)下單頁面的為了避免用戶直接訪問下單需要將動(dòng)態(tài)化,用隨機(jī)數(shù)作為參數(shù),只能秒殺開始的時(shí)候才生成。架構(gòu)設(shè)計(jì)如何控制秒殺商品頁面搶購按鈕的可用禁用。該文件不被緩存的做法隨機(jī)數(shù)。 秒殺背景 電商中為了吸引顧客、聚集人氣,經(jīng)常會策劃一些秒殺活動(dòng)?;顒?dòng)中售賣的商品,要么價(jià)格遠(yuǎn)低于市場價(jià)格,要么比較稀缺(如一些新發(fā)布的商品)。這些商品電商一般都會限...
摘要:即使秒殺系統(tǒng)崩潰了,也不會對網(wǎng)站造成影響。動(dòng)態(tài)生成隨機(jī)下單頁面的為了避免用戶直接訪問下單需要將動(dòng)態(tài)化,用隨機(jī)數(shù)作為參數(shù),只能秒殺開始的時(shí)候才生成。架構(gòu)設(shè)計(jì)如何控制秒殺商品頁面搶購按鈕的可用禁用。該文件不被緩存的做法隨機(jī)數(shù)。 秒殺背景 電商中為了吸引顧客、聚集人氣,經(jīng)常會策劃一些秒殺活動(dòng)?;顒?dòng)中售賣的商品,要么價(jià)格遠(yuǎn)低于市場價(jià)格,要么比較稀缺(如一些新發(fā)布的商品)。這些商品電商一般都會限...
摘要:即使秒殺系統(tǒng)崩潰了,也不會對網(wǎng)站造成影響。動(dòng)態(tài)生成隨機(jī)下單頁面的為了避免用戶直接訪問下單需要將動(dòng)態(tài)化,用隨機(jī)數(shù)作為參數(shù),只能秒殺開始的時(shí)候才生成。架構(gòu)設(shè)計(jì)如何控制秒殺商品頁面搶購按鈕的可用禁用。該文件不被緩存的做法隨機(jī)數(shù)。 秒殺背景 電商中為了吸引顧客、聚集人氣,經(jīng)常會策劃一些秒殺活動(dòng)?;顒?dòng)中售賣的商品,要么價(jià)格遠(yuǎn)低于市場價(jià)格,要么比較稀缺(如一些新發(fā)布的商品)。這些商品電商一般都會限...
摘要:動(dòng)態(tài)生成隨機(jī)下單頁面的為了避免用戶直接訪問下單需要將動(dòng)態(tài)化,用隨機(jī)數(shù)作為參數(shù),只能秒殺開始的時(shí)候才生成。該文件不被緩存的做法隨機(jī)數(shù)。淺談秒殺系統(tǒng)架構(gòu)設(shè)計(jì)如何只允許,第一個(gè)提交的單進(jìn)入訂單系統(tǒng)。未超過秒殺商品總數(shù),提交到子訂單系統(tǒng)。 秒殺是電子商務(wù)網(wǎng)站常見的一種營銷手段。 原則 不要整個(gè)系統(tǒng)宕機(jī)。 即使系統(tǒng)故障,也不要將錯(cuò)誤數(shù)據(jù)展示出來。 盡量保持公平公正。 實(shí)現(xiàn)效果 秒殺開始前,...
摘要:但很顯然這些請求的處理性能并不好,有沒有更好的解決方案這時(shí)可以想到布隆過濾器。系統(tǒng)根據(jù)商品,先從布隆過濾器中查詢該是否存在,如果存在則允許從緩存中查詢數(shù)據(jù),如果不存在,則直接返回失敗。所以布隆過濾器絕大部分使用在緩存數(shù)據(jù)更新很少的場景中。高并發(fā)下如何設(shè)計(jì)秒殺系統(tǒng)?這是一個(gè)高頻面試題。這個(gè)問題看似簡單,但是里面的水很深,它考查的是高并發(fā)場景下,從前端到后端多方面的知識。 秒殺一般出現(xiàn)在商...
閱讀 2238·2021-09-24 10:31
閱讀 3889·2021-09-22 15:16
閱讀 3411·2021-09-22 10:02
閱讀 1026·2021-09-22 10:02
閱讀 1842·2021-09-08 09:36
閱讀 1988·2019-08-30 14:18
閱讀 617·2019-08-30 10:51
閱讀 1881·2019-08-29 11:08