知識星球
發紅包是目前各大網際網路公司最常用的營銷手段之一，它形式多樣，內容豐富。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技術棧
不知大家是否有過這種搶紅包心理，向來手快，奈何網慢啊？原來背後還有這麼多我們不可控因素，給做紅包系統的同學點贊！
