秒殺系統(tǒng)搭建,要easy
秒殺是電商平臺的常見配置,用戶看到的呈現效果都需要后端的支持,那么,秒殺的后端系統(tǒng)如何根據前端業(yè)務需求做調整?筆者針對這個問題,進行了具體的闡述。
秒殺是電商平臺最常用的促銷活動,例如京東淘寶等主流電商平臺把秒殺、搶購作為一個功能入口存在,定期秒殺。
其產品定位在于通過低價促銷吸引對價格敏感的用戶,起到引流促活,且?guī)愉N售。
下圖是京東、淘寶的秒殺頁面。
那么一個秒殺系統(tǒng)如何搭建?前后端功能如何配合?
都說“前端一小步,后端一大步”,對于C端來說,價格、商品吸引人,我能到特定時間去搶購、付款就可以了。
那么,后端如何做相應的功能支撐呢?
下面我具體闡述一下。
一、秒殺架構
秒殺架構
從此架構看出,一個秒殺完整的系統(tǒng)搭建,后端需要有商家報名參與入口、秒殺活動的設置、后臺秒殺活動、訂單管理等功能。
二、 商家報名流程
平臺可以給商家提供這樣的功能入口,一旦商家有意愿做秒殺活動,可以發(fā)起由平臺審核,審核通過即可上架。
- 商家是否滿足要求:是否對參與商家設置門檻,比如經營較好,店鋪綜合評分較高的店鋪方可參與;
- 提報商品是否滿足:比如此商品設置價格合理,是否是違規(guī)商品等。
這里我只簡單論述,具體需根據每個企業(yè)業(yè)務性質進行考量。
三、秒殺活動設置
- 活動信息:包括秒殺時間、渠道、秒殺模板(不會做圖的商家可提供模板套用);
- 活動限制條件:每個用戶的限制購買次數、購買數量等;
- 活動商品:設置活動商品價格、庫存、時間段等。
四、秒殺搶購
對于C端用戶是否有意愿參與秒殺、是否有心儀的商品、搶購流程是否順暢等需求點進行考慮。
- 是否有意愿參與秒殺:首先前端交互效果一定要引人入勝;
- 是否有心儀商品:價格、商品是否吸引用戶;
- 搶購是否順暢:活動預熱是否充分,可設置提醒/活動開始時候庫存是否充足,是否超過限購數量,售完是否可以原價購買等;
下面是我自己整理的秒殺流程圖,僅供借鑒。
五、技術層面實現
這部分也是參考一些大神的博客得出的一些技術層面的心得,可能不是很恰當,希望大家指正。
1. 前端高并發(fā)
前端常用的方法是擴容、靜態(tài)化、限流。
擴容:
加機器,這是最簡單的方法,通過增加前端池的整體承載量來抗峰值。
舉個通俗的例子:
比如我想運送100棵樹木,我準備兩輛卡車,一輛運50,計算公式就是2輛X50棵/輛X1小時=100棵/小時。
那如果我需要搬運更多的樹木,我可以通過增加車輛、也可以增加每輛車的運輸量、或者縮短運輸時間。
這就是擴容的概念。
靜態(tài)化:
將活動頁面上的所有可以靜態(tài)的元素全部靜態(tài)化,并盡量減少動態(tài)元素,通過CDN來抗峰值。
限流:
一般都會采用IP級別的限流,即針對某一個IP,限制單位時間內發(fā)起請求數量;或者在活動入口,增加游戲或者問題環(huán)節(jié)進行消峰操作。
有損服務:
最后一招,在接近前端池承載能力的水位上限的時候,隨機拒絕部分請求來保護活動整體的可用性。
2. 后端如何解決
方案:本地標記+redis預處理+RabbitMQ異步下單+客戶端輪詢。
實現:
- 在秒殺階段使用本地標記對用戶秒殺過的商品做標記,若被標記過直接返回重復秒殺,未被標記才查詢redis,通過本地標記來減少對redis的訪問。
- 搶購開始前,將商品和庫存數據同步到redis中,所有的搶購操作都在redis中進行處理,通過Redis預減少庫存減少數據庫訪問。
- 為了保護系統(tǒng)不受高流量的沖擊而導致系統(tǒng)崩潰的問題,使用RabbitMQ用異步隊列處理下單,實際做了一層緩沖保護,做了一個窗口模型,窗口模型會實時的刷新用戶秒殺的狀態(tài)。
- client端用js輪詢一個接口,用來獲取處理狀態(tài)。
六、總結
以上是自己對于設計秒殺系統(tǒng)的思路,不喜勿噴。如果大家有更多的思路希望和我多多交流,不斷補充。
作者:琛??;公眾號:宇說產品
本文由 @琛琛 原創(chuàng)發(fā)布于人人都是產品經理,未經許可,禁止轉載
題圖來自 Unsplash,基于 CC0 協(xié)議
真的好 謝謝,很全面 作為產品來說這才是最棒的
商家報名成功后庫存要不要鎖定
這是講技術還是講產品 哈哈哈
你是技術轉產品嗎?
你們?yōu)槭裁催@么問呢?有啥秘密秘?嘿嘿
秒殺整體架構講清楚了
??
?