本文來自騰訊QQ技術(shù)團隊工程師許靈鋒、周海發(fā)的技術(shù)分享。

一、引言

自 2015 年春節(jié)以來，QQ 春節(jié)紅包經(jīng)歷了企業(yè)紅包（2015 年）、刷一刷紅包（2016 年）和 AR 紅包（2017 年）幾個階段，通過不斷創(chuàng)新玩法，活躍度節(jié)節(jié)攀升，成為春節(jié)一大玩點，給火紅的春節(jié)帶來一抹亮色。2017 年除夕，AR 紅包、刷一刷紅包再創(chuàng)新高，搶紅包用戶數(shù)達 3.42 億，共刷出紅包 37.77 億個。

那么，QQ 紅包的技術(shù)方案究竟是怎樣的？其整體架構(gòu)如何？重要的系統(tǒng)是如何設(shè)計的？為了保證用戶的體驗，手機 QQ 移動端做了哪些優(yōu)化？今年的 QQ 紅包又做了哪些新的嘗試，遇到的問題是如何解決的呢？本文將從架構(gòu)開始，到手機 QQ 移動端優(yōu)化，再到個性化紅包和 AR 新玩法，為大家全面解密 QQ 紅包技術(shù)方案。

學(xué)習(xí)交流：

- 即時通訊/推送技術(shù)開發(fā)交流4群：101279154 [推薦]

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

（本文同步發(fā)布于：http://www.52im.net/thread-2202-1-1.html）

二、關(guān)于作者

▲ 兩位作者，許靈鋒（圖左者）和周海發(fā)（圖右者）

turboxu（許靈鋒）：2006 年加入騰訊，會員體系后臺負責(zé)人，從事過 MIS 系統(tǒng)、網(wǎng)絡(luò)安全、滔滔（空間說說）、WAP 音樂、超 Q、會員等項目，對開源組件、虛擬化感興趣，致力于推動 Docker 虛擬化和開源組件的應(yīng)用和實踐。

haifazhou（周海發(fā)）：2011 年加入騰訊，從事 IM 基礎(chǔ)系統(tǒng)開發(fā)和運營，先后參與過 PTLogin 統(tǒng)一登錄和消息漫游存儲改造項目，連續(xù)三年參與并負責(zé) QQ 春節(jié)紅包后臺系統(tǒng)架構(gòu)設(shè)計，在海量分布式高性能系統(tǒng)設(shè)計方面積累了多年經(jīng)驗。

三、相關(guān)文章

《技術(shù)往事：“QQ群”和“微信紅包”是怎么來的？》

《QQ 18年：解密8億月活的QQ后臺服務(wù)接口隔離技術(shù)》

《月活8.89億的超級IM微信是如何進行Android端兼容測試的》

《開源libco庫：單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]》

《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(演講全文)》

《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(PPT講稿) [附件下載]》

《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡》》

《微信海量用戶背后的后臺系統(tǒng)存儲架構(gòu)(視頻+PPT) [附件下載]》

《微信異步化改造實踐：8億月活、單機千萬連接背后的后臺解決方案》

《微信朋友圈海量技術(shù)之道PPT [附件下載]》

《架構(gòu)之道：3個程序員成就微信朋友圈日均10億發(fā)布量[有視頻]》

《快速裂變：見證微信強大后臺架構(gòu)從0到1的演進歷程（一）》

《快速裂變：見證微信強大后臺架構(gòu)從0到1的演進歷程（二）》

四、QQ 紅包整體架構(gòu)及重要系統(tǒng)

QQ 春節(jié)紅包以一個又一個的整點刷紅包活動貫穿年三十，在除夕夜達到頂峰，是典型的海量用戶秒殺場景，如何應(yīng)對海量的用戶刷紅包洪流，保證刷得爽，紅包安全到賬，是 QQ 紅包設(shè)計要解決的關(guān)鍵技術(shù)難點。另外，紅包項目涉及手機 QQ 移動端、手機 QQQ 后臺、QQ 錢包（財付通）系統(tǒng)、禮券系統(tǒng)、公眾號等諸多業(yè)務(wù)系統(tǒng)，流程長且多，各系統(tǒng)性能吞吐量差異很大，如何保證各系統(tǒng)形成一個有機整體，協(xié)調(diào)高效提供服務(wù)，也是難點之一。

下圖為簡化后 QQ 紅包的架構(gòu)，包括：接入層、抽獎系統(tǒng)、存儲系統(tǒng)、發(fā)貨系統(tǒng)、公眾號消息通知和 CDN 資源等幾部分，請大家先有一個整體的認知，便于閱讀下文。

▲ 簡化后的QQ紅包系統(tǒng)架構(gòu)

本節(jié)將重點講解接入層、抽獎系統(tǒng)和發(fā)貨系統(tǒng)。

4.1、接入層

接入層是紅包后臺服務(wù)的大門，負責(zé)抽獎?wù)埱箢A(yù)處理，確保有效的請求才透傳給后端服務(wù)。為保證自身高可用、高穩(wěn)定，接入層還可實時控制手機 QQ 請求頻率，避免海量請求壓垮接入層，出現(xiàn)不可控局面。

在海量服務(wù)場景下，為避免網(wǎng)絡(luò)開銷，方便后端服務(wù)使用 cache 提升性能，接入層采用了一致性 Hash 尋址，保證同一個用戶的請求只會落在同一臺紅包抽獎邏輯機器處理。

4.2、抽獎系統(tǒng)

4.2.1 基本介紹

抽獎系統(tǒng)作為 QQ 紅包的核心系統(tǒng)，在承接用戶抽獎?wù)埱螅丛O(shè)計合理的幾率完成抽獎操作，將抽獎結(jié)果安全落地保存，并順利發(fā)貨等過程中，起到了關(guān)鍵作用。面對海量抽獎?wù)埱螅绾渭皶r作出響應(yīng)，是抽獎系統(tǒng)面臨的難題。

為了解決這些問題，我們采用了一些設(shè)計方法：

1）在接入層采用一致性 Hash 算法：同一用戶的抽獎?wù)埱笾粫D(zhuǎn)發(fā)到相同的抽獎系統(tǒng)處理 ;

2）抽獎系統(tǒng)采用緩存機制：在加快抽獎過程的同時也減少了對存儲層的訪問壓力；

3）獎品配額機制：平滑抽獎過程，各類獎品按比例有序抽中；

4）流水和對賬機制：保證抽獎數(shù)據(jù)最終無差錯發(fā)放到用戶賬戶中。

抽獎系統(tǒng)的架構(gòu)如下圖所示：

4.2.2 緩存機制

業(yè)務(wù)要求在每個刷一刷的活動中，能對用戶中獎次數(shù)、參與時間（30 秒）進行限制。如果用戶的每個抽獎?wù)埱蟮絹頃r，先到存儲層獲取用戶的中獎歷史信息，再判定用戶是否還有抽獎資格，在海量高并發(fā)的請求場景下，勢必會對存儲層造成巨大的壓力。所以這里我們引入了本地內(nèi)存緩存層，用于保存用戶的中獎歷史信息，每次請求到來時，會先到緩存層獲取用戶的中獎歷史信息，如果在緩存層沒找到，才會到存儲層獲取，這樣就不會對存儲層造成太大的壓力，同時也能實現(xiàn)業(yè)務(wù)的需求。緩存層我們采用開源 Memcached 組件實現(xiàn)。

4.2.3 一致性 hash 尋址

紅包抽獎系統(tǒng)是一個分布式的系統(tǒng)，因此為了使緩存機制生效，我們在手機 QQ 接入層使用了一致性 hash 的路由算法進行尋址，保證同一個用戶（uin）的請求總會落在同一臺邏輯機器進行處理。

4.2.4 協(xié)議處理模塊

由于手機 QQ 后臺既要處理客戶端的二進制請求，也要處理其他 Web 系統(tǒng)的 HTTP 請求，所以協(xié)議處理模塊的首要任務(wù)就是兼容各種格式的協(xié)議，給后端模塊一個最簡單的結(jié)構(gòu)。為此我們制定了 Protobuf 格式的交互協(xié)議（兼容 JSON 格式，會統(tǒng)一轉(zhuǎn)換成 Protobuf 處理），傳給后端模塊。

4.2.5 配額管理模塊

手機 QQ 春節(jié)紅包是通過很多場定時“活動”來發(fā)放紅包的。每場活動里面能發(fā)放多少現(xiàn)金，能發(fā)放多少虛擬物品，發(fā)放的比例如何，這些都是配額數(shù)據(jù)。

更進一步，我們要做到精確控制現(xiàn)金和虛擬物品的發(fā)放速度，使得無論何時用戶來參加活動，都有機會獲得紅包，而不是所有紅包在前幾分鐘就被用戶橫掃一空。

配額信息由配額管理工具負責(zé)檢查和修改，每次修改都會生成新的 SeqNo。一旦配額 agent 發(fā)現(xiàn) SeqNo 發(fā)生變化，則會更新本地共享內(nèi)存。由于 agent 采用雙 buffer 設(shè)計，所以更新完成前不會影響當(dāng)前業(yè)務(wù)進程。

4.2.6 抽獎模塊

聚焦到抽獎，QQ 紅包的抽獎算法其實并不復(fù)雜，但是能否滿足產(chǎn)品需要非常重要。

我們的設(shè)計思路是至少需要滿足如下需求：

1）可以在秒級別控制現(xiàn)金和每種物品的發(fā)放速度；

2）可以方便調(diào)整現(xiàn)金和每種物品的發(fā)放比例；

3）盡量保證紅包全部發(fā)放出去。

為此，我們設(shè)計了如下的抽獎流程算法：

需要說明的是，只要是因為配額限制發(fā)放紅包失敗，我們都會繼續(xù)嘗試給用戶發(fā)放其他獎品的紅包，直到?jīng)]有獎品可以發(fā)放，這樣我們就能保證把獎品盡可能發(fā)放出去。

4.2.7 流水系統(tǒng)設(shè)計

流水系統(tǒng)用于保存活動過程中的抽獎流水記錄，在活動后對獎品發(fā)放和領(lǐng)用進行統(tǒng)計和對賬。該系統(tǒng)還定時對領(lǐng)用失敗的請求進行重做和對賬，確保獎品發(fā)放到用戶賬戶里。

流水系統(tǒng)架構(gòu)如下：

由于流水需要記錄用戶中獎的信息和領(lǐng)用的的情況，數(shù)據(jù)量巨大，所以抽獎邏輯層本地采用順序?qū)懳募姆绞竭M行記錄。抽獎邏輯層會定期的把本地的流水文件同步到遠程流水系統(tǒng)進行匯總和備份，同時，流水系統(tǒng)會對領(lǐng)用失敗的流水進行重做，發(fā)送請求到抽獎邏輯層，抽獎邏輯層會調(diào)用發(fā)貨系統(tǒng)的接口完成發(fā)貨操作。

4.2.8 存儲層選型

存儲層的設(shè)計向來都是后臺架構(gòu)設(shè)計中的重點和難點。目前騰訊公司內(nèi)部較成熟的 NoSQL 存儲系統(tǒng)有 CKV、Grocery，經(jīng)過一番對比我們選擇使用 Grocery，主要原因有以下幾點。

1）強大的帶條件判斷的分布式原子算數(shù)運算：

抽獎邏輯里需要對每個獎品進行計數(shù)，避免多發(fā)少發(fā)，所以一個高效可靠的分布式原子加計數(shù)器顯得格外重要，Grocery 支持帶條件判斷的原子加計數(shù)器，調(diào)用一次接口就能完成獎品計數(shù)值與配額的判斷以及獎品計數(shù)值的增加。

2）靈活的數(shù)據(jù)類型：

Grocery 支持 Key-Key-Row 類型的數(shù)據(jù)存儲格式，可以靈活的存儲用戶的紅包中獎信息，為獲取用戶單個紅包或者紅包列表提供了豐富的接口。

3）部署、擴容方便：

Grocery 有專門的團隊支持，易于部署和擴容。

4）平滑限頻設(shè)計：

每一種獎品，對應(yīng)的業(yè)務(wù)都有他們自己的容量能力，且各業(yè)務(wù)的能力也不盡相同（如黃鉆 4w/s，京東 2k/s 等）。為保證紅包活動持續(xù)進行，抽獎系統(tǒng)必須嚴格按業(yè)務(wù)控制派發(fā)峰值。派發(fā)峰值支持實時可調(diào)，避免由于業(yè)務(wù)方評估不足引起過載。

考慮這樣一種場景，如果請求是在 1 秒的最開始全部涌到業(yè)務(wù)方，受限于業(yè)務(wù)方不同的架構(gòu)實現(xiàn)，有可能會觸發(fā)業(yè)務(wù)方的頻率限制或者是過載保護。為此，我們將頻限粒度調(diào)整到百毫秒，這樣獎品就會在 1 秒內(nèi)相對平均的發(fā)放，從而解決了上述問題。

4.3、QQ 紅包發(fā)貨系統(tǒng)

QQ 紅包獎品包括現(xiàn)金和禮券兩類，現(xiàn)金對接財付通，禮券又分騰訊公司內(nèi)部虛擬物品和第三方禮券。最終禮品落地到用戶的賬戶（QQ 錢包余額、QQ 卡券或第三方系統(tǒng)賬戶）中。雖然抽獎系統(tǒng)有作平滑處理，但持續(xù)長時間的大流量發(fā)貨，也可能導(dǎo)致業(yè)務(wù)系統(tǒng)不能正常提供峰值下的服務(wù)能力。如何承上啟下，既預(yù)防抽獎系統(tǒng)不能平滑地發(fā)貨導(dǎo)致壓跨發(fā)貨系統(tǒng)（自身），又能保護后端業(yè)務(wù)系統(tǒng)的情況下，以較快的速度將獎品安全發(fā)放到賬，是發(fā)貨系統(tǒng)的設(shè)計要點。

發(fā)貨系統(tǒng)設(shè)計遵循以下策略：

1）快慢分離；

2）異步削峰；

3）柔性處理；

4）保護業(yè)務(wù)系統(tǒng)；

5）最終一致性。

發(fā)貨系統(tǒng)架構(gòu)如下圖所示：

快慢分離：

現(xiàn)金和禮券后端的系統(tǒng)完全不同，現(xiàn)金通過 QQ 錢包系統(tǒng)發(fā)放入財付通賬戶，要求實時到賬不能延遲。而禮券對接的后端業(yè)務(wù)千差萬別，服務(wù)容量和性能各不相同。為了不讓慢速的禮券發(fā)放影響快速的現(xiàn)金發(fā)放，將現(xiàn)金通道與禮券通道分離，互不干擾。

異步削峰：

由于用戶來抽獎的時機完全是隨機的，抽獎系統(tǒng)并不能做到絕對平滑發(fā)貨。任由抽獎系統(tǒng)將發(fā)貨請求直接透傳到業(yè)務(wù)系統(tǒng)，將出現(xiàn)不可預(yù)知的問題，嚴重時可能會導(dǎo)致業(yè)務(wù)系統(tǒng)雪崩，這是不能接受的。另外象游戲禮包類、滴滴券等第三方禮券，可能用戶賬戶并不存在（用戶并不玩該款游戲，或用戶并沒有第三方賬戶），需要先引導(dǎo)用戶創(chuàng)建賬戶才能發(fā)貨，這就要求發(fā)貨系統(tǒng)有暫存獎品信息，具備延后發(fā)貨的能力。

發(fā)貨系統(tǒng)采用開源的 RocketMQ 消息中間件作為異步消息隊列，暫存發(fā)貨請求，再由禮券發(fā)貨模塊根據(jù)各業(yè)務(wù)的限速配置均勻地調(diào)用業(yè)務(wù)接口進行發(fā)貨。

柔性處理：

禮券類獎品通過異步方式發(fā)放到用戶賬戶，在除夕高峰值可能發(fā)放速度跟不上抽獎速度，會延后一些時間才能到賬，這對不明真相用戶可能會造成困擾。因此在用戶中獎信息頁面中，會提示用戶 24 小時（或 48 小時）到賬。發(fā)貨過程的每個步驟，都有可以異常失敗，導(dǎo)致發(fā)貨不成功，因此在物品詳細頁面的按鈕支持多次發(fā)起發(fā)貨，在“禮券發(fā)貨”模塊根據(jù)發(fā)貨狀態(tài)，可以多次嘗試發(fā)貨，并保證一個獎品只發(fā)放一次。

保護業(yè)務(wù)系統(tǒng)：

前面已經(jīng)提過，發(fā)貨系統(tǒng)通過異步消息隊列，將抽獎系統(tǒng)與業(yè)務(wù)開發(fā)隔離開，抽獎洪峰不會直接影響業(yè)務(wù)系統(tǒng)，對業(yè)務(wù)系統(tǒng)起來隔離保護作用。

禮券發(fā)貨模塊針對每個業(yè)務(wù)單獨配置限速閾值，對各業(yè)務(wù)的發(fā)貨嚴格以不超過限速閾值的速度發(fā)放獎品，如果業(yè)務(wù)有超時或提示超速，再按一定比較再減速。

禮券發(fā)貨模塊首先會到存儲系統(tǒng)檢查獎品是否真實有效，再到發(fā)貨狀態(tài)存儲檢查狀態(tài)是否正常，只有真正需要的發(fā)貨的獎品才向業(yè)務(wù)系統(tǒng)發(fā)起發(fā)貨請求，確保發(fā)貨的有效性，避免錯發(fā)和多發(fā)。

最終一致性：

由于采用異步發(fā)貨，抽獎時刻獎品不能保證立即發(fā)放到用戶賬戶中。但用戶的獎品不會丟失，通過在異步隊列中暫存，禮券發(fā)貨模塊逐步以合適的速度將獎品發(fā)放到用戶賬戶中。

如果發(fā)貨過程中有延時或失敗，用戶可以通過多次領(lǐng)取提起發(fā)貨請求，系統(tǒng)支持多次提交。

如果多次發(fā)貨仍然失敗，對賬工具第 2 天會從流水系統(tǒng)中將用戶抽獎數(shù)據(jù)與發(fā)貨數(shù)據(jù)進行對賬，對發(fā)貨異常用戶再次發(fā)起發(fā)貨。如果對賬仍然失敗，則提醒管理人員介入處理。

五、手機QQ移動端的優(yōu)化策略

普通用戶不會關(guān)心 QQ 紅包的后臺有多復(fù)雜，他們在手機QQ移動端搶紅包時的體驗直接決定著用戶對 QQ 紅包的評價。對用戶來說，看到紅包后能否順暢的搶和刷，是最直接的體驗痛點，因此需要盡可能降低延遲以消除卡頓體驗，甚至在弱網(wǎng)環(huán)境下，也要能有較好的體驗。為了實現(xiàn)該目標，手機QQ移動端采取了以下優(yōu)化策略：

1）資源預(yù)加載：

QQ 紅包中用到的不經(jīng)常變化的靜態(tài)資源，如頁面，圖片，JS 等，會分發(fā)到各地 CDN 以提高訪問速度，只有動態(tài)變化的內(nèi)容，才實時從后臺拉取。然而即使所有的靜態(tài)資源都采用了 CDN 分發(fā)，如果按實際流量評估，CDN 的壓力仍然無法絕對削峰。因為同時訪問紅包頁面的人數(shù)比較多，按 83 萬 / 秒的峰值，一個頁面按 200K 評估，約需要 158.3G 的 CDN 帶寬，會給 CDN 帶來瞬間很大的壓力。為減輕 CDN 壓力，QQ 紅包使用了手機 QQ 離線包機制提前把紅包相關(guān)靜態(tài)資源預(yù)加載到手機QQ移動端，這樣可大大降低 CDN 壓力。

目前手機 QQ 離線包有兩種預(yù)加載方式：

a. 將靜態(tài)資源放入預(yù)加載列表：用戶重新登錄手機 QQ 時監(jiān)測離線包是否有更新并按需加載（1 天能覆蓋 60%，2 天能覆蓋 80%，適合預(yù)熱放量情況）；

b. 主動推送離線包：向當(dāng)前在線用戶推送離線包。（2 個小時可以完成推送，覆蓋總量的 40% 左右，適合緊急情況）通過離線包預(yù)加載后，除夕當(dāng)天的 CDN 流量并沒有出現(xiàn)異常峰值，比較平穩(wěn)。

2）緩存和延時：

2.59 億用戶同時在線，用戶刷一刷時的峰值高達 83 萬 / 秒，如果這些用戶的操作請求全部同時擁向后臺，即使后臺能抗得住，需要的帶寬、設(shè)備資源成本也是天文數(shù)字。為了盡可能減輕后臺服務(wù)器壓力，根據(jù)用戶刷一刷的體驗，用戶每次刷的操作都向后臺發(fā)起請求是沒有必要的，因此手機 QQ 在移動端對用戶刷一刷的操作進行計數(shù)，定時（1~3 秒）異步將匯總數(shù)據(jù)提交到后臺抽獎，再將抽獎結(jié)果回傳到手機 QQ 移動端顯示。這樣既保證了“刷”的暢快體驗，也大大減輕后臺壓力，抽獎結(jié)果也在不經(jīng)意間生產(chǎn)，用戶體驗完全無損。

3）錯峰：

對用戶進行分組，不同組的用戶刷一刷紅包（企業(yè)明星紅包、AR 紅包等）的開始時間并不相同，而是錯開一段時間（1~5 分鐘），這樣通過錯開每一輪刷紅包的開始時間，可以有效平滑用戶刷一刷的請求峰值。

4）動態(tài)調(diào)整：

手機 QQ 移動端和后臺并不是兩個孤立的系統(tǒng)，而是一個整體。手機 QQ 系統(tǒng)搭建有一整套的負載監(jiān)控體系，當(dāng)后臺負載升高到警戒線時，手機 QQ 移動端可以根據(jù)后臺負載情況，動態(tài)減少發(fā)向后臺的請求，以防止后臺出現(xiàn)超載而雪崩。

5）總量限制和清理：

在刷一刷紅包和 AR 紅包過程中，當(dāng)用戶已經(jīng)抽中的獎品數(shù)達到一個限值（例如 5 個），用戶不能再中獎，這時用戶的抽獎?wù)埱蟛辉傧蚝笈_發(fā)送，而是移動端直接告知用戶“未中獎，請稍后再試”，和清除 AR 紅包地圖中的紅包顯示。

六、紅包創(chuàng)新玩法挑戰(zhàn)

春節(jié)紅包大戰(zhàn)，從企業(yè)紅包演變到刷一刷紅包、個性化紅包和 AR 紅包，玩法不斷創(chuàng)新，用戶體驗更好，活躍度提升，參與人數(shù)也從 2 億增長到 17 年春節(jié)的 3.42 億。

6.1、個性化紅包

6.1.1 基本情況

QQ 個性紅包是在紅包外觀上的一次大膽嘗試，借助該功能，用戶可使用霸氣的書法體將自己的姓氏／或其他文字（提供自動簡繁體轉(zhuǎn)換）鐫刻在紅包封皮上。此外，我們還提供了具有新年氛圍的賀歲紅包、與騰訊 IP 緊密結(jié)合的 QQ family、游戲形象、動漫形象等卡通紅包，大大提高了 QQ 紅包的趣味性與觀賞性。個性紅包功能上線后，有超過 30% 的紅包用戶選擇使用個性紅包。在 2016 年春節(jié)期間共有 1500 萬用戶使用該功能，2016 年除夕當(dāng)晚突破 8 千萬的個性紅包發(fā)送量。

個性紅包在普通基礎(chǔ)上，允許用戶修改紅包封皮，展示個性，應(yīng)合場景，因此設(shè)計的要點是使用戶操作順暢，既保持發(fā)、搶紅包的流暢體驗，又能顯示個性和有趣好玩。

個性化紅包流程架構(gòu)如下圖所示：

從上圖可以看出，簡化后的紅包的發(fā)放過程經(jīng)歷紅包移動端 -> 財付通 -> 紅包后臺 -> 手機 QQ AIO（聊天交互窗口）-> 拆（搶）紅包頁面等過程，流程較長（忽略了一些細節(jié)，實際流程更復(fù)雜），在這些步驟過程中如果每一步都走后臺判斷個性化紅包狀態(tài)，必然影響到紅包的發(fā)放流暢性。

為了盡量不影響用戶發(fā)紅包體驗，個性化紅包在架構(gòu)和運營上作了很多解藕和柔性設(shè)計。包括個性字體提前繪制，資源預(yù)加載，功能開關(guān)和容災(zāi)柔性處理等。

6.1.2 字體提前繪制

個性化紅包支持所有簡體與繁體漢字，并支持部分簡體漢字轉(zhuǎn)換成繁體漢字，為了改善使用“姓氏紅包”用戶的體驗，我們把常用的 300 個姓氏，使用預(yù)生成的方式，在用戶手機 QQ 空閑的時候生成常用的姓氏圖片保存到本地。其他的非常用姓氏，在展示的時候合成，合成一次保存在本地，下次在本地讀取。

手機 QQ 移動端在空閑時繪制好字體貼圖，支持定時更新背景圖和字體庫，對非常用字，則啟動個性化字體引擎生成對應(yīng)的個性化貼圖。

用戶在發(fā)放或收到紅包時，個性化背景和字體貼圖已經(jīng)生成好，不需要再生成，收發(fā)紅包流暢體驗無損。

6.1.3 資源預(yù)加載

個性化紅包封素材提前制作好，上傳到 CDN 網(wǎng)絡(luò)，手機 QQ 在空閑時提前從 CDN 下載素材文件，并定時檢查素材更新情況，及時更新。

6.1.4 功能開關(guān)

用戶是否設(shè)置個性紅包，選擇的個性紅包貼圖樣式，是否啟用個性紅包等信息，如果每次判斷都從后臺拉取，勢必增加后臺壓力。用戶對個性紅包的設(shè)置信息，其實變化不大，并且訪問紅包商場實時設(shè)置的狀態(tài)的結(jié)果在手機 QQ 移動端是存在的。因此我們設(shè)計將這些用戶狀態(tài) FLAG 在手機 QQ 登錄時，從后臺拉取一次后保存在手機 QQ 移動端，在發(fā)紅包的過程中將 FLAG 信息傳遞到下游服務(wù)中，通過紅包商城設(shè)置的個性化紅包標志，實時更新手機 QQ本地配置。

這樣的設(shè)計有幾個好處：

1）用戶的個性化設(shè)置不再依賴于后臺，發(fā)紅包過程完全本地操作，沒有任何延時，不影響紅包的發(fā)放；

2）FLAG 標志可以作為容災(zāi)開關(guān)，如果臨時取消個性紅包，或后臺故障，可以臨時屏蔽個性紅包功能，恢復(fù)為默認紅包樣式，保障任何時刻紅包功能正常可用；

3）FLAG 標志可支持擴展，在紅包后臺可以根據(jù)擴展，支持付費紅包樣式（付費購買）、特權(quán)紅包樣式（如超會專享）等，支持紅包商城擴展各種各樣的個性化紅包；

4）除了從后臺拉取 FLAG，當(dāng)業(yè)務(wù)有調(diào)整導(dǎo)致 FLAG 變化，紅包后臺可以向手機 QQ 移動端主動 push FLAG 狀態(tài)，使得用戶及時感知變化，進一步增強用戶使用體驗。

6.1.5 容災(zāi)柔性處理

相對于手機 QQ 平臺功能，個性紅包系統(tǒng)相對獨立，運營和更新很快，系統(tǒng)各功能組件出現(xiàn)問題的幾率可能較多，如果個性紅包業(yè)務(wù)出現(xiàn)問題，而影響到正常紅包發(fā)放或手機 QQ 功能的使用，會對 QQ 口碑造成很大負面影響。我們在系統(tǒng)中設(shè)計了多處容災(zāi)和柔性處理措施，在個性紅包業(yè)務(wù)異常時，能降級提供服務(wù)，最差時取消個性紅包功能。

柔性措施一：用戶登錄時拉取個性紅包 FLAG 失敗時，采用默認紅包樣式；

柔性措施二：紅包后臺向個性化紅包后臺拉取個性化設(shè)置鑒權(quán)詳情（是否付費、是否會員專享等）時，如果拉取異常，采用默認紅包樣式；

柔性措施三：個性化紅包由用戶輸入姓氏，指定顯示文字，可能遇到敏感字或需要臨時下線，可以通過向手機 QQ 下發(fā) FLAG 標志，臨時取消個性紅包功能，恢復(fù)到默認紅包樣式。

6.2、AR 紅包

6.2.1 概述

AR 紅包是“LBS+AR 天降紅包”的簡稱，這個創(chuàng)新的玩法得到了用戶的一致好評，參與用戶 2.57 億次，共計領(lǐng)取紅包和禮券 20.5 億個，獲得了口碑和活躍的雙豐收。

6.2.2 緩存設(shè)計

LBS+AR 紅包與以往的紅包最大的不同在于多了一重地理位置關(guān)聯(lián)，全國有上千萬的地理位置信息，結(jié)合活動的任務(wù)獎品數(shù)據(jù)產(chǎn)生了海量的配置數(shù)據(jù)，而這些數(shù)據(jù)都需要快速實時讀取。這是系統(tǒng)設(shè)計的一大挑戰(zhàn)。

配置數(shù)據(jù)有以下特點：

1）數(shù)據(jù)量很大（億級），數(shù)據(jù)間有緊密的關(guān)聯(lián)，我們采用 MySQL 數(shù)據(jù)庫集群存儲，并構(gòu)建有 Web 可視化配置投放平臺，實現(xiàn)自動容災(zāi)和備份的功能；

2）“一次配好，到處使用”，配置讀量遠高于寫量，基本思想是設(shè)計開發(fā)一種緩存，放棄寫性能，將讀性能優(yōu)化到極致。

上千兆的配置數(shù)據(jù)，如何供抽獎系統(tǒng)快速檢索？考慮到業(yè)務(wù)使用場景、配置數(shù)據(jù)大小及 MySQL 性能，可以采用預(yù)先構(gòu)建全量緩存并進行有序組織，由同步模塊負責(zé)將構(gòu)建好的配置數(shù)據(jù)同步到抽獎系統(tǒng)，供業(yè)務(wù)進程直接使用。為保證配置數(shù)據(jù)完整性，構(gòu)建緩存采用雙 Buffer 設(shè)計，只有構(gòu)建或同步完成后才切換到最新配置。

6.2.3 地圖打點與查點

基于 LBS 的紅包活動離不開地理位置相關(guān)的業(yè)務(wù)交互。在 AR 紅包中，用戶打開地圖會定期向后臺上報坐標，后臺需要根據(jù)坐標獲取周圍可用的活動任務(wù)投放點，投放點事先都會進行安全篩查，去掉具有安全隱患的區(qū)域，避免給用戶帶來人身安全問題，本節(jié)主要介紹如何管理這些投放點。

地圖格子：

將整個二維平面根據(jù)坐標分成邊長相等的正方形格子，根據(jù)用戶的坐標用簡單的數(shù)學(xué)運算即可獲取相應(yīng)的格子 ID，時間復(fù)雜度 O(1)。一個格子是一次查詢的最小粒度。每次查詢會返回以用戶為中心周圍 5*5 共計 25 個格子的任務(wù)點。

打點：

紅包是以任務(wù)維度投放的，每個任務(wù)關(guān)聯(lián)一個 POI 集合，每個 POI 集合中包含幾個到上百萬不等的 POI 點，每個 POI 點都有一個經(jīng)緯度信息。

打點即是事先建立格子到任務(wù)列表的映射。所有格子數(shù)據(jù)有序組織并存儲在共享內(nèi)存里，使用二分查找提升讀性能。

查點流程：

1） 客戶端上報經(jīng)緯度；

2） 根據(jù)經(jīng)緯度計算中心格子 ID；

3） 根據(jù)中心格子 ID 及半徑配置，獲取周圍格子列表；

4） 在打點系統(tǒng)中獲得此片區(qū)域全部 POI 和任務(wù)信息；

5） 檢查任務(wù)狀態(tài)后返回給客戶端。

6.2.4 采集系統(tǒng)

采集系統(tǒng)主要負責(zé)匯總各行政區(qū)紅包發(fā)放狀態(tài)數(shù)據(jù)，主要提供以下功能：

1）實時返回區(qū)級行政區(qū)紅包計數(shù)；

2）實時接受主邏輯的查詢，返回獎品發(fā)放狀態(tài)；

3）返回活動預(yù)告以及參數(shù)配置等輔助信息。

由于紅包是按行政區(qū)進行投放的，每個行政區(qū)約投放 10 個任務(wù)，每個任務(wù)又關(guān)聯(lián)多種類型的紅包，如果每次查詢區(qū)級紅包余量時，都實時計算和匯總紅包狀態(tài)數(shù)據(jù)，擴散帶來的包量開銷會比較大，為此，我們還是采用雙 Buffer 緩存來解決該問題，一個進程負責(zé)將采集到的數(shù)據(jù)寫到緩存，另一組進程提供查詢服務(wù)。另外，還可以根據(jù)存儲層的壓力，適當(dāng)?shù)卣{(diào)整采集的頻率，使得統(tǒng)計數(shù)據(jù)盡可能實時。

七、本文小結(jié)

自 2015 年起，歷年除夕當(dāng)天 QQ 紅包收發(fā)情況如下表所示，可以看出，參與人數(shù)和紅包首發(fā)總個數(shù)都是節(jié)節(jié)升高。

QQ 紅包業(yè)務(wù)復(fù)雜，海量訪問，涉及業(yè)務(wù)多，流程長，項目的成功離不開相關(guān)兄弟部門的大力支持和能力合作，特別感謝即通產(chǎn)品部、財付通、即通平臺部、SNG 市場部、SNG 商業(yè)廣告中心、增值渠道部、社交用戶體驗設(shè)計部、集團市場與公關(guān)部、增值產(chǎn)品部、社交與效果廣告部、網(wǎng)絡(luò)質(zhì)量部、即通綜合部、架構(gòu)平臺部、社交平臺部、網(wǎng)絡(luò)運營部等 15 個兄弟部門相關(guān)同事的付出和給力支持。

附錄：更多相關(guān)文章

[1] QQ、微信團隊原創(chuàng)技術(shù)文章：

《微信朋友圈千億訪問量背后的技術(shù)挑戰(zhàn)和實踐總結(jié)》

《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(圖片壓縮篇)》

《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(音視頻技術(shù)篇)》

《微信團隊分享：微信移動端的全文檢索多音字問題解決方案》

《騰訊技術(shù)分享：Android版手機QQ的緩存監(jiān)控與優(yōu)化實踐》

《微信團隊分享：iOS版微信的高性能通用key-value組件技術(shù)實踐》

《微信團隊分享：iOS版微信是如何防止特殊字符導(dǎo)致的炸群、APP崩潰的？》

《騰訊技術(shù)分享：Android手Q的線程死鎖監(jiān)控系統(tǒng)技術(shù)實踐》

《微信團隊原創(chuàng)分享：iOS版微信的內(nèi)存監(jiān)控系統(tǒng)技術(shù)實踐》

《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術(shù)實踐分享》

《iOS后臺喚醒實戰(zhàn)：微信收款到賬語音提醒技術(shù)總結(jié)》

《騰訊技術(shù)分享：社交網(wǎng)絡(luò)圖片的帶寬壓縮技術(shù)演進之路》

《微信團隊分享：視頻圖像的超分辨率技術(shù)原理和應(yīng)用場景》

《微信團隊分享：微信每日億次實時音視頻聊天背后的技術(shù)解密》

《QQ音樂團隊分享：Android中的圖片壓縮技術(shù)詳解（上篇）》

《QQ音樂團隊分享：Android中的圖片壓縮技術(shù)詳解（下篇）》

《騰訊團隊分享：手機QQ中的人臉識別酷炫動畫效果實現(xiàn)詳解》

《騰訊團隊分享 ：一次手Q聊天界面中圖片顯示bug的追蹤過程分享》

《微信團隊分享：微信Android版小視頻編碼填過的那些坑》

《微信手機端的本地數(shù)據(jù)全文檢索優(yōu)化之路》

《企業(yè)微信客戶端中組織架構(gòu)數(shù)據(jù)的同步更新方案優(yōu)化實戰(zhàn)》

《微信團隊披露：微信界面卡死超級bug“15。。。。”的來龍去脈》

《QQ 18年：解密8億月活的QQ后臺服務(wù)接口隔離技術(shù)》

《月活8.89億的超級IM微信是如何進行Android端兼容測試的》

《以手機QQ為例探討移動端IM中的“輕應(yīng)用”》

《一篇文章get微信開源移動端數(shù)據(jù)庫組件WCDB的一切！》

《微信客戶端團隊負責(zé)人技術(shù)訪談：如何著手客戶端性能監(jiān)控和優(yōu)化》

《微信后臺基于時間序的海量數(shù)據(jù)冷熱分級架構(gòu)設(shè)計實踐》

《微信團隊原創(chuàng)分享：Android版微信的臃腫之困與模塊化實踐之路》

《微信后臺團隊：微信后臺異步消息隊列的優(yōu)化升級實踐分享》

《微信團隊原創(chuàng)分享：微信客戶端SQLite數(shù)據(jù)庫損壞修復(fù)實踐》

《騰訊原創(chuàng)分享(一)：如何大幅提升移動網(wǎng)絡(luò)下手機QQ的圖片傳輸速度和成功率》

《騰訊原創(chuàng)分享(二)：如何大幅壓縮移動網(wǎng)絡(luò)下APP的流量消耗（下篇）》

《騰訊原創(chuàng)分享(三)：如何大幅壓縮移動網(wǎng)絡(luò)下APP的流量消耗（上篇）》

《微信Mars：微信內(nèi)部正在使用的網(wǎng)絡(luò)層封裝庫，即將開源》

《如約而至：微信自用的移動端IM網(wǎng)絡(luò)層跨平臺組件庫Mars已正式開源》

《開源libco庫：單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]》

《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》

《微信團隊原創(chuàng)分享：Android版微信后臺保活實戰(zhàn)分享(進程保活篇)》

《微信團隊原創(chuàng)分享：Android版微信后臺保活實戰(zhàn)分享(網(wǎng)絡(luò)保活篇)》

《Android版微信從300KB到30MB的技術(shù)演進(PPT講稿) [附件下載]》

《微信團隊原創(chuàng)分享：Android版微信從300KB到30MB的技術(shù)演進》

《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(演講全文)》

《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(PPT講稿) [附件下載]》

《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡》》

《微信海量用戶背后的后臺系統(tǒng)存儲架構(gòu)(視頻+PPT) [附件下載]》

《微信異步化改造實踐：8億月活、單機千萬連接背后的后臺解決方案》

《微信朋友圈海量技術(shù)之道PPT [附件下載]》

《微信對網(wǎng)絡(luò)影響的技術(shù)試驗及分析（論文全文）》

《一份微信后臺技術(shù)架構(gòu)的總結(jié)性筆記》

《架構(gòu)之道：3個程序員成就微信朋友圈日均10億發(fā)布量[有視頻]》

《快速裂變：見證微信強大后臺架構(gòu)從0到1的演進歷程（一）》

《快速裂變：見證微信強大后臺架構(gòu)從0到1的演進歷程（二）》

《微信團隊原創(chuàng)分享：Android內(nèi)存泄漏監(jiān)控和優(yōu)化技巧總結(jié)》

《全面總結(jié)iOS版微信升級iOS9遇到的各種“坑”》

《微信團隊原創(chuàng)資源混淆工具：讓你的APK立減1M》

《微信團隊原創(chuàng)Android資源混淆工具：AndResGuard [有源碼]》

《Android版微信安裝包“減肥”實戰(zhàn)記錄》

《iOS版微信安裝包“減肥”實戰(zhàn)記錄》

《移動端IM實踐：iOS版微信界面卡頓監(jiān)測方案》

《微信“紅包照片”背后的技術(shù)難題》

《移動端IM實踐：iOS版微信小視頻功能技術(shù)方案實錄》

《移動端IM實踐：Android版微信如何大幅提升交互性能（一）》

《移動端IM實踐：Android版微信如何大幅提升交互性能（二）》

《移動端IM實踐：實現(xiàn)Android版微信的智能心跳機制》

《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》

《移動端IM實踐：谷歌消息推送服務(wù)(GCM)研究（來自微信）》

《移動端IM實踐：iOS版微信的多設(shè)備字體適配方案探討》

《信鴿團隊原創(chuàng)：一起走過 iOS10 上消息推送(APNS)的坑》

《騰訊信鴿技術(shù)分享：百億級實時消息推送的實戰(zhàn)經(jīng)驗》

《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實踐（上篇）》

《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實踐（下篇）》

《騰訊TEG團隊原創(chuàng)：基于MySQL的分布式數(shù)據(jù)庫TDSQL十年鍛造經(jīng)驗分享》

《微信多媒體團隊訪談：音視頻開發(fā)的學(xué)習(xí)、微信的音視頻技術(shù)和挑戰(zhàn)等》

《了解iOS消息推送一文就夠：史上最全iOS Push技術(shù)詳解》

《騰訊技術(shù)分享：微信小程序音視頻技術(shù)背后的故事》

《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計的方方面面》

《微信多媒體團隊梁俊斌訪談：聊一聊我所了解的音視頻技術(shù)》

《騰訊音視頻實驗室：使用AI黑科技實現(xiàn)超低碼率的高清實時視頻聊天》

《騰訊技術(shù)分享：微信小程序音視頻與WebRTC互通的技術(shù)思路和實踐》

《手把手教你讀取Android版微信和手Q的聊天記錄(僅作技術(shù)研究學(xué)習(xí))》

《微信技術(shù)分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》

《微信技術(shù)分享：微信的海量IM聊天消息序列號生成實踐（容災(zāi)方案篇）》

《騰訊技術(shù)分享：GIF動圖技術(shù)詳解及手機QQ動態(tài)表情壓縮技術(shù)實踐》

《微信團隊分享：Kotlin漸被認可，Android版微信的技術(shù)嘗鮮之旅》

《全面解密QQ紅包技術(shù)方案：架構(gòu)、技術(shù)實現(xiàn)、移動端優(yōu)化、創(chuàng)新玩法等》

>> 更多同類文章 ……

[2] 有關(guān)QQ、微信的技術(shù)故事：

《技術(shù)往事：微信估值已超5千億，雷軍曾有機會收編張小龍及其Foxmail》

《QQ和微信兇猛成長的背后：騰訊網(wǎng)絡(luò)基礎(chǔ)架構(gòu)的這些年》

《閑話即時通訊：騰訊的成長史本質(zhì)就是一部QQ成長史》

《2017微信數(shù)據(jù)報告：日活躍用戶達9億、日發(fā)消息380億條》

《騰訊開發(fā)微信花了多少錢？技術(shù)難度真這么大？難在哪？》

《技術(shù)往事：創(chuàng)業(yè)初期的騰訊——16年前的冬天，誰動了馬化騰的代碼》

《技術(shù)往事：史上最全QQ圖標變遷過程，追尋IM巨人的演進歷史》

《技術(shù)往事：“QQ群”和“微信紅包”是怎么來的？》

《開發(fā)往事：深度講述2010到2015，微信一路風(fēng)雨的背后》

《開發(fā)往事：微信千年不變的那張閃屏圖片的由來》

《開發(fā)往事：記錄微信3.0版背后的故事（距微信1.0發(fā)布9個月時）》

《一個微信實習(xí)生自述：我眼中的微信開發(fā)團隊》

《首次揭秘：QQ實時視頻聊天背后的神秘組織》

《為什么說即時通訊社交APP創(chuàng)業(yè)就是一個坑？》

《微信七年回顧：歷經(jīng)多少質(zhì)疑和差評，才配擁有今天的強大》

《前創(chuàng)始團隊成員分享：盤點微信的前世今生——微信成功的必然和偶然》

《即時通訊創(chuàng)業(yè)必讀：解密微信的產(chǎn)品定位、創(chuàng)新思維、設(shè)計法則等》

《QQ的成功，遠沒有你想象的那么順利和輕松》

《QQ現(xiàn)狀深度剖析：你還認為QQ已經(jīng)被微信打敗了嗎？》

《[技術(shù)腦洞] 如果把14億中國人拉到一個微信群里技術(shù)上能實現(xiàn)嗎？》

《QQ和微信止步不前，意味著即時通訊社交應(yīng)用創(chuàng)業(yè)的第2春已來？》

《那些年微信開發(fā)過的雞肋功能，及其帶給我們的思考》

《讀懂微信：從1.0到7.0版本，一個主流IM社交工具的進化史》

>> 更多同類文章 ……

（本文同步發(fā)布于：http://www.52im.net/thread-2202-1-1.html）