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,緩存里面不存在的訂單為成功支付的有效訂單,落庫
2.3 如何解決超賣的問題
redis本質上是沒有辦法保證是否超賣的問題,在高並發下這種現象很常見.以下提供一些解決方案,性能上可以根據實際情況做調整.
1)悲觀鎖
2)樂觀鎖
3)分布式鎖
4)隊列串行化
5)異步隊列分散
6)分段鎖