Java生鮮電商平臺-促銷架構以及秒殺解決方案實戰

Java生鮮電商平臺-促銷架構以及秒殺解決方案實戰

背景:
隨着這幾年的電商的大熱,咱們常常看到一些商家爲了促銷和快速收益,紛紛推出了秒殺活動.無論是平常的超市裏面的促銷,明星演唱會門票售賣,仍是春節訂閱火車票,等等咱們都能看到秒殺活動的影子.

1. 構建秒殺活動架構

1.1 說明

  系統架構的設計,必定程度上取決於流量的多少、流量的洪峯值和波谷值,有效的預估好流量是相當重要的一步,流量的大小不同,咱們的架構設計相應的也會不同.這會影響到後續的系統架構設計.反而系統的搭建並非最難的部分,由於如今不少大公司,都有一套本身的成熟架構體系

1.2 關鍵設計

1.2.1 圍繞着產品設計,驅動技術.

  1).通常秒殺活動都是T+N的,這樣設計的好處,就是提早幫咱們預估好用戶流量,這一步也會影響到咱們是否擴容,至於坊間傳說的臨時擴容,本人一直持保守態度,顯然對於大流量洪峯來臨,這種臨時擴容的方案還不夠成熟,由於微博一直在砰砰打臉.
  2).秒殺活動前,來一波小遊戲,有些人問是否是產品腦子冒泡?我是來秒殺商品的.....
  3).秒殺活動前,需輸入12306式的驗證碼,產品是否是又該捱打?
  4).秒殺活動前,倒計時彈幕提醒,產品已gg

其實這些小伎倆的設計,一方面爲了防止活動未開始前大流量涌入,一方面是爲了防止惡意用戶攻擊,另外一方面是爲活動造勢

1.2.2 緩存和預熱

  1).頁面靜態話,靜態頁面部署在CDN服務器上,服務器多機房部署,異地多活,使得用戶能就近訪問到相應的節點服務器.
  2).redis雙泳道
  3).熱點數據提早落地

1.2.3 消息中間件MQ

  延遲隊列、阻塞隊列

1.2.4 限流、降級

  推薦sentinel開源中間件,sentinel是以流量爲切入點,從流量控制、熔斷降級、系統負載保護等多個緯度保護服務穩定性.sentinel和谷歌guaval不一樣的地方在於它能夠作到全局性的限流.對於快到水位線時候,能夠隨機拒絕一些請求,作好保護.

1.2.5 網關攔截

  過濾和限制惡意請求和爬蟲之類的,限制參與秒殺的用戶須要登錄的token

1.2.6 是否查詢數據庫

  大型秒殺活動是能夠不查數據庫的,數據異步落庫就行

2. 技術難點

其實在第一章節,我並無過細的贅述,由於如今業界這些框架已經很是成熟了,拿來即用,甚至有些活動並無那麼的流量,可能都無需限流.

2.1 庫存是否鎖定

  是否鎖定庫存須要看場景,像賣林俊杰演唱會門票這種,是無需鎖庫存的,why?
  對於用戶購買意願很是強烈的活動中,是無需鎖定庫存的,一方面能夠作到公平購買,另外一方面防止一些用戶其實就是看看的心態,下單了不付錢,致使那些真正想買的人買不到票.而通常的活動是須要鎖定庫存的,即用戶預下單後就鎖定庫存,可是通常咱們秒殺的訂單都具備時效性,通常在5-30分鐘不等.

2.2 如何釋放庫存

  1)首先查詢庫存,檢查庫存情況,庫存不足直接返回前端.
  2)庫存夠,用戶能夠購買商品,用戶預下單
  3)服務端構建用戶訂單消息,鎖定庫存,推送訂單消息給延遲消費隊列和更新訂單緩存,調用預下單接口,而後調用第三方預支付接口
  4)前端喚起sdk去付款
  5)支付成功,第三方支付會回調通知商戶,而後通知業務線去更新支付狀態
  6)規定時間裏面成功支付的訂單,刪掉緩存
  7)延遲消費隊列監聽,先查詢緩存,看緩存數據是否存在,存在的爲,超時訂單,須要釋放庫存加1,緩存裏面不存在的訂單爲成功支付的有效訂單,落庫

 

支付.jpg

2.3 如何解決超賣的問題

redis本質上是沒有辦法保證是否超賣的問題,在高併發下這種現象很常見.如下提供一些解決方案,性能上能夠根據實際狀況作調整.

  1)悲觀鎖   2)樂觀鎖   3)分佈式鎖   4)隊列串行化   5)異步隊列分散   6)分段鎖