消息中間件的應用——談談秒殺（轉）

轉自公衆號-消息中間件

業務描述如今電商企業一大把，除了某寶、某東等大鱷，還有各類街、某說、某會、沒有品等創業明星，以及蘇寧、國美等傳統企業的電商部門，可謂百花齊放。電商以運營爲基礎，各類活動、購物節層出不窮，秒殺可謂是其中的一朵奇葩——價格低到不要不要的。因爲好貨超低價（大可能是一元），秒殺會吸引大量的尖峯流量彙集，對架構師來講是一大挑戰。

 

只談技術上的業務描述，秒殺通常分爲秒殺前、秒殺中、秒殺後三個階段，各個階段的需求以下：

　　一、秒殺前，用戶訪問秒殺寶貝描述頁，不斷刷新，等待秒殺開始。

　　二、秒殺中，用戶點擊秒殺按鈕，洪水般的流量瞬間涌入系統，都想走在前面，搶到寶貝。

　　三、秒殺後，秒殺結束，商品已被搶完或者秒殺時間已過，用戶訪問秒殺結束頁面，整個秒殺階段結束。 

　　秒殺前，大量用戶頻發刷新秒殺頁面，都想第一個看到秒殺開始，越臨近開始時間，刷新越頻繁，這時候對系統會有巨大的讀壓力。

　　秒殺中，用戶的秒殺請求短期內持續涌入，前端訪問量暴增，而且會牽扯到寫庫的需求，還有在對於單一熱點商品庫存判斷和遞減，因爲寫庫是排他操做，一個一個排隊處理，數據庫寫壓力很大。

　　秒殺後，和秒殺前差很少，短期內單頁面不少用戶訪問，但時間一過，頁面就沒有訪問量了。

 

　　對於秒殺前後單頁面的大量訪問，處理起來很簡單，提早預熱把秒殺頁面放入cdn，大量的請求就能夠抗住了。

　　這裏有一些須要注意的點，一是cdn放的是靜態頁面，秒殺須要判斷秒殺開始，這個可使用動態加載js的方式（網頁），從cdn去請求一個js（秒殺開始後再生成），該js負責跳轉到秒殺頁面（秒殺開始後再生成，避免做弊），若是是app，能夠用webview或者請求一個cdn上的文件也是能夠的。有人說爲何不直接請求接口來獲取秒殺開始標識，固然是能夠的，可是cdn是部署到全國各地的，若是請求服務器，這部份量會佔用一部分服務器資源，秒殺誒，能節約資源來進行後續請求就節約啊，否則掛了很差看啊。二是怎麼判斷秒殺是否開始，秒殺基本都是約定好在某個時間點開始，因此一種直接的想法就是靠時間咯。這的確是一種作法，但不是很好，首先是由於秒殺爲了分散量，多個商品的秒殺就算是一個時間點，也應該分開進行，這樣緩解系統壓力；其次就是爲了公平性，這個開始時間會在必定範圍內有隨機性，這樣因爲用戶看到頁面的時間隨機，不用只拼網速啦，人品也是有用的；還有就是秒殺開始後還有其餘工做要作，好比刷cdn放js，生成秒殺頁面等，時間在分佈式系統裏是最不靠譜的了（服務器時間是有差異的），會致使數據問題（好比js生成了，秒殺頁面尚未出來，用戶一堆404），用戶會罵孃的。因此通常會抽象一個發令器出來（是的，程序來源於生活。。。），秒殺系統激活發令器，秒殺開始，下游其它業務開始處理，這裏能夠定義這些業務的處理順序，秒殺系統裏能夠配置什麼時候發令，固然也能夠有隨機的規則。消息中間件出現了，這裏發令器發令後，下游的業務就是經過消息中間件獲得的秒殺開始的信號！！不少解決不了的問題每每是由於視角不對，以更高的視角看問題，不少問題每每只缺一個抽象。

 　　秒殺中的最大壓力就是對商品庫存的併發爭搶，就像商場大促銷，就那麼兩件，一堆大媽衝上去搶，各個身懷絕技，商場導購小妹沒點武藝還真是抗不住。這時候能夠參考以前文章中的異步減庫存的形式來作，只是這裏是異步下訂單。說具體方案以前，先看看這個業務場景要作什麼？其實就是在解決一萬我的同時拿着錢來東西，可是東西只有十件，你賣給誰的問題，只要沒給錢，那我東西不給你就沒問題，給了錢就必須拿到東西。因此這裏咱們能夠對來買東西的人強制他們排隊，先到先得，而且排隊的數據少許丟失是能夠接受的，後面拍着那麼多人呢，不怕賣不完。那最後的方案就是，用戶點擊秒殺按鈕後，加入秒殺隊列（限制長度），加入成功則告知正在秒殺，不然直接跳到秒殺結束頁面。對於秒殺隊列中的用戶，則進行寫訂單減庫存處理處理，而且記錄成功與失敗，商品秒殺完成後，標記秒殺結束，而且能夠清空秒殺隊列，避免後面重複判斷和處理。用戶端輪詢（能夠採用長輪詢，時效性好）結果，若是秒殺結束而且本身沒有秒殺成功，則跳轉到秒殺結束頁面，不然繼續等待，若是秒殺成功則跳轉到秒殺成功頁面，支付就是後面的事情了。這裏有幾個點須要關注，一是做弊，就是驗證碼，各類策略各類造型的驗證碼；二是時效性，秒殺完後一段時間（好比半個小時）沒付款，應該將該筆秒殺標記無效，而且把庫存回補。消息中間件再次大顯身手，秒殺隊列，這裏須要消息中間件提供限長隊列功能（不限長，先查詢再入隊也是能夠的，只是要把握好這個時間間隔可能加入的多餘數據對消息中間件的影響），清空隊列功能（沒有也能夠，只是不能更快的釋放壓力）。固然除了這些，還有限流功能，接入層只容許系統可負載流量進入，超過必定負載就採起措施緩解流量進入（好比驗證碼。。。）。能夠看到，對於秒殺中功能，基本就是採起逐級下降流量的方法（大流量系統的重要思路），只讓不過度高於有效流量的流量進入後端真正的業務系統，保證業務系統不宕機。還有一個原則就是讀比寫更容易擴展，無業務系統比業務系統更容易擴展，因此應該化寫爲讀（下訂單變爲查詢訂單），下降業務系統壓力（前端接入層攔截無效流量）。

 

　　秒殺後的方案和秒殺前差很少，再也不贅述。 最後說兩句本質，本質，本質！抓住本質看問題，不要爲了解決問題而解決問題！