個性化推薦系統（五）---電商雙11大促研發

  今天已到10月下旬一年一度電商雙11大促即將開始，是電子商務公司一年最大促銷活動，是重中之重。對於線上服務來講，是一次流量大考，對研發來講是一次技術提高機會。作好應對高併發、大流量準備，是件必需要作必須作成的事情。

       個性化推薦系統又與其餘系統有着類似大流量考驗，還有一些和其餘業務系統差別地方。核心交易系統更多面臨高併發交易可用性，高併發交易不出錯，系統穩定性。個性化推薦面臨問題是及其複雜線上算法邏輯，屢次緩存redis調用，各個業務線面臨線上將近20倍流量暴漲，由於個性化每一個用戶邏輯均不相同，暴漲的流量對於redis等存儲壓力也是巨大相似DDoS。挑戰是至關之大，最近上下游聯合壓測、全鏈路壓測系統均未達到預估流量，壓力山大。

       流量大、系統多、問題複雜，整個事情怎麼作，仍是要梳理思路，按節奏進行備戰，開展各項工做。首先是梳理線上服務依賴存儲、依賴上游接口、線上服務邏輯是否可優化，而後單機壓測、上下游壓測、全鏈路壓測，線上服務擴容，線上各類redis、數據庫、ES等資源擴容。詳細備戰可見個人618備戰文章618電商大促備戰以及總結。

       此次雙11出現新狀況以及面臨主要問題是第一次壓測多個redis集羣性能嚴重降低並持續整個壓測過程，後來進行查找分析定位是網絡異常致使，由於redis目前也是在虛擬機中，兩個物理機網絡出問題，物理機上的多個redis集羣出現性能持續降低。

        第二次上下游壓測依然是redis性能降低，redis單個集羣性能持續降低，致使整個集羣性能降，線上業務基本都依賴這個集羣，全線業務性能受影響。經查是存在大key或熱key致使單個分片性能差。以及線上業務流量過於集中，所有集中單個redis集羣，每分鐘流量過億。

        解決辦法最好是redis數據複製進行拆分，一部分業務讀原有redis集羣，一部分讀新集羣，這是個方法但資源消耗大。二是在定位查找熱key將熱key進行定時處理或分散處理，大key value值大小進行控制，避免集羣節點壓力過大，致使集羣性能降低。三是線上業務自查看是否有redis通用數據是定時拉取，實時拉取通用數據致使熱點key，通用數據必定採用定時器拉取。空用戶信息訪問直接返回通用數據，避免空信息時出現熱點key。

        redis資源不可擴容狀況下，線上服務能夠進行一下優化，主要是redis集羣鏈接配置調大、單個客戶端鏈接調小，避免消耗盡redis鏈接。集羣超時調小，避免redis性能差致使線上服務不可用。

        該作工做認真作好，儘可能作到線上業務大流量不降級。但外一出現風險的狀況怎麼辦？這時降級預案要作好，作好降級準備，降級預案提早演練作到萬無一失。

        微信搜索：debugme123 

        掃碼關注：