本文來自騰訊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 春節紅包后臺系統架構設計，在海量分布式高性能系統設計方面積累了多年經驗。
三、相關文章
《技術往事：“QQ群”和“微信紅包”是怎么來的？》
《QQ 18年：解密8億月活的QQ后臺服務接口隔離技術》
《月活8.89億的超級IM微信是如何進行Android端兼容測試的》
《開源libco庫：單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]》
《微信技術總監談架構：微信之道——大道至簡(演講全文)》
《微信技術總監談架構：微信之道——大道至簡(PPT講稿) [附件下載]》
《如何解讀《微信技術總監談架構：微信之道——大道至簡》》
《微信海量用戶背后的后臺系統存儲架構(視頻+PPT) [附件下載]》
《微信異步化改造實踐：8億月活、單機千萬連接背后的后臺解決方案》
《微信朋友圈海量技術之道PPT [附件下載]》
《架構之道：3個程序員成就微信朋友圈日均10億發布量[有視頻]》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（一）》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（二）》
四、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 標志可以作為容災開關，如果臨時取消個性紅包，或后臺故障，可以臨時屏蔽個性紅包功能，恢復為默認紅包樣式，保障任何時刻紅包功能正?？捎茫?/p>
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的線程死鎖監控系統技術實踐》
《微信團隊原創分享：iOS版微信的內存監控系統技術實踐》
《讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享》
《iOS后臺喚醒實戰：微信收款到賬語音提醒技術總結》
《騰訊技術分享：社交網絡圖片的帶寬壓縮技術演進之路》
《微信團隊分享：視頻圖像的超分辨率技術原理和應用場景》
《微信團隊分享：微信每日億次實時音視頻聊天背后的技術解密》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》
《騰訊團隊分享：手機QQ中的人臉識別酷炫動畫效果實現詳解》
《騰訊團隊分享 ：一次手Q聊天界面中圖片顯示bug的追蹤過程分享》
《微信團隊分享：微信Android版小視頻編碼填過的那些坑》
《微信手機端的本地數據全文檢索優化之路》
《企業微信客戶端中組織架構數據的同步更新方案優化實戰》
《微信團隊披露：微信界面卡死超級bug“15。。。。”的來龍去脈》
《QQ 18年：解密8億月活的QQ后臺服務接口隔離技術》
《月活8.89億的超級IM微信是如何進行Android端兼容測試的》
《以手機QQ為例探討移動端IM中的“輕應用”》
《一篇文章get微信開源移動端數據庫組件WCDB的一切！》
《微信客戶端團隊負責人技術訪談：如何著手客戶端性能監控和優化》
《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》
《微信團隊原創分享：Android版微信的臃腫之困與模塊化實踐之路》
《微信后臺團隊：微信后臺異步消息隊列的優化升級實踐分享》
《微信團隊原創分享：微信客戶端SQLite數據庫損壞修復實踐》
《騰訊原創分享(一)：如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《騰訊原創分享(三)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《微信Mars：微信內部正在使用的網絡層封裝庫，即將開源》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《開源libco庫：單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《微信團隊原創分享：Android版微信后臺保活實戰分享(進程保活篇)》
《微信團隊原創分享：Android版微信后臺?；顚崙鸱窒?網絡?；钇?》
《Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載]》
《微信團隊原創分享：Android版微信從300KB到30MB的技術演進》
《微信技術總監談架構：微信之道——大道至簡(演講全文)》
《微信技術總監談架構：微信之道——大道至簡(PPT講稿) [附件下載]》
《如何解讀《微信技術總監談架構：微信之道——大道至簡》》
《微信海量用戶背后的后臺系統存儲架構(視頻+PPT) [附件下載]》
《微信異步化改造實踐：8億月活、單機千萬連接背后的后臺解決方案》
《微信朋友圈海量技術之道PPT [附件下載]》
《微信對網絡影響的技術試驗及分析（論文全文）》
《一份微信后臺技術架構的總結性筆記》
《架構之道：3個程序員成就微信朋友圈日均10億發布量[有視頻]》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（一）》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（二）》
《微信團隊原創分享：Android內存泄漏監控和優化技巧總結》
《全面總結iOS版微信升級iOS9遇到的各種“坑”》
《微信團隊原創資源混淆工具：讓你的APK立減1M》
《微信團隊原創Android資源混淆工具：AndResGuard [有源碼]》
《Android版微信安裝包“減肥”實戰記錄》
《iOS版微信安裝包“減肥”實戰記錄》
《移動端IM實踐：iOS版微信界面卡頓監測方案》
《微信“紅包照片”背后的技術難題》
《移動端IM實踐：iOS版微信小視頻功能技術方案實錄》
《移動端IM實踐：Android版微信如何大幅提升交互性能（一）》
《移動端IM實踐：Android版微信如何大幅提升交互性能（二）》
《移動端IM實踐：實現Android版微信的智能心跳機制》
《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》
《移動端IM實踐：谷歌消息推送服務(GCM)研究（來自微信）》
《移動端IM實踐：iOS版微信的多設備字體適配方案探討》
《信鴿團隊原創：一起走過 iOS10 上消息推送(APNS)的坑》
《騰訊信鴿技術分享：百億級實時消息推送的實戰經驗》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇）》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（下篇）》
《騰訊TEG團隊原創：基于MySQL的分布式數據庫TDSQL十年鍛造經驗分享》
《微信多媒體團隊訪談：音視頻開發的學習、微信的音視頻技術和挑戰等》
《了解iOS消息推送一文就夠：史上最全iOS Push技術詳解》
《騰訊技術分享：微信小程序音視頻技術背后的故事》
《騰訊資深架構師干貨總結：一文讀懂大型分布式系統設計的方方面面》
《微信多媒體團隊梁俊斌訪談：聊一聊我所了解的音視頻技術》
《騰訊音視頻實驗室：使用AI黑科技實現超低碼率的高清實時視頻聊天》
《騰訊技術分享：微信小程序音視頻與WebRTC互通的技術思路和實踐》
《手把手教你讀取Android版微信和手Q的聊天記錄(僅作技術研究學習)》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》
《騰訊技術分享：GIF動圖技術詳解及手機QQ動態表情壓縮技術實踐》
《微信團隊分享：Kotlin漸被認可，Android版微信的技術嘗鮮之旅》
《全面解密QQ紅包技術方案：架構、技術實現、移動端優化、創新玩法等》
>> 更多同類文章 ……
[2] 有關QQ、微信的技術故事：
《技術往事：微信估值已超5千億，雷軍曾有機會收編張小龍及其Foxmail》
《QQ和微信兇猛成長的背后：騰訊網絡基礎架構的這些年》
《閑話即時通訊：騰訊的成長史本質就是一部QQ成長史》
《2017微信數據報告：日活躍用戶達9億、日發消息380億條》
《騰訊開發微信花了多少錢？技術難度真這么大？難在哪？》
《技術往事：創業初期的騰訊——16年前的冬天，誰動了馬化騰的代碼》
《技術往事：史上最全QQ圖標變遷過程，追尋IM巨人的演進歷史》
《技術往事：“QQ群”和“微信紅包”是怎么來的？》
《開發往事：深度講述2010到2015，微信一路風雨的背后》
《開發往事：微信千年不變的那張閃屏圖片的由來》
《開發往事：記錄微信3.0版背后的故事（距微信1.0發布9個月時）》
《一個微信實習生自述：我眼中的微信開發團隊》
《首次揭秘：QQ實時視頻聊天背后的神秘組織》
《為什么說即時通訊社交APP創業就是一個坑？》
《微信七年回顧：歷經多少質疑和差評，才配擁有今天的強大》
《前創始團隊成員分享：盤點微信的前世今生——微信成功的必然和偶然》
《即時通訊創業必讀：解密微信的產品定位、創新思維、設計法則等》
《QQ的成功，遠沒有你想象的那么順利和輕松》
《QQ現狀深度剖析：你還認為QQ已經被微信打敗了嗎？》
《[技術腦洞] 如果把14億中國人拉到一個微信群里技術上能實現嗎？》
《QQ和微信止步不前，意味著即時通訊社交應用創業的第2春已來？》
《那些年微信開發過的雞肋功能，及其帶給我們的思考》
《讀懂微信：從1.0到7.0版本，一個主流IM社交工具的進化史》
>> 更多同類文章 ……
（本文同步發布于：http://www.52im.net/thread-2202-1-1.html）