歡迎光臨
每天分享高質量文章

紅包系統流量高併發技術,你需要知道的是…

 

發紅包是目前各大互聯網公司最常用的營銷手段之一,它形式多樣,內容豐富。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 毫秒以內。

分佈式鎖組件

回呼式的分佈式鎖組件

在拆紅包環節時可能出現同一用戶拆兩次紅包的問題:當用戶點擊過快時,可能同一用戶的兩個執行緒同時通過了是否拆紅包的條件校驗,在這種情況下,該用戶可以拆兩次同一個紅包。

針對這一問題,我們通過對紅包單號,用戶編號兩個維度加分佈式鎖來解決。

目前常用的分佈式鎖大致有三種實現:

  • 資料庫

  • Zookeeper

  • Redis

基於實際執行效率和實現難度的考慮,在紅包系統使用 Redis 實現了分佈式鎖組件。

加鎖:使用高版本 Redis  set 命令的 EX,PX 屬性,實現加鎖,超時時間設置的原子操作。

加鎖

釋放鎖:通過 Lua 腳本來實現鎖值判斷,釋放鎖的原子操作。

釋放鎖

執行入口

搶紅包、拆紅包前的高效前置校驗

拆紅包作為紅包操作中併發最高,處理步驟比較複雜的部分,如何削減拆紅包的流量至關重要。

搶紅包是拆紅包大併發流量的第一道入口,系統設計要盡可能滿足快進快出的要求。

搶紅包流程圖

搶紅包時只通過快取計數器做簡單的紅包狀態檢驗,可以過濾掉大部分拆紅包的流量;計數器設置為僅從主 Redis 讀,避免隨機讀的延遲問題。

紅包系統高可用架構實踐

分佈式任務調度

分佈式任務調度包括紅包超時退款、異常補償等,紅包超過設定時間未被領取完如何退款?紅包發放因為系統、網絡等各方面的原因,導致用戶紅包到賬失敗如何給用戶進行補償?

因為紅包涉及到資金問題,所以在紅包發放、到賬、退款方面需要萬無一失,否則可能會遭到用戶的大量投訴,在這裡我們用蘇寧統一任務調度平臺進行分佈式部署系統的定時任務調度。

定時掃描資料庫中符合條件的訂單,進行超時退款,發放異常重覆訂單發放等操作。

支付鏈路&賬戶分離

通過設計專用的紅包極簡收銀台、紅包賬戶實現紅包發、搶、拆等過程與普通賬戶、支付鏈路分離,避免在大促時對支付、會員、賬務核心等購物核心主鏈路造成壓力。

高可用部署架構

上圖為蘇寧金融會員紅包系統目前的單集群部署示意圖,是典型的蘇寧技術體系下的分佈式,高可用系統部署結構。

它具備水平擴容,容災和監控的能力:

  • 前端流量會通過 HLB 來分發和負載均衡至 WAF 平臺。

  • WAF 經過防火牆處理後分發至 HTTP 服務集群(目前主要為 Nginx)。

  • 然後由 HTTP 服務器進行流量反向代理,分發至後端應用服務器進行處理。

  • 服務與服務之間,通過 RPC 遠程呼叫框架進行服務的發現,註冊與呼叫,訊息佇列使用 Kafka 進行通信。

  • 在儲存層使用 Mycat 來訪問分佈式資料庫進行讀寫操作,分佈式快取使用多分片 Redis 進行儲存。

服務器使用 Zabbix 平臺進行性能監控,統一任務調度平臺進行分佈式任務的分發,使用雲跡平臺進行分佈式日誌的採集與查看。

為同時應對多個渠道,多種型別的紅包類大促營銷活動,紅包系統採用多個集群部署方式部署,在本次雙十一大促中同時為集團各產業紅包—獎勵金紅包、體育紅包、圈子紅包等營銷產品提供高性能高可用的服務支撐。

紅包系統的大促保障

紅包系統作為公司每次大促營銷活動的重要參與系統之一,在 818&雙十一等大促中需要應對瞬間海量流量,那麼我們如何在大促中監控、保障系統呢?

系統監控

目前在大促活動監控方面,主要分為兩大塊:

  • 業務監控

  • 中間件監控

業務監控:蘇寧金融自研監控平臺,可以細化到服務秒級的呼叫數、成功率、呼叫耗時等的監控,可以靈活針對各項維度進行告警設置,在業務異常時進行短信或者郵件告警。

業務監控的意義在於實時監控生產線上的流量情況,在流量接近或者超過業務預期的性能閥值後,應當儘快進行服務降級或者生產擴容等緊急措施。

鏈路式服務監控

中間件監控:中間件的監控平臺較多,Zabbix 平臺監控服務器的性能指標,包括 CPU 使用率,記憶體使用率,磁盤使用率,網絡流量等。

Redis 監控使用 Promes 監控平臺;資料庫監控使用蘇寧自研資料庫管理平臺,可實時查看資料庫狀態,是否存在慢 SQL 等。

異常監管及日誌查看使用蘇寧自研分佈式日誌平臺,可實時查看分佈式系統日誌,系統中的異常情況等。

中間件監控可以發現硬體層面的問題,例如系統壓力過大時造成 CPU 過高等,可以根據具體指標進行擴容或者聯繫系統運維解決硬體問題。

多級流控

在流量洪峰來臨時,如何優先保障系統穩定呢?首先,通過性能壓測等手段確認系統的最大承受能力,為每個服務&接口設定具體的流量閥值。

其後在各級流控平臺進行流控配置:

  • 防火牆:防火牆主要針對 HTTP 服務進行流控,並可提供防黃牛、防網絡攻擊、負載控制等相關功能。

  • 服務全域性流控:防火牆僅能針對 HTTP 服務進行流控,那麼系統提供的 RPC 微服務接口集群流控則依賴內部流控平臺,可提供系統級的全域性服務流控。

  • 服務單機流控:RPC 微服務接口單節點流控配置與 RPC 服務後臺,提供單機令牌式流控服務。

  • 用戶級流控:以上幾種流控方式均為服務級別的流控,尚無法控制單個用戶的防刷操作,在這裡我們開發了基於 Redis 的用戶級流控,可以控制單個用戶一段時間內的訪問次數。

為什麼要配置多種級別的流控服務呢?主要基於以下幾點考慮:

  • 基於高可用的理念,防止單個流控服務出現故障時可以有其他流控進行補充。

  • 不同流控方式所控制的維度不一樣,有針對 HTTP 服務的,有針對 RPC 服務的;級別也不一致,有全域性和單機的,在流量控制方面做到萬無一失。

  • 控制的方式不一樣,有基於 TPS 控制的,也有基於令牌式控制的,還有根據時間範圍內次數進行控制。

系統降級

基於 Zookeeper 的分佈式配置平臺設置應用開關閥值,在系統壓力過大時,通過開啟關閉非核心應用功能,保障核心主鏈路的可用。

例如在發紅包、搶紅包的流量洪峰到來前,通過在配置平臺修改開關值,可以暫時性的關閉紅包消費功能(餘額提現、兌券等),開關關閉後,消費功能暫時不可用,在流量洪峰消退後,打開開關,即可恢復消費功能。

打開和關閉的操作在半分鐘內可以完成,快速保護紅包核心主鏈路和恢復功能完整。

未來的挑戰及方向

紅包系統從 2016 年年底至今,經歷了公司的數個大促,目前在業務方面,也面臨著一系列的挑戰:

  • 隨著紅包形式的多樣化,業務不斷提出新的紅包玩法;如何在現有能力的基礎上,提升系統復用性,核心服務中台化,快速兼容新的紅包玩法。

  • 紅包系統目前高度依賴 Redis,在現有 Redis 資料持久化的基礎上,需要在代碼層面進一步完善快取資料補償能力。

  • 目前的紅包高可用部署基於一個 IDC 機房的集群部署,如果整個 IDC 機房服務都不可用的話,那麼服務就需要切換到備機房,目前還無法做到無縫對接;在這種情況下,異地多活部署勢在必行。

每年都會有新的紅包活動,而隨著蘇寧易購和蘇寧金融用戶群體的不斷擴大,紅包系統面臨的挑戰也越來越多。

以後我們將圍繞高併發,高可用,高一致性的方向,不斷優化系統部署,代碼結構,未來的路還很長,我們將砥礪前行。

作者:薑春峰、邢愷

簡介:薑春峰,蘇寧金融研發中心技術副總監,目前負責蘇寧金融會員及互聯網研發中心的前端、門戶、內容、增長產品研發的技術管理工作。具有 8 年互聯網金融領域相關研發以及技術管理經驗;擅長互聯網金融領域應用架構,涉獵支付、理財、保險、營銷、生活服務產品等產品領域應用研發,有豐富的系統性能優化經驗,具備很強的技術領導力。

邢愷,蘇寧金融研發中心技術經理,主要負責蘇寧金融會員及互聯網研發中心的紅包及營銷產品線研發工作。具有 7 年軟體研發工作經驗;參與過蘇寧集團多次紅包類大促活動的開發;擅長高併發服務端系統開發架構,對構建高性能服務端系統具有比較豐富的實戰經驗。

 

來源:51CTO技術棧

不知大家是否有過這種搶紅包心理,向來手快,奈何網慢啊?原來背後還有這麼多我們不可控因素,給做紅包系統的同學點贊!

    赞(0)

    分享創造快樂