python實現秒殺系統 如何設計乙個秒殺系統

2021-10-11 20:28:21 字數 2383 閱讀 9215

前言

業務介紹

什麼是秒殺?通俗一點講就是網路商家為**等目的組織的網上限時搶購活動。

比如說京東秒殺,就是一種定時定量秒殺,在規定的時間內,無論商品是否秒殺完畢,該場次的秒殺活動都會結束。這種秒殺,對時間不是特別嚴格,只要下手快點,秒中的概率還是比較大的。

**以前就做過一元搶購,一般都是限量 1 件商品,同時**低到「令人發齒」,這種秒殺一般都在開始時間 1 到 3 秒內就已經搶光了,參與這個秒殺一般都是看運氣的,不必太強求。

業務特點

瞬時併發量大

秒殺時會有大量使用者在同一時間進行搶購,瞬時併發訪問量突增 10 倍,甚至 100 倍以上都有。

庫存量少

一般秒殺活動商品量很少,這就導致了只有極少量使用者能成功購買到。

業務簡單

流程比較簡單,一般都是下訂單、扣庫存、支付訂單。

技術難點

現有業務的衝擊

秒殺是營銷活動中的一種,如果和其他營銷活動應用部署在同一伺服器上,肯定會對現有其他活動造成衝擊,極端情況下可能導致整個電商系統服務宕機。

直接下訂單

下單頁面是乙個正常的 url 位址,需要控制在秒殺開始前,不能下訂單,只能瀏覽對應活動商品的資訊。簡單來說,需要 disable 訂單按鈕。

頁面流量突增

秒殺活動開始前後,會有很多使用者請求對應商品頁面,會造成後台伺服器的流量突增,同時對應的網路頻寬增加,需要控制商品頁面的流量不會對後台伺服器、db、redis 等元件的造成過大的壓力。

架構設計思想

限流由於活動庫存量一般都是很少,對應的只有少部分使用者才能秒殺成功。所以我們需要限制大部分使用者流量,只准少量使用者流量進入後端伺服器。

削峰秒殺開始的那一瞬間,會有大量使用者衝擊進來,所以在開始時候會有乙個瞬間流量峰值。如何把瞬間的流量峰值變得更平緩,是能否成功設計好秒殺系統的關鍵因素。實現流量削峰填谷,一般的採用快取和 mq 中介軟體來解決。

非同步秒殺其實可以當做高併發系統來處理,在這個時候,可以考慮從業務上做相容,將同步的業務,設計成非同步處理的任務,提高**的整體可用性。

快取秒殺系統的瓶頸主要體現在下訂單、扣減庫存流程中。在這些流程中主要用到 oltp 的資料庫,類似 mysql、sqlserver、oracle。由於資料庫底層採用 b+ 樹的儲存結構,對應我們隨機寫入與讀取的效率,相對較低。如果我們把部分業務邏輯遷移到記憶體的快取或者 redis 中,會極大的提高併發效率。

整體架構

客戶端優化

客戶端優化主要有兩個問題:

秒殺頁面

秒殺活動開始前,其實就有很多使用者訪問該頁面了。如果這個頁面的一些資源,比如 css、js、、商品詳情等,都訪問後端伺服器,甚至 db 的話,服務肯定會出現不可用的情況。所以一般我們會把這個頁面整體進行靜態化,並將頁面靜態化之後的頁面分發到 cdn 邊緣節點上,起到壓力分散的作用。

防止提前下單

防止提前下單主要是在靜態化頁面中加入乙個 js 檔案引用,該 js 檔案包含活動是否開始的標記以及開始時的動態下單頁面的 url 引數。同時,這個 js 檔案是不會被 cdn 系統快取的,會一直請求後端服務的,所以這個 js 檔案一定要很小。當活動快開始的時候(比如提前),通過後台介面修改這個 js 檔案使之生效。

api 接入層優化

客戶端優化,對於不是搞計算機方面的使用者還是可以防止住的。但是稍有一定網路基礎的使用者就起不到作用了,因此服務端也需要加些對應控制,不能信任客戶端的任何操作。一般控制分為 2 大類:

限制使用者維度訪問頻率

針對同乙個使用者( userid 維度),做頁面級別快取,單元時間內的請求,統一走快取,返回同乙個頁面。

限制商品維度訪問頻率

大量請求同時間段查詢同乙個商品時,可以做頁面級別快取,不管下回是誰來訪問,只要是這個頁面就直接返回。

soa 服務層優化

上面兩層只能限制異常使用者訪問,如果秒殺活動運營的比較好,很多使用者都參加了,就會造成系統壓力過大甚至宕機,因此需要後端流量控制。

對於後端系統的控制可以通過訊息佇列、非同步處理、提高併發等方式解決。對於超過系統水位線的請求,直接採取 「fail-fast」原則,拒絕掉。

秒殺整體流程圖

秒殺系統核心在於層層過濾,逐漸遞減瞬時訪問壓力,減少最終對資料庫的衝擊。通過上面流程圖就會發現壓力最大的地方在**?

mq 排隊服務,只要 mq 排隊服務頂住,後面下訂單與扣減庫存的壓力都是自己能控制的,根據資料庫的壓力,可以定製化建立訂單消費者的數量,避免出現消費者資料量過多,導致資料庫壓力過大或者直接宕機。

庫存服務專門為秒殺的商品提供庫存管理,實現提前鎖定庫存,避免超賣的現象。同時,通過超時處理任務發現已搶到商品,但未付款的訂單,並在規定付款時間後,處理這些訂單,將恢復訂單商品對應的庫存量。

總結核心思想:層層過濾

盡量將請求攔截在上游,降低下游的壓力

充分利用快取與訊息佇列,提高請求處理速度以及削峰填谷的作用

原文發布時間為:2018-07-21

秒殺系統如何設計

近來聽到關於秒殺的話題,想起n年前去某當面試,好像有類似設計題,秒殺場景 10w真實使用者參與秒殺,僅有100人可以成功購買商品。考慮到碼農的特殊手段,介面流量咱們按20w去算.思路如下 1 前端控制 技術控制,置灰按鈕 防止重複提交 2 後端負載均衡 分散流量 單機理論極限併發約6w,20w流量需...

秒殺系統實現總結

訪問量大,對網路頻寬要求高 系統如何支援瞬間的高併發 如何防止商品超賣 如何防刷 防黃牛等 cdn快取,nginx lua實現活動資料快取2秒 高併發 限流 防刷 超賣 使用redis實現原子性的操作 防刷 openresty lua 實現限流 驗證黑名單等 黑名單機制 手動 自動收集ip user...

秒殺系統的實現

按照正常的購買流程 查詢商品庫存,庫存大於0時,生成訂單,去庫存。如果出現併發,導致在查詢商品庫存的時候,庫存會一直出現大於0的情況,出現超賣現象。基於mysql的事務和鎖實現方式 如果不開啟事務,第二步即使加鎖,第乙個會話讀庫存結束後,變會釋放鎖,第二個會話仍有機會在去庫存前讀庫存,出現超賣。如果...