“秒殺”求生?網站運維如何挑戰尖峰時刻!

文:吳冠輝 2020-05-11

發布時間: 2020-05-08 15:38:00

網站運維 網購 動靜分離 CDN 熱點隔離


網站運維挑戰:尖峰時刻,秒殺求生


14.jpg

”秒殺”活動一直是網購平台經營業者又愛又怕的行銷活動。它能夠快速聚集大量人氣和流量,帶來巨大營業額及品牌影響力。然而,”秒殺”對網站平台運維技術卻帶來極大的挑戰。網站一旦不能支撐秒殺活動帶來的瞬間洪峰流量,將造成伺服器癱瘓、資料庫崩潰、帳務出貨問題等接踵而來,因而對商譽造成巨大的負面影響。




從技術面來看,秒殺活動運作也成為平台運維技術能力的衡量指標,能應付瞬間洪峰流量問題,代表平台團隊綜合能力已達某種高度,有機會將營運帶上另一個高點。以下介紹幾個處理瞬間洪峰流量問題的秒殺系統平台設計方法。


熱點隔離

秒殺系統設計常用模式之一就是「熱點數據隔離」。大部分秒殺活動在整個網站平台中是很小一部分的行銷活動,但卻對整個網站系統造成當機,且影響網站全範圍。試想,秒殺活動造成人太多、買不到、搶不到,也就認了,但如果該活動導致整個網站商店正常銷售活動也一起躺槍,就得不償失了。因此,秒殺架構設計,首要基礎就是將熱點數據隔離:不要讓1%的請求影響到另外的99%活動!隔離後,也可以更容易對這1%的請求做針對性優化。針對秒殺活動可作多層次的隔離,說明如下:


業務隔離:把秒殺做成一種行銷活動,賣家要參加秒殺活動需要單獨報名。技術上來說,賣家報名後就是已知熱點,當真正開始時,可提前做好準備。

 系統隔離:是指運行時的隔離,可以通過分組部署方式,讓秒殺活動的資源利用與99%的一般活動分開。秒殺活動還可以利用導流的方式,讓流量請求自動轉到指定的虛擬伺服器叢集。

 數據隔離:秒殺所調用的數據大部分都是熱數據,比如啟用單獨cache叢集或單獨MySQL資料庫來放熱點數據,不讓0.01%的數據影響另外99.99%。

 路由隔離:可以按照用戶來區分,給與不同用戶分配不同cookie,從接入時就可以路由到不同服務介面進行存取。還可在接入時,針對URL不同路徑來設置限流策略等。


動靜分離

前面介紹在系統面上做隔離,屬於防守性策略,可進一步採用進攻策略來對付1%熱點請求。其中,最有效的方案為對熱點進行「數據動靜分離」,這是解決大流量系統的一個重要原則。


2.jpg

圖、數據動靜分離策略


如上圖所示,數據動靜分離主要原則在於把90%的靜態數據緩存在用戶端或者CDN上,讓秒殺的用戶只需要點擊特殊的按鈕“刷新搶購”即可,不需要刷新整個頁面,如此只需要向服務端請求很少的有效數據,而不需要重複請求大量靜態數據。由於秒殺動態數據相較於普通詳情頁面的動態數據少很多,如此作法性能會提升3倍以上。這種“刷新搶購”設計方式是面對秒殺活動一種很有效的動態架構。綜合來說,此架構具有以下特點:


 把整個頁面數據Cache放在用戶流覽器

 如果強制刷新整個頁面,也會請求到CDN Cache上

 實際有效請求只是“刷新搶購”按鈕


分時削峰

除了從技術面進行分流外,從業務面亦有分流方案。所謂尖峰,每秒查詢率是以秒為單位,透過流程設計將峰值時間片段拉長,系統就會擴充好幾倍處理能力。熟悉淘寶秒殺活動都知道,第一版的秒殺系統沒有答題功能,導致系統經常會有撐不住狀況;之後網站設計增加秒殺答題後,下單時間被控制在2秒之後,大大分散系統瞬間流量,請參閱下圖摘錄的淘寶網頁面。

3.jpg

圖、淘寶網—分時削峰策略


增加答題還有另一個重要功能,就是把峰值下單請求給拉長,從以前的1秒之內延長到2~10秒左右,請求峰值被時間片段化,因而減少服務端處理併發請求的壓力。另外,答題會造成請求的先後,較後面的請求根本到不了最後下單步驟,所以也會減少併發請求的狀況。


小結

解決網站高流量洪峰的方法並不是單一技術解,而是一套組合拳。技術能力有所侷限,必須透過其他方案輔助,發揮一加一大於二的效益,才是解決高併發問題的最佳解答。流量是把雙面刃,正如「水能載舟,亦能覆舟」一樣。面對流量的治水工程將是運維技術未來至少十年的大課題,上述介紹在幾年後也許又有新的面貌與方案,但不變的是面對技術挑戰時,持續的研究與學習是真正的樂趣之處。




8.jpg


Hi! 我是Roger。

從事技術工作十多年了,

喜歡玩和瞭解學習各種技術的內涵,

喜歡聽、也喜歡分享各種狂想,

歡迎你跟我分享你的看法!





6.jpg


更多案例

x