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