“雙十一”高并發應對解決之道
作者簡介:叢磊,白山云科技合伙人兼工程副總裁,2016年加入白山,負責云鏈體系的設計與構建等工作;2006年至2015年,就職于新浪,帶領團隊從事云相關領域技術研發工作。國內***公有云PaaS平臺——SAE創始人;工信部可信云服務認證評委。
1 “雙十一”壓力
不知從何時起,“雙十一”成為了“購物節”,這種全民狂歡式購物對金融行業是一個巨大挑戰,短時間的高并發會給數據接口帶來巨大壓力。據悉,2015年天貓峰值交易量達到14萬次/秒,而2009年僅為400次/秒。
用戶每一筆交易背后都包含了多項操作:首先,用戶瀏覽多個商品才觸發一次購物行為;再次,實際交易前,需要確保庫存、配送、商家優惠政策等信息;生成訂單后,執行支付接口,要求高度一致性和可靠性;支付完成后需要回調多個邏輯,包括積分計算、折扣返點、物流配送等。
可見14萬/秒的交易峰值,不僅對于金融機構,即便是具備豐富應對高并發經驗的互聯網公司,都不是一件容易的事。更為緊迫的是,隨著IOT設備進一步普及,“雙十一”帶來的壓力將越來越大,據某電商平臺預測,2016年“雙十一”峰值壓力將再翻5倍。在可預見的未來,交易完全有可能達到100萬次/秒!
2 應對之道
本人曾參與研發交易量10萬/秒級別的系統,這里對如何應對超高并發提出一些建議。其實,無論是“秒殺”還是“雙十一”,都沒有靈丹妙藥,一個真正能抗超高并發的金融系統,必然由系統中每個組件優化而成。讓每個組件發揮***威力,并對系統充分解耦,才能做出可靠的平臺。
應對超高并發,最重要兩個技術:“緩存-Cache”和”異步化-隊列”。
3 緩存- Cache
這里的Cache不是傳統意義上的Redis/Memcache等系統Cache組件,而是從用戶端到***數據層所有環節的Cache。
對于高并發場景,***條準則就是為用戶行為所有環節加上合理的Cache。
業務層次圖如下:
如圖所示,用戶訪問/交易行為的起點是瀏覽器。首先對瀏覽器端進行合理的Cache設置,即對其中頁面設置合理的過期規則,配合CDN端,讓部分元素響應直接在瀏覽器Cache端返回,有效降低業務訪問壓力;其次,虛線內展示的是業務端,主要由兩部分構成,一個是計算資源,運行業務代碼;另一個是數據庫,負責存儲業務數據。
業務層輸出的內容分為兩部分:動態+靜態。對于動態居多的電商金融業務,以靜態內容為主的CDN加速沒有特別效果,而應該對數據接口進行接口加速(ADN,API Delivery Network)。接口加速需要注意的是,不能因給接口加Cache而影響業務本身。我們建議對所有讀類型數據接口加Cache,并將Cache時間設定為毫秒級,針對不同接口指定不同Cache策略,有效提高Cache***率。
根據實測,通過加ADN Cache,可提高60%訪問速度,同時降低2-3倍后端實際負載。
4 異步化-隊列
異步化-隊列是通過隊列將請求/事務放入后臺運行,從同步阻塞模式變為異步非阻塞模式。例如,搶購發生時,用戶同時調用支付接口,同步阻塞模式下,用戶數量即支付接口的并發度,用戶過多時,支付數據庫壓力過大,嚴重時可能會導致數據庫服務宕機。采用異步模式后,搶購時,用戶請求進入隊列處理,隊列并發度與數據庫并發能力相匹配,用戶請求按序進行,可有效保護數據后端。
隊列不只可以保護后端數據庫。在秒殺場景,很多用戶搶購一個商品,可以先將搶購請求放入隊列,再進入后臺篩選處理(比如排重、按優先級排序等),***調用實際下單接口。隊列可以根據產品需求選用兩種不同模式:一種是全異步模式,即進入隊列后立即返回成功,通過回調通知調用者結果;另一種是半異步,即進入隊列后,調用者掛起,實際執行結束后,再返回成功或者失敗結果。
5 總結
應對“雙十一”高并發,主要采用緩存+隊列異步化,緩存的重點是每個環節,尤其是對于傳統易忽略的數據接口,都要進行合理的Cache。
對于高并發請求,要進行異步化非阻塞處理,防止“洪水”現象,保證業務穩定有序進行。
————————————————————我是可愛分割線———————————————————————