【51CTO.com原創稿件】發紅包是目前各大互聯網公司最常用的營銷手段之一，它形式多樣，內容豐富。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原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】