整理 | 田曉旭
新年到，各家大廠的“撒幣”活動終于開獎了！這次你賺到了多少錢？
除了大年三十看春晚，參與各大 App 的春節紅包活動也逐漸成為了中國人的過年傳統。紅包也不再只是“錢”，而是承擔了更多的角色，成為了應用的流量入口和增長引擎。春節紅包的實現，背后少不了大數據、云計算、支付結算等新技術的支持。本文搜集了支付寶、微信、快手、QQ 四家大廠公開分享過的春節紅包技術實踐，以饗讀者。
1
今天你掃福了嗎？支付寶紅包的實現
“敬業福，你掃到了嗎？”相信大家最近應該經常聽到這句話。支付寶集五福已經成為了大多數人春節的必備互動，2020 年春節有 3 億多人集齊了五福，而今年的集福活動又有了新花樣，除了傳統的 AR 掃福和螞蟻森林，增加寫福字和芭芭農場。
其中，掃福字得福卡可能是參與人數最多的，為了解決高并發的問題，采用了客戶端 + 服務端并行處理的架構體系，可支持兩種識別方式：所有圖片都傳至服務端做處理，這樣識別精度更高，但是服務器端能處理的數量有限；二是先走客戶端檢測，客戶端無法識別的再上傳服務端。客戶端檢測能力稍弱，但將計算能力分散到各終端，能極大緩解服務端的壓力。
這么多人參與的集五福活動，其背后的技術支撐是怎樣的？支付寶團隊曾經分享過他們的技術保障，在數據方面比較特別的是采用了 GeaBase 和 OceanBase 兩款數據庫。
由于集五福活動有很多用戶互動的場景，以好友福卡排名榜為例，雖然看上去只是計算每個好友的福卡總數，再進行排序，但是當用戶量級上去之后，這個事情的難度就增加了。假設每人有十個好友，參與活動的用戶是億級，那么查詢量級就會達到數十億級，并且需要實時更新福卡數量。
在這種情況下，Oracle、MySQL 等普通關系型數據庫的表現不是特別突出，查詢用戶好友還可以在毫秒內完成，而查詢好友的好友，耗時就會指數級上升，查詢越深，耗時越長。因此，在集五福的應用場景中采用了螞蟻金服自主研發的分布式圖數據庫 GeaBase。
由于數據的存儲結構和查詢規則不同，查詢深度對于 Geabase 的速度幾乎沒有顯著影響，關系型數據庫 30 秒才能得到查詢結果，而 GeaBase 只需要 0.168 秒；關系型數據庫難以給出結果的查詢，Geabase 也只需 2 秒即可完成。
在集五福這類全民活動中，洪峰流量對于服務器的承壓能力來說是一場大考。在開獎的那一瞬間，就是交答卷和出成績的時刻，每個用戶的中獎邏輯后面都有數十條數據，整體就有幾十億數據需要同步。這些數據需要在 2 分鐘內完成同步，并發數高達每秒上千萬。
如何更有效率，更節省成本地調配服務器資源呢？OceanBase 在其中發揮了作用，它可以在分鐘級別內調度資源承接流量，也可以在洪峰過去之后，快速回收資源，避免浪費。
2
今天你搶紅包了嗎？微信紅包的實現
過年期間，在各種微信群中搶紅包已經成為一種大家喜聞樂見的歡度春節的方式。今年微信紅包比較新鮮的變化是可以自己制作個性化的紅包封面。
微信紅包的使用步驟，相信大家都很熟悉，主要包括包、發、搶、拆、查詢發送紅包和收紅包數量，其中比較關鍵的是發紅包和搶紅包。這是我們普通用戶的角度，從微信團隊的角度看，紅包系統由三部分組成：信息流、業務流和資金流。這三部分在組織架構上由不同的后臺團隊完成：信息流——微信后臺，業務流——微信支付后臺，資金流——財付通后臺。
2016 年除夕活動時的紅包系統架構
搶紅包階段如何做到既輕量又可靠？根據微信團隊介紹，主要是通過三種方式：
零 RPC 調用：一般情況下客戶端發起的請求都是通過接入服務轉發給具體的業務服務處理的，會產生 RPC 調用。但搖一搖邏輯直接嵌入接入服務中，接入服務可以直接處理搖一搖請求，派發紅包。
零數據庫存儲：在搶紅包的過程中，微信團隊完全不使用數據庫，可以達到幾個數量級的性能提升，同時可靠性有了更好的保障。
異步化：用戶搶到紅包后不會同步進行后續的賬務處理，請求會被放入紅包異步隊列，再通過異步隊列轉給微信支付后臺，由微信支付后臺完成后續業務邏輯。
同時，為了應對網絡分裂的問題，微信團隊在每個數據中心都建設三個獨立的數據園區，可以做到在任意一個數據園區出現網絡分裂等故障，甚至徹底變成園區孤島后，另外兩個數據園區可以無損承接整個數據中心的請求。
3
今天你扔骰子了嗎？快手紅包的實現
2021 年 2 月 5 日，快手在香港上市，開盤漲 194%，報 338 港元 / 股，發行價 115 港元 / 股，總市值一度高達 1.39 萬億港元。今年，快手策劃了攢牛氣分 21 億活動，其中包括扔骰子、集福氣、拼牛氣等游戲。
2020 年，快手成為了央視春晚獨家互動合作伙伴，在“春節 10 億現金紅包”活動中，快手紅包互動總量達到了 639 億次，紅包站外分享次數達到 5.9 億次。快手春晚直播間累計觀看人次 7.8 億，最高同時在線人數 2524 萬。
快手在傳統紅包的基礎上玩了很多新花樣，增加了很多新年特效，例如新年燈牌、地標 AR、萌娃拜年、我的一生等等。
這些特效的實現應用了 MR、AR 等技術。MR 是混合現實技術，將春節元素與現實世界融合，創造了一個虛擬和物理對象共存、且能夠實時交互的環境，帶來沉浸式的用戶體驗。快手 App 的 MR 算法通過單攝像頭來采集圖像數據，利用深度學習和立體幾何算法估算出相機的位置，然后實時輸出 3D 數據，成功將 MR 效果融合到真實世界。
除了這些大家都能感受到的技術，還有一些背后默默支撐整個紅包的技術實踐。騰訊云高級工程師陳宏亮之前分享過騰訊云文件存儲 CFS 如何支持快手應用廣告推薦。
據了解，CFS 文件存儲主要與 TKE 容器節點搭配，在春節期間為快手的廣告推薦業務提供保障。CFS 主要參與三項具體的廣告推薦業務流程，分別是模型文件發布、業務應用獲取模型和廣告推薦。春節期間，快手在騰訊云上使用了 3 個 TKE 容器集群共計 4000+ Node、Pod 數量超過 8000 個，以分攤業務壓力。這些 Pod 要將所需的幾十 GB 不等的一組模型文件全部加載后（該組合總共若干組），應用才能啟動。
4
今天你刷一刷了嗎？QQ 春節紅包的實現
與其它平臺的紅包一樣，QQ 春節紅包也擁有多種形式，例如企業紅包、刷一刷紅包、AR 紅包等。
據悉，QQ 春節紅包項目涉及手機 QQ 移動端、手機 QQQ 后臺、QQ 錢包（財付通）系統、禮券系統、公眾號等諸多業務系統，流程長且多，各系統性能吞吐量差異很大。QQ 團隊曾經分享過 QQ 2017 年春節紅包背后的技術實踐。
QQ 紅包的簡化架構主要是由以下部分組成：接入層、抽獎系統、存儲系統、發貨系統、公眾號消息通知和 CDN 資源。其中，接入層是紅包后臺服務的大門，負責抽獎請求預處理，確保有效的請求才透傳給后端服務；抽獎系統是 QQ 紅包的核心系統，負責承接用戶抽獎請求，按設計合理的幾率完成抽獎操作，并將抽獎結果安全落地保存；發貨系統主要是確保最終禮品落地到用戶賬戶中，QQ 錢包余額、QQ 卡券或第三方系統賬戶。
春節紅包的主要特點就是海量、秒殺，用戶期望的是看到紅包之后能夠順暢地搶到，因此降低延遲、消除卡頓就是最直接的體驗，甚至在弱網環境中，也能如絲般順滑。基于此，QQ 團隊在技術上面做了很多優化。
首先是資源預加載，原本 QQ 紅包中不經常變化的靜態資源都會分發到各地 CDN 以提高訪問速度，例如頁面、圖片、JS 等，只有動態變化的內容才會實時從后臺拉取。但是即使所有靜態資源都采用 CDN 分發也無法支持流量洪峰。因此，QQ 團隊采用了一個方法：使用手機 QQ 離線包機制提前把紅包相關靜態資源預加載到手機 QQ 移動端，以此來減輕 CDN 壓力。離線包預加載的方式有兩種，一是將靜態資源放入預加載列表，二是主動推送離線包。
其次是緩存和延時，當流量洪峰來臨時，用戶操作請求同時涌向后臺，后臺服務器是會崩潰的，即使后臺扛住了，那么所需的帶寬和設備資源成本也是天文數字。用戶每次刷的操作都向后臺發起請求是沒必要的，因此，QQ 團隊對用戶的刷一刷次數做了匯總，定時異步將匯總數據提交到后臺，再將結果反饋到 QQ 移動端。
再次是錯峰，通過運營手段將不同紅包活動分散在不同時間點，有效減少請求峰值。
最后是動態調整，手機 QQ 移動端和后臺并不是兩個孤立的系統，而是一個整體。手機 QQ 系統搭建有一整套的負載監控體系，當后臺負載升高到警戒線時，手機 QQ 移動端可以根據后臺負載情況，動態減少發向后臺的請求，以防止后臺出現超載而雪崩。
參考鏈接：
https://www.infoq.cn/article/story-and-technology-innovation-of-alipay-ar-hongbao
https://www.infoq.cn/article/1-billion-bonus-from-the-clouds
https://www.cnblogs.com/qcloud1001/p/12869910.html
https://www.infoq.cn/article/qq-red-envelopes-technology-program
