發紅包是目前各大互聯網公司最經常使用的營銷手段之一,它形式多樣,內容豐富。2016 年末蘇寧金融開啓了紅包系統及相關係統的項目開發。前端
本文將對蘇寧金融紅包系統的架構部署方式、演變過程、技術優化等方面進行詳細闡述。數據庫
紅包系統的技術挑戰後端
紅包,升級版的秒殺系統,紅包系統應當具有秒殺系統所具有的特性。緩存
大量用戶搶紅包帶來了系統的高併發壓力;大量用戶搶同一紅包帶來了數據一致性問題:紅包不能超發,漏發,重複發;而因爲紅包涉及到資金,也會帶來資金安全問題。安全
由上述可見,一套紅包系統,主要的技術挑戰在於:系統的高併發,一致性,高響應,安全性等。性能優化
紅包系統性能優化(高性能&數據一致性)服務器
流量的削峯填谷網絡
削峯填谷:顧名思義,就是在流量洪峯到來以前在系統負載比較低的時候進行數據預熱等操做,用來分散紅包活動開始後的高併發流量。架構
紅包類營銷活動的業務特色:定時的洪峯流量,經過「削峯填谷」有效減小瞬間流量對系統形成的衝擊。併發
開戶:用戶參與蘇寧搶紅包活動,均需提早開通紅包帳戶,在紅包活動開始後,用戶瞬時併發大。
短期內大量用戶參與活動,開通紅包帳號會將訪問請求瞬間提交到後端應用,會給後端的業務系統形成很大的開戶壓力。
爲減輕基礎服務壓力,將流量峯值進行削峯,咱們採起了以下措施:
預熱活躍用戶
流量削峯填谷
異步化
異步紅包充值及訂單持久化:在紅包發放環節,大量用戶紅包須要到帳,若是不對峯值進行處理,壓力將會直接轉嫁給上游系統形成處理壓力,間接致使紅包系統堵塞。
所以將充值轉爲異步處理,先將充值任務進行隊列存儲,而後分攤到多臺機器(利用分佈式優勢)處理,提高系統處理效率,避免單臺節點壓力過大。
多級緩存(熱點數據全局緩存化)
EHCACHE:本地對讀取多,修改少的數據作 EHCACHE 本地緩存處理,減小訪問數據庫、分佈式緩存的次數。
數據庫緩存:提升數據庫熱表的數據緩存大小。
Redis:全局 Redis 數據化處理,利用 Redis 單線程,基於內存讀寫高 QPS 的特性,解決熱點數據高併發,線程安全等一系列問題。
熱點數據(包括紅包訂單,用戶發,搶記錄等)均存儲至 Redis 系統中,並進行多分片部署,經過 Redis 高併發讀寫的特性,提高系統吞吐量。
另外,目前高併發 Java 系統的核心都是分佈式微服務集羣部署,這種部署狀況下 JVM 級別的鎖,線程安全的數據類型等都不適用,那麼如何保證紅包敏感數據在高併發下的線程安全性呢?
答案仍是 Redis,利用 Redis 單線程的處理特性,Redis 在修改數據方面是線程安全的。
如下爲紅包系統中用到 Redis 存儲的部分場景:
Redis Pipeline 管道模式
煙花紅包燃放環節對於系統響應時間要求很高。開發初期按照 2000 人蔘與,5S 響應時間設計,系統已經達到性能需求的要求。
但在活動運營後,易購將活動參與人數提升到了 8888 人,按照原有方案,響應時間變爲 13S,耗時大大加長,沒法知足性能要求。
在對 Redis 進行大批量的操做時,可使用 Pipeline 模式,經過減小網絡傳輸時間,從而極大的提升系統性能。
在煙花紅包發放中須要對 Redis 進行大量查詢操做,在實際測試中發如今對接近 1W 個命令進行循環普通同步模式時須要 10S 左右,而改用 Pipeline 模式後處理時間在 100 毫秒之內。
分佈式鎖組件
回調式的分佈式鎖組件
在拆紅包環節時可能出現同一用戶拆兩次紅包的問題:當用戶點擊過快時,可能同一用戶的兩個線程同時經過了是否拆紅包的條件校驗,在這種狀況下,該用戶能夠拆兩次同一個紅包。
針對這一問題,咱們經過對紅包單號,用戶編號兩個維度加分佈式鎖來解決。
目前經常使用的分佈式鎖大體有三種實現:
基於實際執行效率和實現難度的考慮,在紅包系統使用 Redis 實現了分佈式鎖組件。
加鎖:使用高版本 Redis set 命令的 EX,PX 屬性,實現加鎖,超時時間設置的原子操做。
加鎖
釋放鎖:經過 Lua 腳原本實現鎖值判斷,釋放鎖的原子操做。
釋放鎖
執行入口
搶紅包、拆紅包前的高效前置校驗
拆紅包做爲紅包操做中併發最高,處理步驟比較複雜的部分,如何削減拆紅包的流量相當重要。
搶紅包是拆紅包大併發流量的第一道入口,系統設計要儘量知足快進快出的要求。
搶紅包流程圖
搶紅包時只經過緩存計數器作簡單的紅包狀態檢驗,能夠過濾掉大部分拆紅包的流量;計數器設置爲僅從主 Redis 讀,避免隨機讀的延遲問題。
紅包系統高可用架構實踐
分佈式任務調度
分佈式任務調度包括紅包超時退款、異常補償等,紅包超過設定時間未被領取完如何退款?紅包發放由於系統、網絡等各方面的緣由,致使用戶紅包到帳失敗如何給用戶進行補償?
由於紅包涉及到資金問題,因此在紅包發放、到帳、退款方面須要萬無一失,不然可能會遭到用戶的大量投訴,在這裏咱們用蘇寧統一任務調度平臺進行分佈式部署系統的定時任務調度。
定時掃描數據庫中符合條件的訂單,進行超時退款,發放異常重複訂單發放等操做。
支付鏈路&帳戶分離
經過設計專用的紅包極簡收銀臺、紅包帳戶實現紅包發、搶、拆等過程與普通帳戶、支付鏈路分離,避免在大促時對支付、會員、帳務核心等購物核心主鏈路形成壓力。
高可用部署架構
上圖爲蘇寧金融會員紅包系統目前的單集羣部署示意圖,是典型的蘇寧技術體系下的分佈式,高可用系統部署結構。
它具有水平擴容,容災和監控的能力:
服務器使用 Zabbix 平臺進行性能監控,統一任務調度平臺進行分佈式任務的分發,使用雲跡平臺進行分佈式日誌的採集與查看。
爲同時應對多個渠道,多種類型的紅包類大促營銷活動,紅包系統採用多個集羣部署方式部署,在本次雙十一大促中同時爲集團各產業紅包—獎勵金紅包、體育紅包、圈子紅包等營銷產品提供高性能高可用的服務支撐。
紅包系統的大促保障
紅包系統做爲公司每次大促營銷活動的重要參與系統之一,在 818&雙十一等大促中須要應對瞬間海量流量,那麼咱們如何在大促中監控、保障系統呢?
系統監控
目前在大促活動監控方面,主要分爲兩大塊:
業務監控:蘇寧金融自研監控平臺,能夠細化到服務秒級的調用數、成功率、調用耗時等的監控,能夠靈活針對各項維度進行告警設置,在業務異常時進行短信或者郵件告警。
業務監控的意義在於實時監控生產線上的流量狀況,在流量接近或者超過業務預期的性能閥值後,應當儘快進行服務降級或者生產擴容等緊急措施。
鏈路式服務監控
中間件監控:中間件的監控平臺較多,Zabbix 平臺監控服務器的性能指標,包括 CPU 使用率,內存使用率,磁盤使用率,網絡流量等。
Redis 監控使用 Promes 監控平臺;數據庫監控使用蘇寧自研數據庫管理平臺,可實時查看數據庫狀態,是否存在慢 SQL 等。
異常監管及日誌查看使用蘇寧自研分佈式日誌平臺,可實時查看分佈式系統日誌,系統中的異常狀況等。
中間件監控能夠發現硬件層面的問題,例如系統壓力過大時形成 CPU 太高等,能夠根據具體指標進行擴容或者聯繫系統運維解決硬件問題。
多級流控
在流量洪峯來臨時,如何優先保障系統穩定呢?首先,經過性能壓測等手段確認系統的最大承受能力,爲每一個服務&接口設定具體的流量閥值。
其後在各級流控平臺進行流控配置:
爲何要配置多種級別的流控服務呢?主要基於如下幾點考慮:
系統降級
基於 Zookeeper 的分佈式配置平臺設置應用開關閥值,在系統壓力過大時,經過開啓關閉非核心應用功能,保障核心主鏈路的可用。
例如在發紅包、搶紅包的流量洪峯到來前,經過在配置平臺修改開關值,能夠暫時性的關閉紅包消費功能(餘額提現、兌券等),開關關閉後,消費功能暫時不可用,在流量洪峯消退後,打開開關,便可恢復消費功能。
打開和關閉的操做在半分鐘內能夠完成,快速保護紅包核心主鏈路和恢復功能完整。
感興趣的能夠本身來個人Java架構羣,能夠獲取免費的學習資料,羣號:855801563 對Java技術,架構技術感興趣的同窗,歡迎加羣,一塊兒學習,相互討論。