蘇寧11.11:如何hold住大促紅包
紅包,這幾年最火的營銷系統。各大廠,無論雙11、春節都花費了大力氣,五花八門的產品竭力吸引眼球。
那麼如何設計一個能抗住億級併發的紅包系統了。這恐怕對任何一個團隊來說,都是一個很大的挑戰。經過這幾年的大促紅包開發(AR小獅子,紅包雨等),我們蘇寧團隊也在系統架構設計上積累一些經驗。
架構設計
核心業務系統架構設計做到大系統小做,各個服務之間做到高內聚低耦合,服務之間做到非同步化,突發事件的時候能夠做到對非核心業務進行降級,保證核心功能可用,最大程度保證使用者體驗。
總體架構示意圖
系統主要分前臺和後臺兩個模組。
- 後臺:主要負責活動資訊、獎項資訊配置,並實時下發前臺系統。
- 前臺:主要提供了活動資格校驗、獎項配額扣減、概率服務、獎項列表服務等。
後臺配置管理
後臺配置管理維護活動資訊及獎項資訊,通過MQ下發給前臺系統。前臺系統將配置刷入本地快取中。
准入驗證
活動開啟時間的,使用者級別、是否實名認證,每天活動期間抽獎次數驗證。
獎項配額管理(庫存扣減)
在大規模的流量下,我們要做到獎項數量不多發、不少發,還有合理的獎項發放能力和發放速度。保證整個活動按照產權預期效果執行。
強大的獎項處理能力。通過概率服務計算完之後,獎項數量通過redis做扣減,非同步落DB和非同步發放。
非同步發獎
通過MQ的形式,通知下游系統(促銷中心,易付寶),發放券和現金紅包。和下游系統完全解耦,在大流量併發場景下,保護下游系統,不被外部系統拖死。
資料實時計算
為了前端準確展示和資料決策的需要,我們需要知道準備的已發放的紅包數和現金數。基於多個IDC的多叢集部署,我們需要多IDC的資料匯聚進行統計,我們通過資料庫Binlog抽數單向複製匯聚主機房,然後寫入kafka,通過spark的流式計算獲得秒級資料,寫入快取。
流量控制與防刷
如何順利扛過流量洪峰,我們通過客戶端過載保護、流量清洗、流控控制、風控防刷、單機保護來保證系統平穩的執行。而且在過載保護和流控的時候,我們通過客戶端的預埋邏輯來展示未中獎的彩蛋,保證使用者體驗。
客戶過載保護:在客戶端層面進行流量攔截,在系統處於過載狀態的時候,通過客戶端的預埋邏輯,獲取實時配置,根據實時配置來限制流量往後傳送。通過長連線推送和拉的形式來實現配置實時下發。
流量清洗:通過CDN和應用防火牆WAF進行流量清洗,有效的防止CC和DDOS等流量惡意攻擊。
叢集限流策略:通過WAF層來實現流量控制,總量通過令牌桶演算法限制總量,通過其他行為策略(單IP,單UA)來限制異常流量。
單機限流策略:限制單臺機器的總訪問QPS,對超過閥值的流量進行限流。限制單機介面粒度的訪問QPS,對超過閥值的流量進行限流。
風控防刷策略:通過使用者賬號質量,使用者行為,使用者屬性(各種認證),惡意IP等策略來進行風控防刷。
資源管理
單元化部署
路由層(CDN層上實現)根據使用者的會員號,按照規則演算法(取模等),垂直上下切分,形成各個獨立的叢集。將流量分散到各個叢集中,互不影響。而且不同叢集可以部署到不同的機房。
故障切換
通過單元化的部署,在某一個IDC出現網路問題或不可預測的問題,可以短時間修改路由規則將流量切換到其他IDC叢集。
彈性擴容
服務層擴容: 利用蘇寧雲的Docker的快速部署服務,當流量峰值超過預期的時候,通過Docker自動化操作叢集,對服務層進行彈性擴容。
資料庫擴容: 資料庫部署為1主2備。預先設計好多個分表(比如512個表)並分配好主備對應的分表。在需要對資料庫層進行水平擴容時,將備庫切為寫庫,同時一鍵切換MYCAT的配置。
鏈路壓測
任何系統設計再完美,也不能保證在線上能夠完美達到預期,我們需要對系統在線上生產環境進行效能壓測。通過整個鏈路的壓測,我們能夠清晰的瞭解我們各個服務間的能力和瓶頸(主機、資料庫、網路、頻寬等),能夠針對瓶頸有效指定降級方案。
內部預熱和流量模型修正
前期在產品設計階段,我們通過往年資料和計劃引流方案,估算到各個頁面和各個系統的流量模型,通過模型來預估我們的系統容量。
在產品真正對外之前,發起幾輪內部的預熱,進行業務的演練,測試部分功能問題和體驗問題。同時,通過頁面埋點,根據真實的使用者行為習慣,修正我們預估的流量模型,能夠更好的來分配我們資源。
系統監控
當系統正式上線執行時,我們需要實時瞭解系統各個資源執行狀態,流量大小,業務引數。充分的保障業務節點的可用性、效能可靠性。及時發現突發狀況,按照預先準備的降級手段進行降級。
目前蘇寧的監控手段還是比較豐富的,通過雲跡(日誌)、呼叫鏈監控、ZABBIX等平臺,可以全面監控到:伺服器負載監控、資源層負載監控、網路層監控、應用層介面監控、應用日誌監控、應用伺服器jVM層監控。
小結