【51CTO.com原創(chuàng)稿件】發(fā)紅包是目前各大互聯(lián)網(wǎng)公司最常用的營銷手段之一，它形式多樣，內(nèi)容豐富。2016 年底蘇寧金融開啟了紅包系統(tǒng)及相關(guān)系統(tǒng)的項(xiàng)目開發(fā)。

本文將對蘇寧金融紅包系統(tǒng)的架構(gòu)部署方式、演變過程、技術(shù)優(yōu)化等方面進(jìn)行詳細(xì)闡述。

紅包系統(tǒng)的技術(shù)挑戰(zhàn)

紅包，升級版的秒殺系統(tǒng)，紅包系統(tǒng)應(yīng)當(dāng)具備秒殺系統(tǒng)所具備的特性。

大量用戶搶紅包帶來了系統(tǒng)的高并發(fā)壓力;大量用戶搶同一紅包帶來了數(shù)據(jù)一致性問題：紅包不能超發(fā)，漏發(fā)，重復(fù)發(fā);而由于紅包涉及到資金，也會帶來資金安全問題。

由上述可見，一套紅包系統(tǒng)，主要的技術(shù)挑戰(zhàn)在于：系統(tǒng)的高并發(fā)，一致性，高響應(yīng)，安全性等。

紅包系統(tǒng)性能優(yōu)化(高性能&數(shù)據(jù)一致性)

流量的削峰填谷

削峰填谷：顧名思義，就是在流量洪峰到來之前在系統(tǒng)負(fù)載比較低的時候進(jìn)行數(shù)據(jù)預(yù)熱等操作，用來分散紅包活動開始后的高并發(fā)流量。

紅包類營銷活動的業(yè)務(wù)特點(diǎn)：定時的洪峰流量，通過“削峰填谷”有效減少瞬間流量對系統(tǒng)造成的沖擊。

開戶：用戶參與蘇寧搶紅包活動，均需提前開通紅包賬戶，在紅包活動開始后，用戶瞬時并發(fā)大。

短時間內(nèi)大量用戶參與活動，開通紅包賬號會將訪問請求瞬間提交到后端應(yīng)用，會給后端的業(yè)務(wù)系統(tǒng)造成很大的開戶壓力。

為減輕基礎(chǔ)服務(wù)壓力，將流量峰值進(jìn)行削峰，我們采取了如下措施：

• 提前蓄水開戶，在活動爆發(fā)前，采集近期內(nèi)的活躍會員進(jìn)行批量提前開戶，降低活動開始時的開戶壓力。
• 進(jìn)入紅包活動聚合頁提前開戶，在用戶進(jìn)入紅包活動聚合頁時提前開戶，降低發(fā)紅包以及搶紅包中的開戶壓力。

預(yù)熱活躍用戶

流量削峰填谷

異步化

異步紅包充值及訂單持久化：在紅包發(fā)放環(huán)節(jié)，大量用戶紅包需要到賬，如果不對峰值進(jìn)行處理，壓力將會直接轉(zhuǎn)嫁給上游系統(tǒng)造成處理壓力，間接導(dǎo)致紅包系統(tǒng)堵塞。

因此將充值轉(zhuǎn)為異步處理，先將充值任務(wù)進(jìn)行隊(duì)列存儲，然后分?jǐn)偟蕉嗯_機(jī)器(利用分布式優(yōu)點(diǎn))處理，提升系統(tǒng)處理效率，避免單臺節(jié)點(diǎn)壓力過大。

多級緩存(熱點(diǎn)數(shù)據(jù)全局緩存化)

EHCACHE：本地對讀取多，修改少的數(shù)據(jù)做 EHCACHE 本地緩存處理，減少訪問數(shù)據(jù)庫、分布式緩存的次數(shù)。

數(shù)據(jù)庫緩存：提高數(shù)據(jù)庫熱表的數(shù)據(jù)緩存大小。

Redis：全局 Redis 數(shù)據(jù)化處理，利用 Redis 單線程，基于內(nèi)存讀寫高 QPS 的特性，解決熱點(diǎn)數(shù)據(jù)高并發(fā)，線程安全等一系列問題。

熱點(diǎn)數(shù)據(jù)(包括紅包訂單，用戶發(fā)，搶記錄等)均存儲至 Redis 系統(tǒng)中，并進(jìn)行多分片部署，通過 Redis 高并發(fā)讀寫的特性，提升系統(tǒng)吞吐量。

另外，目前高并發(fā) Java 系統(tǒng)的核心都是分布式微服務(wù)集群部署，這種部署情況下 JVM 級別的鎖，線程安全的數(shù)據(jù)類型等都不適用，那么如何保證紅包敏感數(shù)據(jù)在高并發(fā)下的線程安全性呢?

答案還是 Redis，利用 Redis 單線程的處理特性，Redis 在修改數(shù)據(jù)方面是線程安全的。

以下為紅包系統(tǒng)中用到 Redis 存儲的部分場景：

Redis Pipeline 管道模式

煙花紅包燃放環(huán)節(jié)對于系統(tǒng)響應(yīng)時間要求很高。開發(fā)初期按照 2000 人參與，5S 響應(yīng)時間設(shè)計(jì)，系統(tǒng)已經(jīng)達(dá)到性能需求的要求。

但在活動運(yùn)營后，易購將活動參與人數(shù)提高到了 8888 人，按照原有方案，響應(yīng)時間變?yōu)?13S，耗時大大加長，無法滿足性能要求。

在對 Redis 進(jìn)行大批量的操作時，可以使用 Pipeline 模式，通過減少網(wǎng)絡(luò)傳輸時間，從而極大的提高系統(tǒng)性能。

在煙花紅包發(fā)放中需要對 Redis 進(jìn)行大量查詢操作，在實(shí)際測試中發(fā)現(xiàn)在對接近 1W 個命令進(jìn)行循環(huán)普通同步模式時需要 10S 左右，而改用 Pipeline 模式后處理時間在 100 毫秒以內(nèi)。

分布式鎖組件

回調(diào)式的分布式鎖組件

在拆紅包環(huán)節(jié)時可能出現(xiàn)同一用戶拆兩次紅包的問題：當(dāng)用戶點(diǎn)擊過快時，可能同一用戶的兩個線程同時通過了是否拆紅包的條件校驗(yàn)，在這種情況下，該用戶可以拆兩次同一個紅包。

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

目前常用的分布式鎖大致有三種實(shí)現(xiàn)：

• 數(shù)據(jù)庫
• Zookeeper
• Redis

基于實(shí)際執(zhí)行效率和實(shí)現(xiàn)難度的考慮，在紅包系統(tǒng)使用 Redis 實(shí)現(xiàn)了分布式鎖組件。

加鎖：使用高版本 Redis set 命令的 EX，PX 屬性，實(shí)現(xiàn)加鎖，超時時間設(shè)置的原子操作。

加鎖

釋放鎖：通過 Lua 腳本來實(shí)現(xiàn)鎖值判斷，釋放鎖的原子操作。

釋放鎖

執(zhí)行入口

搶紅包、拆紅包前的高效前置校驗(yàn)

拆紅包作為紅包操作中并發(fā)較高，處理步驟比較復(fù)雜的部分，如何削減拆紅包的流量至關(guān)重要。

搶紅包是拆紅包大并發(fā)流量的入口，系統(tǒng)設(shè)計(jì)要盡可能滿足快進(jìn)快出的要求。

搶紅包流程圖

搶紅包時只通過緩存計(jì)數(shù)器做簡單的紅包狀態(tài)檢驗(yàn)，可以過濾掉大部分拆紅包的流量;計(jì)數(shù)器設(shè)置為僅從主 Redis 讀，避免隨機(jī)讀的延遲問題。

紅包系統(tǒng)高可用架構(gòu)實(shí)踐

分布式任務(wù)調(diào)度

分布式任務(wù)調(diào)度包括紅包超時退款、異常補(bǔ)償?shù)?，紅包超過設(shè)定時間未被領(lǐng)取完如何退款?紅包發(fā)放因?yàn)橄到y(tǒng)、網(wǎng)絡(luò)等各方面的原因，導(dǎo)致用戶紅包到賬失敗如何給用戶進(jìn)行補(bǔ)償?

因?yàn)榧t包涉及到資金問題，所以在紅包發(fā)放、到賬、退款方面需要萬無一失，否則可能會遭到用戶的大量投訴，在這里我們用蘇寧統(tǒng)一任務(wù)調(diào)度平臺進(jìn)行分布式部署系統(tǒng)的定時任務(wù)調(diào)度。

定時掃描數(shù)據(jù)庫中符合條件的訂單，進(jìn)行超時退款，發(fā)放異常重復(fù)訂單發(fā)放等操作。

支付鏈路&賬戶分離

通過設(shè)計(jì)專用的紅包極簡收銀臺、紅包賬戶實(shí)現(xiàn)紅包發(fā)、搶、拆等過程與普通賬戶、支付鏈路分離，避免在大促時對支付、會員、賬務(wù)核心等購物核心主鏈路造成壓力。

高可用部署架構(gòu)

上圖為蘇寧金融會員紅包系統(tǒng)目前的單集群部署示意圖，是典型的蘇寧技術(shù)體系下的分布式，高可用系統(tǒng)部署結(jié)構(gòu)。

它具備水平擴(kuò)容，容災(zāi)和監(jiān)控的能力：

• 前端流量會通過 HLB 來分發(fā)和負(fù)載均衡至 WAF 平臺。
• WAF 經(jīng)過防火墻處理后分發(fā)至 HTTP 服務(wù)集群(目前主要為 Nginx)。
• 然后由 HTTP 服務(wù)器進(jìn)行流量反向代理，分發(fā)至后端應(yīng)用服務(wù)器進(jìn)行處理。
• 服務(wù)與服務(wù)之間，通過 RPC 遠(yuǎn)程調(diào)用框架進(jìn)行服務(wù)的發(fā)現(xiàn)，注冊與調(diào)用，消息隊(duì)列使用 Kafka 進(jìn)行通信。
• 在存儲層使用 Mycat 來訪問分布式數(shù)據(jù)庫進(jìn)行讀寫操作，分布式緩存使用多分片 Redis 進(jìn)行存儲。

服務(wù)器使用 Zabbix 平臺進(jìn)行性能監(jiān)控，統(tǒng)一任務(wù)調(diào)度平臺進(jìn)行分布式任務(wù)的分發(fā)，使用云跡平臺進(jìn)行分布式日志的采集與查看。

為同時應(yīng)對多個渠道，多種類型的紅包類大促營銷活動，紅包系統(tǒng)采用多個集群部署方式部署，在本次雙十一大促中同時為集團(tuán)各產(chǎn)業(yè)紅包—獎勵金紅包、體育紅包、圈子紅包等營銷產(chǎn)品提供高性能高可用的服務(wù)支撐。

紅包系統(tǒng)的大促保障

紅包系統(tǒng)作為公司每次大促營銷活動的重要參與系統(tǒng)之一，在 818&雙十一等大促中需要應(yīng)對瞬間海量流量，那么我們?nèi)绾卧诖蟠僦斜O(jiān)控、保障系統(tǒng)呢?

系統(tǒng)監(jiān)控

目前在大促活動監(jiān)控方面，主要分為兩大塊：

• 業(yè)務(wù)監(jiān)控
• 中間件監(jiān)控

業(yè)務(wù)監(jiān)控：蘇寧金融自研監(jiān)控平臺，可以細(xì)化到服務(wù)秒級的調(diào)用數(shù)、成功率、調(diào)用耗時等的監(jiān)控，可以靈活針對各項(xiàng)維度進(jìn)行告警設(shè)置，在業(yè)務(wù)異常時進(jìn)行短信或者郵件告警。

業(yè)務(wù)監(jiān)控的意義在于實(shí)時監(jiān)控生產(chǎn)線上的流量情況，在流量接近或者超過業(yè)務(wù)預(yù)期的性能閥值后，應(yīng)當(dāng)盡快進(jìn)行服務(wù)降級或者生產(chǎn)擴(kuò)容等緊急措施。

鏈路式服務(wù)監(jiān)控

中間件監(jiān)控：中間件的監(jiān)控平臺較多，Zabbix 平臺監(jiān)控服務(wù)器的性能指標(biāo)，包括 CPU 使用率，內(nèi)存使用率，磁盤使用率，網(wǎng)絡(luò)流量等。

Redis 監(jiān)控使用 Promes 監(jiān)控平臺;數(shù)據(jù)庫監(jiān)控使用蘇寧自研數(shù)據(jù)庫管理平臺，可實(shí)時查看數(shù)據(jù)庫狀態(tài)，是否存在慢 SQL 等。

異常監(jiān)管及日志查看使用蘇寧自研分布式日志平臺，可實(shí)時查看分布式系統(tǒng)日志，系統(tǒng)中的異常情況等。

中間件監(jiān)控可以發(fā)現(xiàn)硬件層面的問題，例如系統(tǒng)壓力過大時造成 CPU 過高等，可以根據(jù)具體指標(biāo)進(jìn)行擴(kuò)容或者聯(lián)系系統(tǒng)運(yùn)維解決硬件問題。

多級流控

在流量洪峰來臨時，如何優(yōu)先保障系統(tǒng)穩(wěn)定呢?首先，通過性能壓測等手段確認(rèn)系統(tǒng)的最大承受能力，為每個服務(wù)&接口設(shè)定具體的流量閥值。

其后在各級流控平臺進(jìn)行流控配置：

• 防火墻：防火墻主要針對 HTTP 服務(wù)進(jìn)行流控，并可提供防黃牛、防網(wǎng)絡(luò)攻擊、負(fù)載控制等相關(guān)功能。
• 服務(wù)全局流控：防火墻僅能針對 HTTP 服務(wù)進(jìn)行流控，那么系統(tǒng)提供的 RPC 微服務(wù)接口集群流控則依賴內(nèi)部流控平臺，可提供系統(tǒng)級的全局服務(wù)流控。
• 服務(wù)單機(jī)流控：RPC 微服務(wù)接口單節(jié)點(diǎn)流控配置與 RPC 服務(wù)后臺，提供單機(jī)令牌式流控服務(wù)。
• 用戶級流控：以上幾種流控方式均為服務(wù)級別的流控，尚無法控制單個用戶的防刷操作，在這里我們開發(fā)了基于 Redis 的用戶級流控，可以控制單個用戶一段時間內(nèi)的訪問次數(shù)。

為什么要配置多種級別的流控服務(wù)呢?主要基于以下幾點(diǎn)考慮：

• 基于高可用的理念，防止單個流控服務(wù)出現(xiàn)故障時可以有其他流控進(jìn)行補(bǔ)充。
• 不同流控方式所控制的維度不一樣，有針對 HTTP 服務(wù)的，有針對 RPC 服務(wù)的;級別也不一致，有全局和單機(jī)的，在流量控制方面做到萬無一失。
• 控制的方式不一樣，有基于 TPS 控制的，也有基于令牌式控制的，還有根據(jù)時間范圍內(nèi)次數(shù)進(jìn)行控制。

系統(tǒng)降級

基于 Zookeeper 的分布式配置平臺設(shè)置應(yīng)用開關(guān)閥值，在系統(tǒng)壓力過大時，通過開啟關(guān)閉非核心應(yīng)用功能，保障核心主鏈路的可用。

例如在發(fā)紅包、搶紅包的流量洪峰到來前，通過在配置平臺修改開關(guān)值，可以暫時性的關(guān)閉紅包消費(fèi)功能(余額提現(xiàn)、兌券等)，開關(guān)關(guān)閉后，消費(fèi)功能暫時不可用，在流量洪峰消退后，打開開關(guān)，即可恢復(fù)消費(fèi)功能。

打開和關(guān)閉的操作在半分鐘內(nèi)可以完成，快速保護(hù)紅包核心主鏈路和恢復(fù)功能完整。

未來的挑戰(zhàn)及方向

紅包系統(tǒng)從 2016 年年底至今，經(jīng)歷了公司的數(shù)個大促，目前在業(yè)務(wù)方面，也面臨著一系列的挑戰(zhàn)：

• 隨著紅包形式的多樣化，業(yè)務(wù)不斷提出新的紅包玩法;如何在現(xiàn)有能力的基礎(chǔ)上，提升系統(tǒng)復(fù)用性，核心服務(wù)中臺化，快速兼容新的紅包玩法。
• 紅包系統(tǒng)目前高度依賴 Redis，在現(xiàn)有 Redis 數(shù)據(jù)持久化的基礎(chǔ)上，需要在代碼層面進(jìn)一步完善緩存數(shù)據(jù)補(bǔ)償能力。
• 目前的紅包高可用部署基于一個 IDC 機(jī)房的集群部署，如果整個 IDC 機(jī)房服務(wù)都不可用的話，那么服務(wù)就需要切換到備機(jī)房，目前還無法做到無縫對接;在這種情況下，異地多活部署勢在必行。

每年都會有新的紅包活動，而隨著蘇寧易購和蘇寧金融用戶群體的不斷擴(kuò)大，紅包系統(tǒng)面臨的挑戰(zhàn)也越來越多。

以后我們將圍繞高并發(fā)，高可用，高一致性的方向，不斷優(yōu)化系統(tǒng)部署，代碼結(jié)構(gòu)，未來的路還很長，我們將砥礪前行。

作者：姜春峰、邢愷

簡介：姜春峰，蘇寧金融研發(fā)中心技術(shù)副總監(jiān)，目前負(fù)責(zé)蘇寧金融會員及互聯(lián)網(wǎng)研發(fā)中心的前端、門戶、內(nèi)容、增長產(chǎn)品研發(fā)的技術(shù)管理工作。具有 8 年互聯(lián)網(wǎng)金融領(lǐng)域相關(guān)研發(fā)以及技術(shù)管理經(jīng)驗(yàn);擅長互聯(lián)網(wǎng)金融領(lǐng)域應(yīng)用架構(gòu)，涉獵支付、理財(cái)、保險、營銷、生活服務(wù)產(chǎn)品等產(chǎn)品領(lǐng)域應(yīng)用研發(fā)，有豐富的系統(tǒng)性能優(yōu)化經(jīng)驗(yàn)，具備很強(qiáng)的技術(shù)領(lǐng)導(dǎo)力。

邢愷，蘇寧金融研發(fā)中心技術(shù)經(jīng)理，主要負(fù)責(zé)蘇寧金融會員及互聯(lián)網(wǎng)研發(fā)中心的紅包及營銷產(chǎn)品線研發(fā)工作。具有 7 年軟件研發(fā)工作經(jīng)驗(yàn);參與過蘇寧集團(tuán)多次紅包類大促活動的開發(fā);擅長高并發(fā)服務(wù)端系統(tǒng)開發(fā)架構(gòu)，對構(gòu)建高性能服務(wù)端系統(tǒng)具有比較豐富的實(shí)戰(zhàn)經(jīng)驗(yàn)。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】