電商搶購秒殺系統的設計_1_應用場景分析

電商搶購秒殺系統的設計_1_應用場景分析

概述

所謂知已知彼，百戰不殆，在開始詳細介紹實戰中的搶購秒殺系統時，咱們瞭解一些搶購秒殺系統系統面臨的尷尬與難點。另外須要說明一點，下面的內容都是在工做中慢慢總結得來，咱們團隊也是慢慢摸着石頭過河，甚至最初的的架構設計並不是是搶購秒殺系統。

評估系統處理能力

理論基礎：LNMP的併發考慮與資源分配

雖然有基礎去評估咱們應用系統的處理能力，可是電商購買的業務流程挺複雜，從登陸，商品詳情，購物車，填寫收貨地址，選擇支付方式，建立訂單，完成支付，以及隱含的定時服務，限購策略，庫存操做，排隊機制等一系列的業務邏輯，每一個請求的處理時間都不同。那麼根據木桶原理，一隻水桶能將多少水取決於它最短的那塊木板，分析整個業務流程中最耗系統資源的請求，以此爲標準爲評估系統處理能力。

場景

咱們是一個作特賣秒殺搶購的電商平臺，咱們的商品異常火爆且價格低廉價，這就給網絡黃牛帶了巨大的利潤空間。爲了讓真正的平臺用戶受益，改善用戶體驗，提升用戶留存率，咱們在產品業務、技術實現上嘗試了不少方法，都沒有完美解決黃牛刷單的問題。

目標

話說回來，讓黃牛買不到商品，不是單純技術可以解決的問題。咱們要解決的問題是，因爲黃牛大規模的請求登陸接口、商品詳情頁接口、下單接口致使在搶購開始先後的流量峯值直接翻了上千倍，最終致使服務不可用。在不增長硬件成本的狀況下，解決短期內大流量致使的服務不可用。

產品特徵

以H5應用爲主站主要流量入口，支持QQ、微信、微博等平臺用戶登陸購買，嵌入到某流行的資訊客戶端。另外，也有單獨的特賣安卓客戶端、IOS客戶端。

刷單特徵

帳號

黃牛每次搶購活動註冊新用戶，因爲平臺流量大部分來自某新聞客戶端，客戶端的帳號體系爲弱帳號體系，能夠綁定手機號也能夠解除綁定，每次從新綁定都會生成新的用戶ID。同時平臺也容許非手機號註冊的用戶下單購買商品，用戶的收貨地址的聯繫電話能夠和註冊帳號的手機號不一致。另外一方面，黃牛在淘寶花錢能夠購買大量的平臺新註冊帳號，真是術業有專攻。

IP庫

在雲服務盛行的互聯網時代，黃牛以很低的成本能夠得到上萬的IP及主機，IP分佈在全球各地。

頻次

黃牛刷單時訪問頻次不是很高，在擁有大量帳號、IP的狀況下，訪問頻次低也能夠搶購到商品。

破解原生App

黃牛的技術很強，將混淆加密後的原生客戶端破解，將其中的加密算法重寫，升級搶購軟件。

CC攻擊

黃牛爲了不預定用戶將商品提早搶光，聯合全國的黃牛同時高頻次的訪問網站數據接口，致使網站因爲大流量下不堪重負，從而服務不可用，在預定提早購買時間過去（黃牛的目的是堵住預定用戶購買），全網用戶都可購買時，慢慢的減小流量，任意下單購買商品。

產品與技術措施

產品業務角度

預定購買

全網用戶提早預定，具備預定購買資格的用戶可享受提早入場下單購買。預定須要綁定手機號，輸入驗證碼（短信和圖片）。

搶購排隊

爲了應對短期內的大流量請求，採用排隊購買機制，用戶提交購買請求後當即返回，等待後端處理結果。

引流

在預知大流量不可控時，將H5主站流量引到原生的客戶端APP內進行搶購。

技術防守角度

驗證碼

在搶購開始時，下單購買某商品必須輸入驗證碼。在必定時間內，對於訪問庫存爲0的用戶請求，超過必定頻次後要求輸入驗證碼。打碼雲服務不少，理論上字符驗證碼都可識別，甚至人工打碼，可是提升了刷單成本。

IP禁止策略

經過nginx的lua擴展，在單位時間內同用戶相同IP請求同一URL進行計數，在nginx層面進行限流。IP級別下，控制很差，誤殺太多或者起不了做用。

fastcgi請求計數

設定PHP可併發處理請求的最大值，nginx交給PHP的請求都進行計數+1，fastcgi完成後進行-1。因爲nginx+php-fpm高併發狀況下，作到原子的計數很難。

隊列

引入消息隊列和長鏈接服務，用戶請求排隊購買，後端進行流量控制，發放資格號，經過長鏈接通知用戶的處理結果。

靜態化

將商品詳情頁靜態化，靜態頁面的請求直接由CDN返回。

創建黃牛帳號庫

通過幾回大規模的搶購後，黃牛帳號有限，將積累的黃牛帳號入庫，在下次搶購時，載入內存，下降購買優先級或者直接拒絕請求。

增長服務器

從原有的幾臺服務器，擴容到幾十臺服務器，每一個服務都部署負載均衡、高可用。如多級緩存、nginx與php-fpm分離、長鏈接服務器集羣等等。

可伸縮架構

搶購開始前準備上百倍的服務器數量，全部的服務都可橫向擴展，提升處理能力。

上面交待了挺多的作搶購平臺的一些場景、特徵、措施，涉及的產品和技術的面廣，我認爲最重要的是解決網站服務不可用或者宕機的問題，咱們在nginx層面作了不少努力與嘗試，另外nginx在防CC攻擊方面有一些成熟的方案，下面詳述，下一階段研究nginx源碼。

nginx請求限制模塊

ngx_http_limit_conn_module

限制鏈接數模塊

一般用來限制同一IP地址的可併發鏈接數

指令說明：http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html

須要注意的是$binary_remote_addr而不是$remote_addr，$remote_addr的長度爲7到15個字節，它的會話信息的長度爲32或64 bytes，$binary_remote_addr的長度爲4字節，會話信息的長度爲32字節，這樣設置1M的一個zone時，用$binary_remote_addr方式，該zone將會存放32000個會話。

ngx_http_limit_req_module

限制請求數模塊

一般用來限制同一IP地址單位時間可完成的請求數，限制的方法是採用漏桶算法(Leaky Bucket)，每秒處理固定請求數量，推遲過多請求，超過桶的閥值，請求直接終止返回503。

指令說明：http://nginx.org/en/docs/http/ngx_http_limit_req_module.html

基於nginx的Tengine分支ngx_http_limit_req_module

nginx相似，不過支持多個變量，而且支持多個limit_req_zone及forbid_action的設置。

指令說明：http://tengine.taobao.org/document_cn/http_limit_req_cn.html

基於nginx的Senginx分支的ngx_http_limit_req_module

指令說明：http://www.senginx.org/cn/index.php/%E5%9F%BA%E4%BA%8E%E6%9D%A1%E4%BB%B6%E7%9A%84%E9%99%90%E9%80%9F%E5%8A%9F%E8%83%BD

稱之爲基於條件的限速功能，在Tenginer的limit_req模塊基礎上，增長condition參數，在條件爲真時執行限制動做。

基於nginx的Senginx分支的ngx_http_ip_behavior

指令說明：http://www.senginx.org/cn/index.php/%E8%AE%BF%E9%97%AE%E8%A1%8C%E4%B8%BA%E8%AF%86%E5%88%AB%E6%A8%A1%E5%9D%97

稱之爲行爲識別模塊，訪問行爲識別模塊的做用是對用戶訪問網站的行爲進行監控

基於nginx的Senginx分支的ngx_http_robot_mitigation

指令說明：http://www.senginx.org/cn/index.php/Robot_Mitigation%E6%A8%A1%E5%9D%97

稱之爲HTTP機器人緩解，Robot Mitigation模塊採用了一種基於「挑戰」的驗證方法，即向客戶端發送特定的、瀏覽器能解析的應答，若是客戶端是真實的瀏覽器，則會從新觸發請求， 並帶有一個特定的Cookie值，Robot Mitigation模塊會依據此Cookie的信息來決定是否放行此請求。

最後

基於上述的場景、特徵、nginx限制模塊的調研和分析，咱們徹底能夠經過靈活的nginx配置來解決CC攻擊威脅。使用了Senginx，靈活運用基於條件的限速功能，行爲識別模塊，機器人緩解模塊。今天先聊到這兒，後續會總結出本文提到的不少技術細節。