松花皮蛋的黑板報
  • 分享在京東工作的技術感悟,還有JAVA技術和業內最佳實踐,大部分都是務實的、能看懂的、可復現的

掃一掃
關注公眾號

秒殺系統技術解剖

博客首頁文章列表 松花皮蛋me 2019-08-19 12:47

我們知道秒殺類的活動對整個運營貢獻是最大的,它的特點是瞬間流量俱增、請求數量遠大于庫存,導致保證下單扣庫存準確性難度大,那我們前端、后端怎么做才能保證呢?下面是我的一些思考。


先來說說整體的設計理念,秒殺類的活動光靠水平擴展擴增機器只能是個備選方案,它的成本和收益不對等。那我們就應該盡量利用有效的資源最大化處理業務,可從限流、異步處理、內存緩存角度考慮。


接下來說說具體的落地方案。秒殺類的活動前端一般會展示商品描述、秒殺價格、已售比例、時間提示,這些內容基本上是不變的,那我們可以通過內容分發CDN機制來將頁面靜態化,減少動態元素。前端還需要減少用戶提交次數,用戶提交之后按鈕置灰,禁止重復提交,但是別忘記了還有刷子這個灰色產業鏈,所以后端還需要做一些限制。


在后端的服務控制層針對同一訪問UID,限制請求頻率。或者先把請教都寫到消息隊列中緩存一下,邏輯層訂閱消息減庫存,減庫存成功的請求返回秒殺成功,失敗的返回秒殺結束。甚至,我們可以利用緩存來應對讀寫請求,首先把庫存信息同步到Redis緩存中,所以的減庫存操作都Redis中進行,然后同步到數據庫中。實際上,這些還遠遠不夠,我們還需要考慮以下場景。


場景一是同一個賬號,一次性發出多個請求。我們可以利用Redis內容緩存來判斷用戶是否已參加過了活動,寫入一個標志位,結合樂觀鎖特性約束只允許一個請求寫成功,成功寫入的也就是沒有記錄的才能繼續參加。


場景二是多個賬號,一次性發送多個請求。針對這種場景,我們通過檢測指定機器IP請求頻率可以解決,如果發現某個請求IP請求頻率過高,可以給它彈出一個驗證碼或者直接禁止它的請求。


場景三是多個賬號,不同IP發送不同的請求。這種場景下的請求,和真實用戶行為基本相同,想做分辨很難,需要通過賬號數據進行數據挖掘后打標,結合是否經常搶票、退票等等標識為風控用戶。


其實秒殺類的活動最大的挑戰是如何保證高并發下的數據安全和防刷,這是一個矛與盾的博弈。總結一下今天的文章重點,針對秒殺系統,盡量將請求攔截在系統上游,越上游越好,另外讀多寫少的多使用緩存。好,今天的分享就到這里,歡迎分享給你的朋友。

黑龙江6+1开奖结果查询