一、引言

2020年春節(jié)早已過去兩月有余，回顧本次騰訊手Q春節(jié)紅包活動的玩法，主要以答題形式結(jié)合中國傳統(tǒng)文化（成語、詩詞、對聯(lián)、歷史等）的方式進(jìn)行，達(dá)到寓教于樂的效果。

 

▲ 2020年春節(jié)QQ的紅包活動

對于這種大體量的IM社交應(yīng)用運營活動，技術(shù)上除了前端、后臺的大力支撐，對于手Q客戶端來說，又是從哪些方面來保證整個紅包活動的靈活性、穩(wěn)定性和用戶體驗的呢？帶著這個問題，我們一起來閱讀余下的文字。

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

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

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

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

二、內(nèi)容概述

本文將回顧今年的春節(jié)紅包活動中，針對手Q客戶端在活動配置、錯峰、數(shù)據(jù)上報、資源預(yù)下載和柔性策略五個方面進(jìn)行探討和總結(jié)，希望能和大家在后續(xù)春節(jié)紅包項目上一起學(xué)習(xí)交流。

具體來說，這些技術(shù)手段主要是以下幾個方面的內(nèi)容：

1）配置：通過配置控制眾多可變參數(shù)，靈活應(yīng)對活動變化

2）錯峰：解決活動高峰后臺服務(wù)負(fù)載過高的問題，新錯峰方案提升用戶感知體驗

3）數(shù)據(jù)上報：即保證活動數(shù)據(jù)的及時上報，又避免過度消耗資源

4）資源預(yù)下載：解決活動高峰CDN帶寬壓力過高問題的同時，提升用戶體驗；

5）柔性策略：確?；顒硬粫ζ渌鼧I(yè)務(wù)產(chǎn)生太大影響。

三、系列文章

? 系列文章目錄：

《社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實現(xiàn)等》

《社交軟件紅包技術(shù)解密(二)：解密微信搖一搖紅包從0到1的技術(shù)演進(jìn)》

《社交軟件紅包技術(shù)解密(三)：微信搖一搖紅包雨背后的技術(shù)細(xì)節(jié)》

《社交軟件紅包技術(shù)解密(四)：微信紅包系統(tǒng)是如何應(yīng)對高并發(fā)的》

《社交軟件紅包技術(shù)解密(五)：微信紅包系統(tǒng)是如何實現(xiàn)高可用性的》

《社交軟件紅包技術(shù)解密(六)：微信紅包系統(tǒng)的存儲層架構(gòu)演進(jìn)實踐》

《社交軟件紅包技術(shù)解密(七)：支付寶紅包的海量高并發(fā)技術(shù)實踐》

《社交軟件紅包技術(shù)解密(八)：全面解密微博紅包技術(shù)方案》

《社交軟件紅包技術(shù)解密(九)：談?wù)勈諵春節(jié)紅包的設(shè)計、容災(zāi)、運維、架構(gòu)等》

《社交軟件紅包技術(shù)解密(十)：手Q客戶端針對2020年春節(jié)紅包的技術(shù)實踐》（* 本文）

? 其它相關(guān)文章：

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

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

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

四、關(guān)于“配置”

整個春節(jié)紅包活動是通過全局配置進(jìn)行控制的，可動態(tài)修改，以靈活應(yīng)對活動的變更。根據(jù)產(chǎn)品需求，結(jié)合需求變更的可能性，以及通用能力的可復(fù)用性，本次春節(jié)紅包總共定義了四份配置。

1）入口配置：

包含活動入口吊墜、小程序入口Banner和一些控制開關(guān)等配置內(nèi)容。春節(jié)紅包活動橫跨小年、除夕、大年初一，每天有4場答題活動，有些場次為商家專場，因此入口配置中提前以列表形式定義好了各天各場次的具體活動信息。

 

2）大插屏配置：

包含活動預(yù)熱大插屏的配置內(nèi)容，由于剛開始時需求的不確定性，獨立出來作為一份配置，后來還增加了分會場呼吸燈的配置內(nèi)容。

 

3）錯峰配置：

包含本次春節(jié)紅包活動客戶端錯峰方案的配置內(nèi)容，獨立配置，可供手Q其它通用運營業(yè)務(wù)復(fù)用。

4）預(yù)下載配置：

包含春節(jié)紅包活動客戶端需要提前預(yù)下載的資源配置內(nèi)容，本次活動資源預(yù)覆蓋接入使用了QQ錢包業(yè)務(wù)搭建的資源預(yù)下載系統(tǒng)，因此配置參照了QQ錢包預(yù)下載系統(tǒng)制定的格式。

五、關(guān)于“錯峰”

5.1、以往春節(jié)紅包活動的錯峰方案

錯峰，目的是為了解決春節(jié)紅包活動高峰對抽獎后臺負(fù)載帶來瞬間沖擊的問題。以往春節(jié)紅包活動的錯峰方案，主要有以下兩種。

1）通過客戶端緩沖過程，控制對抽獎后臺的請求：

通過控制參與抽獎的頻率、限制抽獎的次數(shù)等方式來進(jìn)行錯峰，如搖一搖、刷一刷等。

 

2）通過對活動入口隨機(jī)時間錯峰顯示，控制對抽獎后臺的請求：

將所有用戶隨機(jī)均勻地映射到活動開始后的一段時間區(qū)間內(nèi)，使用戶錯峰顯示入口進(jìn)入?yún)⑴c活動，如2019年春節(jié)的福袋。錯峰時間的算法形如：hash(uin) % gap。

 

5.2、我們使用的錯峰方案

上節(jié)提到的兩種錯峰方式，第二種與本次春節(jié)紅包活動場景是比較吻合的。

不過，該方案存在一個問題：由于其隨機(jī)性，使得有用戶反饋身邊其他人都能看到活動入口參與抽獎了，而自己卻一直看不到入口。

針對方案二的問題，我們引入了用戶地理位置的因素進(jìn)行改進(jìn)，下圖描述了總體錯峰方案：

 

具體方案實現(xiàn)流程如下：

首先，我們定義了一份錯峰配置，包含錯峰時間間隔和區(qū)域劃分列表，將全國用戶根據(jù)地理位置adcode劃分為多個區(qū)域批次。

對處于同一批次的用戶，他們看到活動入口的時間段是一樣的。假設(shè)配置活動的開始時間為9:00，錯峰時間間隔為1分鐘，那么第一批用戶能看到入口的時間為9:00~9:01，第二批用戶能看到入口的時間為9:01~9:02，以此類推。

主要流程如下：

1）根據(jù)用戶地理位置adcode和錯峰配置進(jìn)行映射，得到映射后的分區(qū)索引i；

2）計算得到一次錯峰時間：T1 = T0 + i*interval；

3）對于同一批次的用戶，通過隨機(jī)時間，將這些用戶隨機(jī)均勻地映射分布到對應(yīng)較小的時間段內(nèi)，計算得到二次錯峰時間：T2 = T1 + hash(uin)%interval；

4）得到的二次錯峰時間T2即為用戶實際可以看到入口參與活動的時間：T = T2；

5）對于地理位置一次錯峰可能出現(xiàn)的異常情況，如用戶未授權(quán)獲取地理位置（占比30%左右）、國外用戶無adcode未匹配到分區(qū)索引等，客戶端可采取一定的兜底策略，如根據(jù)用戶賬號uin進(jìn)行隨機(jī)映射到某個分區(qū)：i = hash(uin) % regions.count 。

該錯峰方案實現(xiàn)時抽離了業(yè)務(wù)依賴，并走獨立配置，可供其它通用性運營業(yè)務(wù)復(fù)用。

同時，該錯峰方案還申請了專利，以下是專利信息：

六、關(guān)于“數(shù)據(jù)上報”

6.1、意義

春節(jié)紅包的數(shù)據(jù)，不僅是衡量活動運營的質(zhì)量指標(biāo)，還會影響到活動的招商。通過對數(shù)據(jù)進(jìn)行監(jiān)控，產(chǎn)品同學(xué)可以根據(jù)實際活動情況調(diào)整產(chǎn)品策略，開發(fā)同學(xué)可以及時發(fā)現(xiàn)并定位問題。同時，數(shù)據(jù)還是申請活動資源的重要依據(jù)。

6.2、核心訴求

春節(jié)紅包這種大型全民活動的數(shù)據(jù)，主要具有上報數(shù)據(jù)量大、上報并發(fā)高、上報場景多樣的特點。

對于春節(jié)紅包數(shù)據(jù)上報，主要有三方面的核心訴求：

1）數(shù)據(jù)能夠及時上報（實時性需求）；

2）避免為及時上報而導(dǎo)致資源的過度消耗（如客戶端性能、網(wǎng)絡(luò)開銷；后臺性能、擴(kuò)容資源等）；

3）確保上報服務(wù)的穩(wěn)定可用（要有可調(diào)整和容錯的能力）。

6.3、為何不使用現(xiàn)有的數(shù)據(jù)上報

為什么不直接使用手Q現(xiàn)有的數(shù)據(jù)上報系統(tǒng)呢？

主要是基于如下幾方面的考慮：

1）可能影響其它長期運營的正常業(yè)務(wù)；

2）定制化成本高（上報后臺需要做一些秒級監(jiān)控、UV統(tǒng)計等定制邏輯）；

3）上報控制不夠靈活、生效慢（通過配置控制上報邏輯，調(diào)整后配置覆蓋需要一定時間才能全部生效）；

4）人力、溝通成本等其它方面的考慮。

6.4、春節(jié)紅包數(shù)據(jù)上報

針對春節(jié)紅包數(shù)據(jù)的特點及核心訴求，我們設(shè)計了本次春節(jié)紅包數(shù)據(jù)上報方案。

6.4.1 數(shù)據(jù)上報架構(gòu) 

如上圖所示：

1）調(diào)用層：封裝了各上報場景的通用上報能力，通過接口層的統(tǒng)一上報接口將上報數(shù)據(jù)轉(zhuǎn)發(fā)給邏輯層進(jìn)行處理。Native、H5均通過原生統(tǒng)一上報接口走SSO通道上報，上報更可靠且無需重復(fù)開發(fā)；

2）邏輯層：主要包括數(shù)據(jù)預(yù)處理、數(shù)據(jù)上報策略和容錯機(jī)制三部分內(nèi)容。其中，數(shù)據(jù)預(yù)處理負(fù)責(zé)對上報的數(shù)據(jù)進(jìn)行聚合、過濾和轉(zhuǎn)換；數(shù)據(jù)上報策略通過后臺可控的參數(shù)來控制數(shù)據(jù)上報的時機(jī)、頻率、大小和存儲，確保數(shù)據(jù)能夠及時上報又不影響客戶端和后臺的性能，而且能夠?qū)崟r動態(tài)調(diào)整；容錯機(jī)制制定了過載策略和降級策略，提供應(yīng)對上報后臺過載的措施；

3）基礎(chǔ)層：即系統(tǒng)和手Q封裝提供的一些基礎(chǔ)能力，如文件I/O、安全加/解密等。

6.4.2 數(shù)據(jù)上報的實現(xiàn)流程

 

如上圖所示：

1）客戶端通過一個串行隊列來處理所有上報的數(shù)據(jù)，對數(shù)據(jù)首先會進(jìn)行聚合、過濾和轉(zhuǎn)換的預(yù)處理，然后將預(yù)處理的數(shù)據(jù)先寫到內(nèi)存緩存中，當(dāng)滿足保存文件的時機(jī)時，再異步寫到磁盤文件中；

2）為避免頻繁寫文件對CPU、磁盤等帶來的影響，客戶端每隔一段時間寫一次文件；為防止內(nèi)存中數(shù)據(jù)丟失，客戶端在前后臺切換、殺進(jìn)程、app crash場景下也會保存文件進(jìn)行補(bǔ)償；

3）當(dāng)滿足上報時機(jī)時，會觸發(fā)數(shù)據(jù)上報請求，并清空緩存數(shù)據(jù)同時保存文件；

4）上報請求回包中帶有上報控制相關(guān)信息，提供了靈活調(diào)整的能力。

6.5、遇到的問題分析與解決

6.5.1 相同埋點數(shù)據(jù)增大請求包大小

春節(jié)紅包的數(shù)據(jù)中，有多類埋點數(shù)據(jù)觸發(fā)多次的情況（如曝光、點擊等），因此一個上報請求包中可能會存在多條相同的埋點數(shù)據(jù)，增大了請求包大小。通過對請求包中的數(shù)據(jù)進(jìn)行二次聚合（批量上報其實是對上報請求做了一次聚合），經(jīng)測試平均可減小請求包大小28%。

另外，針對特定的需求場景，有些數(shù)據(jù)可能是不能聚合的。例如，我們對于操作時間超過1小時的相同數(shù)據(jù)是不會進(jìn)行聚合處理的，因為今年春節(jié)活動有場次的概念，每場活動間隔1個小時，產(chǎn)品同學(xué)可能需要以場次維度統(tǒng)計相關(guān)數(shù)據(jù)，若合并可能會干擾數(shù)據(jù)統(tǒng)計的準(zhǔn)確性。

 

6.5.2 上報請求次數(shù)過多

前期演練監(jiān)控上報請求發(fā)現(xiàn)，一場答題活動結(jié)束后，客戶端上報的請求次數(shù)比預(yù)估中的偏多，與抽獎?wù)埱蟮谋壤^了2:1（預(yù)估上報請求峰值與抽獎?wù)埱蠓逯档谋壤蠹s為5:4）。假如抽獎?wù)埱蟮竭_(dá)到了峰值，那可能上報請求的峰值會更高，需要上報后臺擴(kuò)容更多的機(jī)器。 

我們針對上報請求的top用戶日志進(jìn)行分析，發(fā)現(xiàn)主要有兩方面原因：

1）用戶頻繁前后臺切換觸發(fā)多次上報請求：初始前后臺切換上報的頻控時間設(shè)置了10s比較短，可能導(dǎo)致用戶多次觸發(fā)只有幾條數(shù)據(jù)的請求；

2）一些關(guān)鍵指標(biāo)數(shù)據(jù)（如覆蓋數(shù)據(jù)）最開始走的是實時上報，會有多個只有一條數(shù)據(jù)的上報請求。

針對這兩個原因，我們采取了相應(yīng)的措施：

1）調(diào)整前后臺切換觸發(fā)上報的時間間隔，將秒級改為分鐘級，后臺可控；

2）關(guān)鍵指標(biāo)數(shù)據(jù)改為批量上報，并通過每日一檢的方式增加觸發(fā)時機(jī)。

解決之后上報請求數(shù)小于抽獎?wù)埱髷?shù)，比例降到了1.0以下。經(jīng)測試平均單用戶上報請求數(shù)降低了71.4%。

6.5.3 關(guān)鍵指標(biāo)數(shù)據(jù)不準(zhǔn)確

針對前期的幾次演練，我們統(tǒng)計了配置、資源的覆蓋率，發(fā)現(xiàn)所得到的結(jié)果與預(yù)想中的有些出入。我們所使用的配置系統(tǒng)是在登錄級別拉取的，下發(fā)成功率高于95%，而演練時統(tǒng)計上報數(shù)據(jù)配置的覆蓋率范圍在80~88%之間，懷疑可能覆蓋上報的數(shù)據(jù)丟失了。

我們針對部分有活躍（前臺登錄）但卻沒有覆蓋上報的用戶進(jìn)行了分析，發(fā)現(xiàn)這些用戶確實是拉取到配置并觸發(fā)了覆蓋上報，但上報的數(shù)據(jù)可能丟失了。一方面可能是在內(nèi)存的數(shù)據(jù)未及時同步到文件中，因為初始設(shè)置寫文件的頻率為每30秒寫一次，時間略長，用戶殺進(jìn)程或退后臺等操作場景下，內(nèi)存中的數(shù)據(jù)可能會丟失；另一方面也可能是網(wǎng)絡(luò)原因?qū)е律蠄髷?shù)據(jù)的丟失。

針對這兩個原因，我們采取的對應(yīng)措施：

1）縮短保存文件的時間間隔（對多個值測試綜合性能和時間效率考慮取值10秒），后臺可控，并進(jìn)行多時機(jī)補(bǔ)償：包括前后臺切換、殺進(jìn)程和App Crash三種場景。經(jīng)測試，對比每次都寫文件，每10秒寫一次文件能夠降低對CPU影響66.7%，降低對磁盤的影響87.9%。

 

2）確保關(guān)鍵指標(biāo)數(shù)據(jù)上報成功，并過濾冗余數(shù)據(jù)：把覆蓋類指標(biāo)每日一檢的方式改為每次登錄/斷網(wǎng)重連時就觸發(fā)覆蓋檢查，并加上一定的頻控，覆蓋檢查得出結(jié)果后即上報。當(dāng)覆蓋數(shù)據(jù)實際觸發(fā)上報到后臺并成功回包后，本地記錄上報的狀態(tài)，這樣當(dāng)下次觸發(fā)覆蓋檢查上報前，若判斷該覆蓋數(shù)據(jù)已上報過，就不再上報，直接作為冗余數(shù)據(jù)過濾掉。相比每日一檢的方式（每天都會產(chǎn)生多條覆蓋數(shù)據(jù)上報），這種方式單用戶最多可以節(jié)省93%的覆蓋數(shù)據(jù)量。

 

解決后，之后演練的覆蓋類數(shù)據(jù)恢復(fù)了正常，配置覆蓋率在97%~99%之間。

6.6、容錯機(jī)制

下圖為上報數(shù)據(jù)的流通流程： 

在客戶端數(shù)據(jù)上報到后臺的鏈路中，SSO接入層和上報服務(wù)后臺均有過載的風(fēng)險。針對這兩個風(fēng)險，我們分別用過載策略和降級策略來應(yīng)對。

1）SSO接入層過載：如果SSO接入層過載了，所采用的的過載策略是：由SSO接入層直接回包，客戶端根據(jù)過載標(biāo)記，將批量上報的batchSize值設(shè)置為最大值，并翻倍上報的頻率時間，從而降低客戶端的上報頻率。

2）上報服務(wù)后臺過載：針對上報服務(wù)后臺過載的情況，我們制定了一套降級策略，后臺回包中包含了兩個降級信息：

reportLevel：上報級別，默認(rèn)為0

reportLevelTime：上報級別有效時間，當(dāng)reportLevel>0時有效

我們設(shè)定了4個上報級別，如下圖所示，客戶端根據(jù)后臺設(shè)置的上報級別，來降級上報服務(wù)。如果上報級別設(shè)置為1，則客戶端會將所有實時上報降級為批量上報；更進(jìn)一步的，可以設(shè)置上報級別為2來降級屏蔽非用戶行為類的數(shù)據(jù)上報；甚至可以設(shè)置上報級別為3來屏蔽所有數(shù)據(jù)的上報。通過上報級別有效時間，來確?？蛻舳四軌蚧謴?fù)正常的上報邏輯。

 

6.7、可優(yōu)化點

下圖為本次春節(jié)紅包活動在除夕當(dāng)天的數(shù)據(jù)上報請求曲線，實際上報請求峰值為預(yù)估上報請求峰值的13.33%。

 

從曲線可以明顯的發(fā)現(xiàn)，每場答題活動開始時，數(shù)據(jù)上報都有一個尖峰，這是因為客戶端未對數(shù)據(jù)上報進(jìn)行錯峰引起的。這也是本數(shù)據(jù)上報方案的可優(yōu)化點之一，錯峰方式可以簡單的隨機(jī)錯峰上報，亦可參考第二部分內(nèi)容的錯峰方案。

另一個可優(yōu)化的點，我們在觸發(fā)數(shù)據(jù)上報請求時，可以帶上觸發(fā)上報的時機(jī)，這有助于分析用戶觸發(fā)數(shù)據(jù)上報的行為。

七、關(guān)于“資源預(yù)下載”

7.1、概述

春節(jié)紅包活動不僅涉及資源眾多，而且有些資源還比較大。如果這些資源都由客戶端通過實時下載的方式使用，不僅會對CDN帶寬造成巨大的壓力，同時也會對用戶參與活動的體驗造成很大的影響。

自然而然想到最常規(guī)最有效的解決辦法就是資源預(yù)下載。

對于資源預(yù)下載的能力，包括但不限于需要考慮以下幾點：

1）資源能夠正常預(yù)下載到本地；

2）業(yè)務(wù)接入的開發(fā)效率（提供更便捷通用的接口，集成資源判斷、實時下載、資源文件預(yù)處理等邏輯）；

3）考慮資源過大時可能引起的CDN帶寬激增問題（需要制定相應(yīng)的流控方案）；

4）預(yù)下載過程不應(yīng)該影響到其它業(yè)務(wù)（如手Q啟動時的消息加載、其它業(yè)務(wù)資源的實時下載等）；

5）資源管理（下載、更新、刪除、防篡改、淘汰機(jī)制等）；

6）預(yù)下載配置管理（存儲、更新、合并、去重等）；

7）等等...

今年春節(jié)紅包活動，接入使用的是QQ錢包業(yè)務(wù)搭建的資源預(yù)下載系統(tǒng)，此處就不深入詳細(xì)介紹，只針對今年春節(jié)紅包活動在如下幾個方面內(nèi)容做討論。

7.2、預(yù)下載配置問題

預(yù)下載配置為JSON格式，接入手Q配置系統(tǒng)進(jìn)行發(fā)布時，需要填寫一份涉及所有預(yù)下載資源的配置內(nèi)容，如果通過人工理解手寫配置，不僅易出錯而且效率低下，輕則影響客戶端資源的正常預(yù)下載，重則JSON解析處理不當(dāng)可能會導(dǎo)致app產(chǎn)生崩潰，在春節(jié)如此大體量用戶情況下會造成相當(dāng)大的影響。

我們的處理辦法是，由春節(jié)紅包活動的管理平臺根據(jù)預(yù)下載配置的格式，一鍵導(dǎo)出自動生成預(yù)下載配置內(nèi)容，再到配置平臺上發(fā)布。同時，客戶端拉取到預(yù)下載配置時，對所拉取的配置內(nèi)容進(jìn)行 JSON Schema 校驗，確保這是一個正確的配置后才會使用。若檢查發(fā)現(xiàn)配置格式異常，會立刻上報告警通知相關(guān)產(chǎn)品、開發(fā)人員，以及時發(fā)現(xiàn)配置問題并采取措施修復(fù)。

7.3、CDN帶寬預(yù)估

春節(jié)紅包的資源多且大，要覆蓋全網(wǎng)用戶做資源預(yù)下載，需要持續(xù)足夠長一段時間。CDN需提前做好資源分配，以滿足活動資源覆蓋的帶寬需求。 

因此，我們需要對春節(jié)紅包活動的CDN帶寬進(jìn)行預(yù)估：提前多久開始預(yù)下載資源？CDN需要分配多少離線帶寬和在線帶寬？

假設(shè)我們提前D天下發(fā)了預(yù)下載配置。

1）離線帶寬的預(yù)估：

離線帶寬資源的分配，要能滿足所有用戶能夠在D天時間內(nèi)，都能順利預(yù)下載下來所有資源。假設(shè)手Q總用戶數(shù)為N，需要預(yù)下載的離線資源總大小為M千字節(jié)（KB），那么可以估算出所有用戶預(yù)下載所有離線資源的總流量（單位：bit）:

預(yù)下載的總流量 = M * 1024 * 8 * N

也就是說D天時間要下載這么多流量的資源，通過一個估算系數(shù)C，預(yù)估出離線帶寬值（單位：Gbps）：

離線帶寬 = 預(yù)下載的總流量 * C / ( D * 86400 * 1024 * 1024 * 1024 )= ( M * 8 * N ) * C / ( D * 86400 * 1024 * 1024 )

2）在線帶寬的預(yù)估：

在線帶寬資源的分配，取決于活動期間資源實時下載預(yù)估能達(dá)到的峰值。我們針對活動所涉及的所有資源，根據(jù)資源使用入口級別將其分為了4個資源等級，不同級別的資源其請求峰值是不一樣的。

 

根據(jù)各活動入口的預(yù)估峰值，以及演練時的轉(zhuǎn)化率數(shù)據(jù)，得出各級別資源的峰值，另外還需要考慮資源預(yù)下載的影響，從而估算出在線帶寬。

對于每個資源, 假設(shè)其在線資源大小為R千字節(jié)（KB），該資源預(yù)計峰值為PW/s，資源預(yù)下載覆蓋率取90%的話，那么該資源的在線帶寬峰值為（單位：Gpbs）：

在線帶寬 = ( R * 1024 * 8 ) * ( P * 10000 * 0.1 )  / (1024 * 1024 * 1024)

7.4、覆蓋率&命中率

預(yù)下載支持配置網(wǎng)絡(luò)參數(shù)，來控制當(dāng)前資源在什么樣的網(wǎng)絡(luò)環(huán)境下才會去預(yù)下載。春節(jié)紅包總體資源較大，我們配置了所有資源只在Wifi網(wǎng)絡(luò)環(huán)境下才預(yù)下載，防止消耗用戶的手機(jī)流量。因此，我們總體資源的覆蓋率不是太高，因為還有不少占比用戶的聯(lián)網(wǎng)狀態(tài)是非Wifi的。

當(dāng)然，覆蓋率只是衡量預(yù)下載功能的一個指標(biāo)，另一個重要指標(biāo)是資源預(yù)下載的命中率。命中，表示用戶在使用某個資源時，是否命中了本地預(yù)下載的資源。我們在用戶進(jìn)入主活動入口的時機(jī)，增加了資源的命中檢查：如果該用戶進(jìn)入主活動頁面時，預(yù)下載配置中的所有資源都提前預(yù)下載到本地了，即認(rèn)為命中，否則認(rèn)為不命中，以活動當(dāng)天首次進(jìn)入為準(zhǔn)。經(jīng)上報統(tǒng)計，本次春節(jié)紅包的資源預(yù)下載命中率超過90%。

理想的情況下，預(yù)下載要能達(dá)到以較低的覆蓋率獲得較高的命中率的效果最佳，這說明大部分參與活動的用戶基本都覆蓋到了所有資源，是我們的目標(biāo)用戶。因此，對于目標(biāo)用戶比較明確的業(yè)務(wù)，可以通過白名單方式來控制預(yù)下載配置只針對目標(biāo)用戶進(jìn)行下發(fā)。

八、關(guān)于“柔性策略”

春節(jié)紅包活動在手Q消息列表處設(shè)置了吊墜入口，且活動主要是以H5頁面的方式進(jìn)行的，對手Q可能會產(chǎn)生如下三方面的影響。

1）對下拉消息列表刷新消息的影響：

基于用戶對以前手Q春節(jié)紅包的認(rèn)知，在春節(jié)紅包活動開始之前，有些用戶會習(xí)慣性地去下拉消息列表尋找活動入口，另外分會場設(shè)置的呼吸燈也會引導(dǎo)用戶下拉消息列表。這個行為會觸發(fā)拉取離線消息，在活動高峰時給消息后臺帶來額外的壓力。

 

為消除對下拉消息列表刷新消息的影響，我們在每場活動開始時的前后一段時間內(nèi)以及呼吸燈第一次展示后的一段時間內(nèi)，禁止用戶刷新消息，在視覺上仍然有一個假刷新消息的過程，但實際不會觸發(fā)拉取離線消息的請求。通過在配置中添加禁刷開關(guān)和禁刷時間來進(jìn)行控制，可靈活調(diào)整。

這里有個細(xì)節(jié)，我們將活動開始前后的禁刷時間分開控制，防止禁刷時間段過長，降低春節(jié)紅包活動禁刷消息對正常離線消息拉取的影響。

 

2）對url安全檢查的影響：

在手Q中打開一個H5頁面，WebView會對頁面url攔截進(jìn)行url安全檢查，只有通過檢查后才能繼續(xù)加載頁面內(nèi)容。本次春節(jié)紅包活動主要以H5方式進(jìn)行，有較多的url鏈接，如果都進(jìn)行安全檢查的話，在活動高峰會給檢查后臺增加較大的壓力。

 

為消除對檢查后臺的影響，采取的措施是針對所有春節(jié)紅包活動的頁面屏蔽url安全檢查。通過在配置中添加url安全檢查開關(guān)和url前綴列表來進(jìn)行控制，所有活動頁面的url走內(nèi)部域名。另外，屏蔽url安全檢查在一定程度上還可以加快活動頁面的加載速度，弱網(wǎng)環(huán)境下會更加明顯。

3）對離線包更新檢查的影響：

本次春節(jié)紅包活動的大部分頁面均支持離線包，在使用WebView打開支持離線包頁面時，會觸發(fā)離線包的異步更新檢查，在活動高峰期同樣會給離線包后臺增加不小的壓力。

消除該影響的辦法，是在所有支持離線包頁面的url中，增加一個開關(guān)參數(shù)，客戶端判斷若帶有該參數(shù)，則直接屏蔽離線包的更新檢查。

那如果活動期間，前端頁面發(fā)了新版本的離線包，客戶端要怎么更新呢？我們設(shè)計了一套按需更新的方案，大致思路是：在進(jìn)入主活動頁面時，頁面會拉取一份離線包版本配置，并檢查本地離線包版本與配置中指定的版本是否一致，若不一致則觸發(fā)更新檢查，觸發(fā)方式為發(fā)起一個不帶屏蔽開關(guān)參數(shù)的資源請求，請求目標(biāo)對象為一個1字節(jié)的文件或1像素的圖片。

九、寫在最后

2020春節(jié)紅包歷時近4個月，經(jīng)過多次演練、迭代、優(yōu)化，團(tuán)隊所有成員在產(chǎn)品體驗、開發(fā)細(xì)節(jié)、測試場景等方面不斷打磨。

在全程參與這種大型全民運營活動的過程中，感受頗深的是，在設(shè)計或?qū)崿F(xiàn)某個看似簡單的功能時，一定要多系統(tǒng)性地思考，盡量做到有依有據(jù)，考慮到各方各面。遇到哪怕看似再小的問題時，也要重視，尋其根因。

（—— 全文完 ——）

附錄：有關(guān)微信、QQ的技術(shù)文章匯總

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

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

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

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

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

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

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

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

《微信團(tuán)隊原創(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ù)演進(jìn)之路》

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

《騰訊原創(chuàng)分享(一)：如何大幅提升移動網(wǎng)絡(luò)下手機(jī)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庫：單機(jī)千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]》 

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

《微信團(tuán)隊原創(chuàng)分享：Android版微信后臺?；顚崙?zhàn)分享(進(jìn)程保活篇)》 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

《微信團(tuán)隊原創(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版微信的智能心跳機(jī)制》 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

《QQ設(shè)計團(tuán)隊分享：新版 QQ 8.0 語音消息改版背后的功能設(shè)計思路》

《微信團(tuán)隊分享：極致優(yōu)化，iOS版微信編譯速度3倍提升的實踐總結(jié)》

《IM“掃一掃”功能很好做？看看微信“掃一掃識物”的完整技術(shù)實現(xiàn)》

《微信團(tuán)隊分享：微信支付代碼重構(gòu)帶來的移動端軟件架構(gòu)上的思考》

>> 更多同類文章 ……

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