全面解密QQ紅包技術方案：架構、技術實現、移動端優化、創新玩法等
本文來自騰訊QQ技術團隊工程師許靈鋒、周海發的技術分享。
一、引言
自 2015 年春節以來，QQ 春節紅包經歷了企業紅包（2015 年）、刷一刷紅包（2016 年）和 AR 紅包（2017 年）幾個階段，通過不斷創新玩法，活躍度節節攀升，成為春節一大玩點，給火紅的春節帶來一抹亮色。2017 年除夕，AR 紅包、刷一刷紅包再創新高，搶紅包使用者數達 3.42 億，共刷出紅包 37.77 億個。
那麼，QQ 紅包的技術方案究竟是怎樣的？其整體架構如何？重要的系統是如何設計的？為了保證使用者的體驗，手機 QQ 移動端做了哪些優化？今年的 QQ 紅包又做了哪些新的嘗試，遇到的問題是如何解決的呢？本文將從架構開始，到手機 QQ 移動端優化，再到個性化紅包和 AR 新玩法，為大家全面解密 QQ 紅包技術方案。
學習交流：
- 即時通訊/推送技術開發交流4群：101279154 [推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
（本文同步釋出於：http://www.52im.net/thread-2202-1-1.html）
二、關於作者
▲ 兩位作者，許靈鋒（圖左者）和周海發（圖右者）
turboxu（許靈鋒）：2006 年加入騰訊，會員體系後臺負責人，從事過 MIS 系統、網路安全、滔滔（空間說說）、WAP 音樂、超 Q、會員等專案，對開源元件、虛擬化感興趣，致力於推動 Docker 虛擬化和開源元件的應用和實踐。
haifazhou（周海發）：2011 年加入騰訊，從事 IM 基礎系統開發和運營，先後參與過 PTLogin 統一登入和訊息漫遊儲存改造專案，連續三年參與並負責 QQ 春節紅包後臺系統架構設計，在海量分散式高效能系統設計方面積累了多年經驗。
三、相關文章
《月活8.89億的超級IM微信是如何進行Android端相容測試的》
《開源libco庫：單機千萬連線、支撐微信8億使用者的後臺框架基石 [原始碼下載]》
》《微信技術總監談架構：微信之道——大道至簡(PPT講稿) [附件下載]》
《微信海量使用者背後的後臺系統儲存架構(視訊+PPT) [附件下載]》
《微信非同步化改造實踐：8億月活、單機千萬連線背後的後臺解決方案》
四、QQ 紅包整體架構及重要系統
QQ 春節紅包以一個又一個的整點刷紅包活動貫穿年三十，在除夕夜達到頂峰，是典型的海量使用者秒殺場景，如何應對海量的使用者刷紅包洪流，保證刷得爽，紅包安全到賬，是 QQ 紅包設計要解決的關鍵技術難點。另外，紅包專案涉及手機 QQ 移動端、手機 QQQ 後臺、QQ 錢包（財付通）系統、禮券系統、公眾號等諸多業務系統，流程長且多，各系統效能吞吐量差異很大，如何保證各系統形成一個有機整體，協調高效提供服務，也是難點之一。
下圖為簡化後 QQ 紅包的架構，包括：接入層、抽獎系統、儲存系統、發貨系統、公眾號訊息通知和 CDN 資源等幾部分，請大家先有一個整體的認知，便於閱讀下文。
▲ 簡化後的QQ紅包系統架構
本節將重點講解接入層、抽獎系統和發貨系統。
4.1、接入層
接入層是紅包後臺服務的大門，負責抽獎請求預處理，確保有效的請求才透傳給後端服務。為保證自身高可用、高穩定，接入層還可實時控制手機 QQ 請求頻率，避免海量請求壓垮接入層，出現不可控局面。
在海量服務場景下，為避免網路開銷，方便後端服務使用 cache 提升效能，接入層採用了一致性 Hash 定址，保證同一個使用者的請求只會落在同一臺紅包抽獎邏輯機器處理。
4.2、抽獎系統
4.2.1 基本介紹
抽獎系統作為 QQ 紅包的核心繫統，在承接使用者抽獎請求，按設計合理的機率完成抽獎操作，將抽獎結果安全落地儲存，並順利發貨等過程中，起到了關鍵作用。面對海量抽獎請求，如何及時作出響應，是抽獎系統面臨的難題。
為了解決這些問題，我們採用了一些設計方法：
1）在接入層採用一致性 Hash 演算法：同一使用者的抽獎請求只會轉發到相同的抽獎系統處理 ;
2）抽獎系統採用快取機制：在加快抽獎過程的同時也減少了對儲存層的訪問壓力；
3）獎品配額機制：平滑抽獎過程，各類獎品按比例有序抽中；
4）流水和對賬機制：保證抽獎資料最終無差錯發放到使用者賬戶中。
抽獎系統的架構如下圖所示：
4.2.2 快取機制
業務要求在每個刷一刷的活動中，能對使用者中獎次數、參與時間（30 秒）進行限制。如果使用者的每個抽獎請求到來時，先到儲存層獲取使用者的中獎歷史資訊，再判定使用者是否還有抽獎資格，在海量高併發的請求場景下，勢必會對儲存層造成巨大的壓力。所以這裡我們引入了本地記憶體快取層，用於儲存使用者的中獎歷史資訊，每次請求到來時，會先到快取層獲取使用者的中獎歷史資訊，如果在快取層沒找到，才會到儲存層獲取，這樣就不會對儲存層造成太大的壓力，同時也能實現業務的需求。快取層我們採用開源 Memcached 元件實現。
4.2.3 一致性 hash 定址
紅包抽獎系統是一個分散式的系統，因此為了使快取機制生效，我們在手機 QQ 接入層使用了一致性 hash 的路由演算法進行定址，保證同一個使用者（uin）的請求總會落在同一臺邏輯機器進行處理。
4.2.4 協議處理模組
由於手機 QQ 後臺既要處理客戶端的二進位制請求，也要處理其他 Web 系統的 HTTP 請求，所以協議處理模組的首要任務就是相容各種格式的協議，給後端模組一個最簡單的結構。為此我們制定了 Protobuf 格式的互動協議（相容 JSON 格式，會統一轉換成 Protobuf 處理），傳給後端模組。
4.2.5 配額管理模組
手機 QQ 春節紅包是通過很多場定時“活動”來發放紅包的。每場活動裡面能發放多少現金，能發放多少虛擬物品，發放的比例如何，這些都是配額資料。
更進一步，我們要做到精確控制現金和虛擬物品的發放速度，使得無論何時使用者來參加活動，都有機會獲得紅包，而不是所有紅包在前幾分鐘就被使用者橫掃一空。
配額資訊由配額管理工具負責檢查和修改，每次修改都會生成新的 SeqNo。一旦配額 agent 發現 SeqNo 發生變化，則會更新本地共享記憶體。由於 agent 採用雙 buffer 設計，所以更新完成前不會影響當前業務程序。
4.2.6 抽獎模組
聚焦到抽獎，QQ 紅包的抽獎演算法其實並不複雜，但是能否滿足產品需要非常重要。
我們的設計思路是至少需要滿足如下需求：
1）可以在秒級別控制現金和每種物品的發放速度；
2）可以方便調整現金和每種物品的發放比例；
3）儘量保證紅包全部發放出去。
為此，我們設計瞭如下的抽獎流程演算法：
需要說明的是，只要是因為配額限制發放紅包失敗，我們都會繼續嘗試給使用者發放其他獎品的紅包，直到沒有獎品可以發放，這樣我們就能保證把獎品儘可能發放出去。
4.2.7 流水系統設計
流水系統用於儲存活動過程中的抽獎流水記錄，在活動後對獎品發放和領用進行統計和對賬。該系統還定時對領用失敗的請求進行重做和對賬，確保獎品發放到使用者賬戶裡。
流水系統架構如下：
由於流水需要記錄使用者中獎的資訊和領用的的情況，資料量巨大，所以抽獎邏輯層本地採用順序寫檔案的方式進行記錄。抽獎邏輯層會定期的把本地的流水檔案同步到遠端流水系統進行彙總和備份，同時，流水系統會對領用失敗的流水進行重做，傳送請求到抽獎邏輯層，抽獎邏輯層會呼叫發貨系統的介面完成發貨操作。
4.2.8 儲存層選型
儲存層的設計向來都是後臺架構設計中的重點和難點。目前騰訊公司內部較成熟的 NoSQL 儲存系統有 CKV、Grocery，經過一番對比我們選擇使用 Grocery，主要原因有以下幾點。
1）強大的帶條件判斷的分散式原子算數運算：
抽獎邏輯裡需要對每個獎品進行計數，避免多發少發，所以一個高效可靠的分散式原子加計數器顯得格外重要，Grocery 支援帶條件判斷的原子加計數器，呼叫一次介面就能完成獎品計數值與配額的判斷以及獎品計數值的增加。
2）靈活的資料型別：
Grocery 支援 Key-Key-Row 型別的資料儲存格式，可以靈活的儲存使用者的紅包中獎資訊，為獲取使用者單個紅包或者紅包列表提供了豐富的介面。
3）部署、擴容方便：
Grocery 有專門的團隊支援，易於部署和擴容。
4）平滑限頻設計：
每一種獎品，對應的業務都有他們自己的容量能力，且各業務的能力也不盡相同（如黃鑽 4w/s，京東 2k/s 等）。為保證紅包活動持續進行，抽獎系統必須嚴格按業務控制派發峰值。派發峰值支援實時可調，避免由於業務方評估不足引起過載。
考慮這樣一種場景，如果請求是在 1 秒的最開始全部湧到業務方，受限於業務方不同的架構實現，有可能會觸發業務方的頻率限制或者是過載保護。為此，我們將頻限粒度調整到百毫秒，這樣獎品就會在 1 秒內相對平均的發放，從而解決了上述問題。
4.3、QQ 紅包發貨系統
QQ 紅包獎品包括現金和禮券兩類，現金對接財付通，禮券又分騰訊公司內部虛擬物品和第三方禮券。最終禮品落地到使用者的賬戶（QQ 錢包餘額、QQ 卡券或第三方系統賬戶）中。雖然抽獎系統有作平滑處理，但持續長時間的大流量發貨，也可能導致業務系統不能正常提供峰值下的服務能力。如何承上啟下，既預防抽獎系統不能平滑地發貨導致壓跨發貨系統（自身），又能保護後端業務系統的情況下，以較快的速度將獎品安全發放到賬，是發貨系統的設計要點。
發貨系統設計遵循以下策略：
1）快慢分離；
2）非同步削峰；
3）柔性處理；
4）保護業務系統；
5）最終一致性。
發貨系統架構如下圖所示：
快慢分離：
現金和禮券後端的系統完全不同，現金通過 QQ 錢包系統發放入財付通賬戶，要求實時到賬不能延遲。而禮券對接的後端業務千差萬別，服務容量和效能各不相同。為了不讓慢速的禮券發放影響快速的現金髮放，將現金通道與禮券通道分離，互不干擾。
非同步削峰：
由於使用者來抽獎的時機完全是隨機的，抽獎系統並不能做到絕對平滑發貨。任由抽獎系統將發貨請求直接透傳到業務系統，將出現不可預知的問題，嚴重時可能會導致業務系統雪崩，這是不能接受的。另外象遊戲禮包類、滴滴券等第三方禮券，可能使用者賬戶並不存在（使用者並不玩該款遊戲，或使用者並沒有第三方賬戶），需要先引導使用者建立賬戶才能發貨，這就要求發貨系統有暫存獎品資訊，具備延後發貨的能力。
發貨系統採用開源的 RocketMQ 訊息中介軟體作為非同步訊息佇列，暫存發貨請求，再由禮券發貨模組根據各業務的限速配置均勻地呼叫業務介面進行發貨。
柔性處理：
禮券類獎品通過非同步方式發放到使用者賬戶，在除夕高峰值可能發放速度跟不上抽獎速度，會延後一些時間才能到賬，這對不明真相使用者可能會造成困擾。因此在使用者中獎資訊頁面中，會提示使用者 24 小時（或 48 小時）到賬。發貨過程的每個步驟，都有可以異常失敗，導致發貨不成功，因此在物品詳細頁面的按鈕支援多次發起發貨，在“禮券發貨”模組根據發貨狀態，可以多次嘗試發貨，並保證一個獎品只發放一次。
保護業務系統：
前面已經提過，發貨系統通過非同步訊息佇列，將抽獎系統與業務開發隔離開，抽獎洪峰不會直接影響業務系統，對業務系統起來隔離保護作用。
禮券發貨模組針對每個業務單獨配置限速閾值，對各業務的發貨嚴格以不超過限速閾值的速度發放獎品，如果業務有超時或提示超速，再按一定比較再減速。
禮券發貨模組首先會到儲存系統檢查獎品是否真實有效，再到發貨狀態儲存檢查狀態是否正常，只有真正需要的發貨的獎品才向業務系統發起發貨請求，確保發貨的有效性，避免錯發和多發。
最終一致性：
由於採用非同步發貨，抽獎時刻獎品不能保證立即發放到使用者賬戶中。但使用者的獎品不會丟失，通過在非同步佇列中暫存，禮券發貨模組逐步以合適的速度將獎品發放到使用者賬戶中。
如果發貨過程中有延時或失敗，使用者可以通過多次領取提起發貨請求，系統支援多次提交。
如果多次發貨仍然失敗，對賬工具第 2 天會從流水系統中將使用者抽獎資料與發貨資料進行對賬，對發貨異常使用者再次發起發貨。如果對賬仍然失敗，則提醒管理人員介入處理。
五、手機QQ移動端的優化策略
普通使用者不會關心 QQ 紅包的後臺有多複雜，他們在手機QQ移動端搶紅包時的體驗直接決定著使用者對 QQ 紅包的評價。對使用者來說，看到紅包後能否順暢的搶和刷，是最直接的體驗痛點，因此需要儘可能降低延遲以消除卡頓體驗，甚至在弱網環境下，也要能有較好的體驗。為了實現該目標，手機QQ移動端採取了以下優化策略：
1）資源預載入：
QQ 紅包中用到的不經常變化的靜態資源，如頁面，圖片，JS 等，會分發到各地 CDN 以提高訪問速度，只有動態變化的內容，才實時從後臺拉取。然而即使所有的靜態資源都採用了 CDN 分發，如果按實際流量評估，CDN 的壓力仍然無法絕對削峰。因為同時訪問紅包頁面的人數比較多，按 83 萬 / 秒的峰值，一個頁面按 200K 評估，約需要 158.3G 的 CDN 頻寬，會給 CDN 帶來瞬間很大的壓力。為減輕 CDN 壓力，QQ 紅包使用了手機 QQ 離線包機制提前把紅包相關靜態資源預載入到手機QQ移動端，這樣可大大降低 CDN 壓力。
目前手機 QQ 離線包有兩種預載入方式：
a. 將靜態資源放入預載入列表：使用者重新登入手機 QQ 時監測離線包是否有更新並按需載入（1 天能覆蓋 60%，2 天能覆蓋 80%，適合預熱放量情況）；
b. 主動推送離線包：向當前線上使用者推送離線包。（2 個小時可以完成推送，覆蓋總量的 40% 左右，適合緊急情況）通過離線包預載入後，除夕當天的 CDN 流量並沒有出現異常峰值，比較平穩。
2）快取和延時：
2.59 億使用者同時線上，使用者刷一刷時的峰值高達 83 萬 / 秒，如果這些使用者的操作請求全部同時擁向後臺，即使後臺能抗得住，需要的頻寬、裝置資源成本也是天文數字。為了儘可能減輕後臺伺服器壓力，根據使用者刷一刷的體驗，使用者每次刷的操作都向後臺發起請求是沒有必要的，因此手機 QQ 在移動端對使用者刷一刷的操作進行計數，定時（1~3 秒）非同步將彙總資料提交到後臺抽獎，再將抽獎結果回傳到手機 QQ 移動端顯示。這樣既保證了“刷”的暢快體驗，也大大減輕後臺壓力，抽獎結果也在不經意間生產，使用者體驗完全無損。
3）錯峰：
對使用者進行分組，不同組的使用者刷一刷紅包（企業明星紅包、AR 紅包等）的開始時間並不相同，而是錯開一段時間（1~5 分鐘），這樣通過錯開每一輪刷紅包的開始時間，可以有效平滑使用者刷一刷的請求峰值。
4）動態調整：
手機 QQ 移動端和後臺並不是兩個孤立的系統，而是一個整體。手機 QQ 系統搭建有一整套的負載監控體系，當後臺負載升高到警戒線時，手機 QQ 移動端可以根據後臺負載情況，動態減少發向後臺的請求，以防止後臺出現超載而雪崩。
5）總量限制和清理：
在刷一刷紅包和 AR 紅包過程中，當用戶已經抽中的獎品數達到一個限值（例如 5 個），使用者不能再中獎，這時使用者的抽獎請求不再向後臺傳送，而是移動端直接告知使用者“未中獎，請稍後再試”，和清除 AR 紅包地圖中的紅包顯示。
六、紅包創新玩法挑戰
春節紅包大戰，從企業紅包演變到刷一刷紅包、個性化紅包和 AR 紅包，玩法不斷創新，使用者體驗更好，活躍度提升，參與人數也從 2 億增長到 17 年春節的 3.42 億。
6.1、個性化紅包
6.1.1 基本情況
QQ 個性紅包是在紅包外觀上的一次大膽嘗試，藉助該功能，使用者可使用霸氣的書法體將自己的姓氏／或其他文字（提供自動簡繁體轉換）鐫刻在紅包封皮上。此外，我們還提供了具有新年氛圍的賀歲紅包、與騰訊 IP 緊密結合的 QQ family、遊戲形象、動漫形象等卡通紅包，大大提高了 QQ 紅包的趣味性與觀賞性。個性紅包功能上線後，有超過 30% 的紅包使用者選擇使用個性紅包。在 2016 年春節期間共有 1500 萬用戶使用該功能，2016 年除夕當晚突破 8 千萬的個性紅包傳送量。
個性紅包在普通基礎上，允許使用者修改紅包封皮，展示個性，應合場景，因此設計的要點是使使用者操作順暢，既保持發、搶紅包的流暢體驗，又能顯示個性和有趣好玩。
個性化紅包流程架構如下圖所示：
從上圖可以看出，簡化後的紅包的發放過程經歷紅包移動端 -> 財付通 -> 紅包後臺 -> 手機 QQ AIO（聊天互動視窗）-> 拆（搶）紅包頁面等過程，流程較長（忽略了一些細節，實際流程更復雜），在這些步驟過程中如果每一步都走後臺判斷個性化紅包狀態，必然影響到紅包的發放流暢性。
為了儘量不影響使用者發紅包體驗，個性化紅包在架構和運營上作了很多解藕和柔性設計。包括個性字型提前繪製，資源預載入，功能開關和容災柔性處理等。
6.1.2 字型提前繪製
個性化紅包支援所有簡體與繁體漢字，並支援部分簡體漢字轉換成繁體漢字，為了改善使用“姓氏紅包”使用者的體驗，我們把常用的 300 個姓氏，使用預生成的方式，在使用者手機 QQ 空閒的時候生成常用的姓氏圖片儲存到本地。其他的非常用姓氏，在展示的時候合成，合成一次儲存在本地，下次在本地讀取。
手機 QQ 移動端在空閒時繪製好字型貼圖，支援定時更新背景圖和字型庫，對非常用字，則啟動個性化字型引擎生成對應的個性化貼圖。
使用者在發放或收到紅包時，個性化背景和字型貼圖已經生成好，不需要再生成，收發紅包流暢體驗無損。
6.1.3 資源預載入
個性化紅包封素材提前製作好，上傳到 CDN 網路，手機 QQ 在空閒時提前從 CDN 下載素材檔案，並定時檢查素材更新情況，及時更新。
6.1.4 功能開關
使用者是否設定個性紅包，選擇的個性紅包貼圖樣式，是否啟用個性紅包等資訊，如果每次判斷都從後臺拉取，勢必增加後臺壓力。使用者對個性紅包的設定資訊，其實變化不大，並且訪問紅包商場實時設定的狀態的結果在手機 QQ 移動端是存在的。因此我們設計將這些使用者狀態 FLAG 在手機 QQ 登入時，從後臺拉取一次後儲存在手機 QQ 移動端，在發紅包的過程中將 FLAG 資訊傳遞到下游服務中，通過紅包商城設定的個性化紅包標誌，實時更新手機 QQ本地配置。
這樣的設計有幾個好處：
1）使用者的個性化設定不再依賴於後臺，發紅包過程完全本地操作，沒有任何延時，不影響紅包的發放；
2）FLAG 標誌可以作為容災開關，如果臨時取消個性紅包，或後臺故障，可以臨時遮蔽個性紅包功能，恢復為預設紅包樣式，保障任何時刻紅包功能正常可用；
3）FLAG 標誌可支援擴充套件，在紅包後臺可以根據擴充套件，支援付費紅包樣式（付費購買）、特權紅包樣式（如超會專享）等，支援紅包商城擴充套件各種各樣的個性化紅包；
4）除了從後臺拉取 FLAG，當業務有調整導致 FLAG 變化，紅包後臺可以向手機 QQ 移動端主動 push FLAG 狀態，使得使用者及時感知變化，進一步增強使用者使用體驗。
6.1.5 容災柔性處理
相對於手機 QQ 平臺功能，個性紅包系統相對獨立，運營和更新很快，系統各功能元件出現問題的機率可能較多，如果個性紅包業務出現問題，而影響到正常紅包發放或手機 QQ 功能的使用，會對 QQ 口碑造成很大負面影響。我們在系統中設計了多處容災和柔性處理措施，在個性紅包業務異常時，能降級提供服務，最差時取消個性紅包功能。
柔性措施一：使用者登入時拉取個性紅包 FLAG 失敗時，採用預設紅包樣式；
柔性措施二：紅包後臺向個性化紅包後臺拉取個性化設定鑑權詳情（是否付費、是否會員專享等）時，如果拉取異常，採用預設紅包樣式；
柔性措施三：個性化紅包由使用者輸入姓氏，指定顯示文字，可能遇到敏感字或需要臨時下線，可以通過向手機 QQ 下發 FLAG 標誌，臨時取消個性紅包功能，恢復到預設紅包樣式。
6.2、AR 紅包
6.2.1 概述
AR 紅包是“LBS+AR 天降紅包”的簡稱，這個創新的玩法得到了使用者的一致好評，參與使用者 2.57 億次，共計領取紅包和禮券 20.5 億個，獲得了口碑和活躍的雙豐收。
6.2.2 快取設計
LBS+AR 紅包與以往的紅包最大的不同在於多了一重地理位置關聯，全國有上千萬的地理位置資訊，結合活動的任務獎品資料產生了海量的配置資料，而這些資料都需要快速實時讀取。這是系統設計的一大挑戰。
配置資料有以下特點：
1）資料量很大（億級），資料間有緊密的關聯，我們採用 MySQL 資料庫叢集儲存，並構建有 Web 視覺化配置投放平臺，實現自動容災和備份的功能；
2）“一次配好，到處使用”，配置讀量遠高於寫量，基本思想是設計開發一種快取，放棄寫效能，將讀效能優化到極致。
上千兆的配置資料，如何供抽獎系統快速檢索？考慮到業務使用場景、配置資料大小及 MySQL 效能，可以採用預先構建全量快取並進行有序組織，由同步模組負責將構建好的配置資料同步到抽獎系統，供業務程序直接使用。為保證配置資料完整性，構建快取採用雙 Buffer 設計，只有構建或同步完成後才切換到最新配置。
6.2.3 地圖打點與查點
基於 LBS 的紅包活動離不開地理位置相關的業務互動。在 AR 紅包中，使用者開啟地圖會定期向後臺上報座標，後臺需要根據座標獲取周圍可用的活動任務投放點，投放點事先都會進行安全篩查，去掉具有安全隱患的區域，避免給使用者帶來人身安全問題，本節主要介紹如何管理這些投放點。
地圖格子：
將整個二維平面根據座標分成邊長相等的正方形格子，根據使用者的座標用簡單的數學運算即可獲取相應的格子 ID，時間複雜度 O(1)。一個格子是一次查詢的最小粒度。每次查詢會返回以使用者為中心周圍 5*5 共計 25 個格子的任務點。
打點：
紅包是以任務維度投放的，每個任務關聯一個 POI 集合，每個 POI 集合中包含幾個到上百萬不等的 POI 點，每個 POI 點都有一個經緯度資訊。
打點即是事先建立格子到任務列表的對映。所有格子資料有序組織並存儲在共享記憶體裡，使用二分查詢提升讀效能。
查點流程：
1） 客戶端上報經緯度；
2） 根據經緯度計算中心格子 ID；
3） 根據中心格子 ID 及半徑配置，獲取周圍格子列表；
4） 在打點系統中獲得此片區域全部 POI 和任務資訊；
5） 檢查任務狀態後返回給客戶端。
6.2.4 採集系統
採集系統主要負責彙總各行政區紅包發放狀態資料，主要提供以下功能：
1）實時返回區級行政區紅包計數；
2）實時接受主邏輯的查詢，返回獎品發放狀態；
3）返回活動預告以及引數配置等輔助資訊。
由於紅包是按行政區進行投放的，每個行政區約投放 10 個任務，每個任務又關聯多種型別的紅包，如果每次查詢區級紅包餘量時，都實時計算和彙總紅包狀態資料，擴散帶來的包量開銷會比較大，為此，我們還是採用雙 Buffer 快取來解決該問題，一個程序負責將採集到的資料寫到快取，另一組程序提供查詢服務。另外，還可以根據儲存層的壓力，適當地調整採集的頻率，使得統計資料儘可能實時。
七、本文小結
自 2015 年起，歷年除夕當天 QQ 紅包收發情況如下表所示，可以看出，參與人數和紅包首發總個數都是節節升高。
QQ 紅包業務複雜，海量訪問，涉及業務多，流程長，專案的成功離不開相關兄弟部門的大力支援和能力合作，特別感謝即通產品部、財付通、即通平臺部、SNG 市場部、SNG 商業廣告中心、增值渠道部、社交使用者體驗設計部、集團市場與公關部、增值產品部、社交與效果廣告部、網路質量部、即通綜合部、架構平臺部、社交平臺部、網路運營部等 15 個兄弟部門相關同事的付出和給力支援。
附錄：更多相關文章
[1] QQ、微信團隊原創技術文章：
《騰訊技術分享：騰訊是如何大幅降低頻寬和網路流量的(圖片壓縮篇)》
《騰訊技術分享：騰訊是如何大幅降低頻寬和網路流量的(音視訊技術篇)》
《騰訊技術分享：Android版手機QQ的快取監控與優化實踐》
《微信團隊分享：iOS版微信的高效能通用key-value元件技術實踐》
《微信團隊分享：iOS版微信是如何防止特殊字元導致的炸群、APP崩潰的？》
《騰訊技術分享：Android手Q的執行緒死鎖監控系統技術實踐》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》
《騰訊團隊分享 ：一次手Q聊天介面中圖片顯示bug的追蹤過程分享》
《微信團隊分享：微信Android版小視訊編碼填過的那些坑》
《微信團隊披露：微信介面卡死超級bug“15。。。。”的來龍去脈》
《月活8.89億的超級IM微信是如何進行Android端相容測試的》
《微信客戶端團隊負責人技術訪談：如何著手客戶端效能監控和優化》
《微信團隊原創分享：Android版微信的臃腫之困與模組化實踐之路》
《微信團隊原創分享：微信客戶端SQLite資料庫損壞修復實踐》
《騰訊原創分享(一)：如何大幅提升行動網路下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮行動網路下APP的流量消耗（下篇）》
《騰訊原創分享(三)：如何大幅壓縮行動網路下APP的流量消耗（上篇）》
《如約而至：微信自用的移動端IM網路層跨平臺元件庫Mars已正式開源》
《開源libco庫：單機千萬連線、支撐微信8億使用者的後臺框架基石 [原始碼下載]》
《微信新一代通訊安全解決方案：基於TLS1.3的MMTLS詳解》
《微信團隊原創分享：Android版微信後臺保活實戰分享(程序保活篇)》
《微信團隊原創分享：Android版微信後臺保活實戰分享(網路保活篇)》
《Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載]》
《微信團隊原創分享：Android版微信從300KB到30MB的技術演進》
《微信技術總監談架構：微信之道——大道至簡(PPT講稿) [附件下載]》
《微信海量使用者背後的後臺系統儲存架構(視訊+PPT) [附件下載]》
《微信非同步化改造實踐：8億月活、單機千萬連線背後的後臺解決方案》
《架構之道：3個程式設計師成就微信朋友圈日均10億釋出量[有視訊]》
《微信團隊原創分享：Android記憶體洩漏監控和優化技巧總結》
《微信團隊原創Android資源混淆工具：AndResGuard [有原始碼]》
《移動端IM實踐：Android版微信如何大幅提升互動效能（一）》
《移動端IM實踐：Android版微信如何大幅提升互動效能（二）》
《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》
《移動端IM實踐：谷歌訊息推送服務(GCM)研究（來自微信）》
《信鴿團隊原創：一起走過 iOS10 上訊息推送(APNS)的坑》
《騰訊TEG團隊原創：基於MySQL的分散式資料庫TDSQL十年鍛造經驗分享》
《微信多媒體團隊訪談：音視訊開發的學習、微信的音視訊技術和挑戰等》
《瞭解iOS訊息推送一文就夠：史上最全iOS Push技術詳解》
《騰訊資深架構師乾貨總結：一文讀懂大型分散式系統設計的方方面面》
《騰訊音視訊實驗室：使用AI黑科技實現超低位元速率的高清實時視訊聊天》
《騰訊技術分享：微信小程式音視訊與WebRTC互通的技術思路和實踐》
《手把手教你讀取Android版微信和手Q的聊天記錄(僅作技術研究學習)》
《微信技術分享：微信的海量IM聊天訊息序列號生成實踐（演算法原理篇）》
《微信技術分享：微信的海量IM聊天訊息序列號生成實踐（容災方案篇）》
《騰訊技術分享：GIF動圖技術詳解及手機QQ動態表情壓縮技術實踐》
《微信團隊分享：Kotlin漸被認可，Android版微信的技術嚐鮮之旅》
《全面解密QQ紅包技術方案：架構、技術實現、移動端優化、創新玩法等》
>> 更多同類文章 ……
[2] 有關QQ、微信的技術故事：
《技術往事：微信估值已超5千億，雷軍曾有機會收編張小龍及其Foxmail》
《2017微信資料報告：日活躍使用者達9億、日發訊息380億條》
《技術往事：創業初期的騰訊——16年前的冬天，誰動了馬化騰的程式碼》
《技術往事：史上最全QQ圖示變遷過程，追尋IM巨人的演進歷史》
《開發往事：深度講述2010到2015，微信一路風雨的背後》
《開發往事：記錄微信3.0版背後的故事（距微信1.0釋出9個月時）》
《前創始團隊成員分享：盤點微信的前世今生——微信成功的必然和偶然》
《即時通訊創業必讀：解密微信的產品定位、創新思維、設計法則等》
《[技術腦洞] 如果把14億中國人拉到一個微信群裡技術上能實現嗎？》
《QQ和微信止步不前，意味著即時通訊社交應用創業的第2春已來？》
《讀懂微信：從1.0到7.0版本，一個主流IM社交工具的進化史》
>> 更多同類文章 ……
（本文同步釋出於：http://www.52im.net/thread-2202-1-1.html）