全面解密QQ紅包技術方案：架構、技術實現、移動端優化、創新玩法等
本文來自騰訊QQ技術團隊工程師許靈鋒、周海發的技術分享。php
1、引言
自 2015 年春節以來，QQ 春節紅包經歷了企業紅包（2015 年）、刷一刷紅包（2016 年）和 AR 紅包（2017 年）幾個階段，經過不斷創新玩法，活躍度節節攀升，成爲春節一大玩點，給火紅的春節帶來一抹亮色。2017 年除夕，AR 紅包、刷一刷紅包再創新高，搶紅包用戶數達 3.42 億，共刷出紅包 37.77 億個。html
那麼，QQ 紅包的技術方案到底是怎樣的？其總體架構如何？重要的系統是如何設計的？爲了保證用戶的體驗，手機 QQ 移動端作了哪些優化？今年的 QQ 紅包又作了哪些新的嘗試，遇到的問題是如何解決的呢？本文將從架構開始，到手機 QQ 移動端優化，再到個性化紅包和 AR 新玩法，爲你們全面解密 QQ 紅包技術方案。程序員
學習交流：算法
- 即時通信/推送技術開發交流4羣：101279154 [推薦]數據庫
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》小程序
（本文同步發佈於：http://www.52im.net/thread-2202-1-1.html）後端
2、關於做者
▲ 兩位做者，許靈鋒（圖左者）和周海發（圖右者）微信小程序
turboxu（許靈鋒）：2006 年加入騰訊，會員體系後臺負責人，從事過 MIS 系統、網絡安全、滔滔（空間說說）、WAP 音樂、超 Q、會員等項目，對開源組件、虛擬化感興趣，致力於推進 Docker 虛擬化和開源組件的應用和實踐。緩存
haifazhou（周海發）：2011 年加入騰訊，從事 IM 基礎系統開發和運營，前後參與過 PTLogin 統一登陸和消息漫遊存儲改造項目，連續三年參與並負責 QQ 春節紅包後臺系統架構設計，在海量分佈式高性能系統設計方面積累了多年經驗。安全
3、相關文章
《月活8.89億的超級IM微信是如何進行Android端兼容測試的》
《開源libco庫：單機千萬鏈接、支撐微信8億用戶的後臺框架基石 [源碼下載]》
《微信技術總監談架構：微信之道——大道至簡(PPT講稿) [附件下載]》
《微信海量用戶背後的後臺系統存儲架構(視頻+PPT) [附件下載]》
《微信異步化改造實踐：8億月活、單機千萬鏈接背後的後臺解決方案》
4、QQ 紅包總體架構及重要系統
QQ 春節紅包以一個又一個的整點刷紅包活動貫穿年三十，在除夕夜達到頂峯，是典型的海量用戶秒殺場景，如何應對海量的用戶刷紅包洪流，保證刷得爽，紅包安全到帳，是 QQ 紅包設計要解決的關鍵技術難點。另外，紅包項目涉及手機 QQ 移動端、手機 QQQ 後臺、QQ 錢包（財付通）系統、禮券系統、公衆號等諸多業務系統，流程長且多，各系統性能吞吐量差別很大，如何保證各系統造成一個有機總體，協調高效提供服務，也是難點之一。
下圖爲簡化後 QQ 紅包的架構，包括：接入層、抽獎系統、存儲系統、發貨系統、公衆號消息通知和 CDN 資源等幾部分，請你們先有一個總體的認知，便於閱讀下文。
▲ 簡化後的QQ紅包系統架構
本節將重點講解接入層、抽獎系統和發貨系統。
4.一、接入層
接入層是紅包後臺服務的大門，負責抽獎請求預處理，確保有效的請求才透傳給後端服務。爲保證自身高可用、高穩定，接入層還可實時控制手機 QQ 請求頻率，避免海量請求壓垮接入層，出現不可控局面。
在海量服務場景下，爲避免網絡開銷，方便後端服務使用 cache 提高性能，接入層採用了一致性 Hash 尋址，保證同一個用戶的請求只會落在同一臺紅包抽獎邏輯機器處理。
4.二、抽獎系統
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.三、QQ 紅包發貨系統
QQ 紅包獎品包括現金和禮券兩類，現金對接財付通，禮券又分騰訊公司內部虛擬物品和第三方禮券。最終禮品落地到用戶的帳戶（QQ 錢包餘額、QQ 卡券或第三方系統帳戶）中。雖然抽獎系統有做平滑處理，但持續長時間的大流量發貨，也可能致使業務系統不能正常提供峯值下的服務能力。如何承上啓下，既預防抽獎系統不能平滑地發貨致使壓跨發貨系統（自身），又能保護後端業務系統的狀況下，以較快的速度將獎品安全發放到帳，是發貨系統的設計要點。
發貨系統設計遵循如下策略：
1）快慢分離；
2）異步削峯；
3）柔性處理；
4）保護業務系統；
5）最終一致性。
發貨系統架構以下圖所示：
快慢分離：
現金和禮券後端的系統徹底不一樣，現金經過 QQ 錢包系統發放入財付通帳戶，要求實時到帳不能延遲。而禮券對接的後端業務千差萬別，服務容量和性能各不相同。爲了避免讓慢速的禮券發放影響快速的現金髮放，將現金通道與禮券通道分離，互不干擾。
異步削峯：
因爲用戶來抽獎的時機徹底是隨機的，抽獎系統並不能作到絕對平滑發貨。任由抽獎系統將發貨請求直接透傳到業務系統，將出現不可預知的問題，嚴重時可能會致使業務系統雪崩，這是不能接受的。另外象遊戲禮包類、滴滴券等第三方禮券，可能用戶帳戶並不存在（用戶並不玩該款遊戲，或用戶並無第三方帳戶），須要先引導用戶建立帳戶才能發貨，這就要求發貨系統有暫存獎品信息，具有延後發貨的能力。
發貨系統採用開源的 RocketMQ 消息中間件做爲異步消息隊列，暫存發貨請求，再由禮券發貨模塊根據各業務的限速配置均勻地調用業務接口進行發貨。
柔性處理：
禮券類獎品經過異步方式發放到用戶帳戶，在除夕高峯值可能發放速度跟不上抽獎速度，會延後一些時間才能到帳，這對不明真相用戶可能會形成困擾。所以在用戶中獎信息頁面中，會提示用戶 24 小時（或 48 小時）到帳。發貨過程的每一個步驟，都有能夠異常失敗，致使發貨不成功，所以在物品詳細頁面的按鈕支持屢次發起發貨，在「禮券發貨」模塊根據發貨狀態，能夠屢次嘗試發貨，並保證一個獎品只發放一次。
保護業務系統：
前面已經提過，發貨系統經過異步消息隊列，將抽獎系統與業務開發隔離開，抽獎洪峯不會直接影響業務系統，對業務系統起來隔離保護做用。
禮券發貨模塊針對每一個業務單獨配置限速閾值，對各業務的發貨嚴格以不超過限速閾值的速度發放獎品，若是業務有超時或提示超速，再按必定比較再減速。
禮券發貨模塊首先會到存儲系統檢查獎品是否真實有效，再到發貨狀態存儲檢查狀態是否正常，只有真正須要的發貨的獎品才向業務系統發起發貨請求，確保發貨的有效性，避免錯發和多發。
最終一致性：
因爲採用異步發貨，抽獎時刻獎品不能保證當即發放到用戶帳戶中。但用戶的獎品不會丟失，經過在異步隊列中暫存，禮券發貨模塊逐步以合適的速度將獎品發放到用戶帳戶中。
若是發貨過程當中有延時或失敗，用戶能夠經過屢次領取提起發貨請求，系統支持屢次提交。
若是屢次發貨仍然失敗，對帳工具第 2 天會從流水系統中將用戶抽獎數據與發貨數據進行對帳，對發貨異經常使用戶再次發起發貨。若是對帳仍然失敗，則提醒管理人員介入處理。
5、手機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 紅包地圖中的紅包顯示。
6、紅包創新玩法挑戰
春節紅包大戰，從企業紅包演變到刷一刷紅包、個性化紅包和 AR 紅包，玩法不斷創新，用戶體驗更好，活躍度提高，參與人數也從 2 億增加到 17 年春節的 3.42 億。
6.一、個性化紅包
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.二、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 緩存來解決該問題，一個進程負責將採集到的數據寫到緩存，另外一組進程提供查詢服務。另外，還能夠根據存儲層的壓力，適當地調整採集的頻率，使得統計數據儘量實時。
7、本文小結
自 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）
- 1. 全面解密QQ紅包技術方案：架構、技術實現、移動端優化、創新玩法等 ...
- 2. QQ紅包技術方案全解密
- 3. QQ 紅包技術方案全解密 （二）
- 4. QQ紅包技術方案全解密（一）
- 5. Hadoop技術創新方案
- 6. 技術-技術方案優化策略--數據庫層面
- 7. 技術-技術方案優化策略--代碼層面
- 8. 技術-技術方案優化策略--緩存層面
- 9. Hadoop技術創新解決方案
- 10. 技術-技術方案優化策略--JVM調優
- 更多相關文章...
- • XML 相關技術 - XML 教程
- • Hibernate的快照技術 - Hibernate教程
- • Docker容器實戰(一) - 封神Server端技術
- • 三篇文章瞭解 TiDB 技術內幕——說存儲
-
每一个你不满意的现在，都有一个你没有努力的曾经。