電商搶購秒殺系統的設計_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,靈活運用基於條件的限速功能,行爲識別模塊,機器人緩解模塊。今天先聊到這兒,後續會總結出本文提到的很多技術細節。



電商搶購秒殺系統的設計_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,靈活運用基於條件的限速功能,行爲識別模塊,機器人緩解模塊。今天先聊到這兒,後續會總結出本文提到的很多技術細節。


發佈了15 篇原創文章 · 獲贊 35 · 訪問量 19萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章