2020春节红包“鼓力全开”已顺利闭幕，本文针对今年腾讯QQ春节红包客户端在活动配置、错峰、数据上报、资源预下载和柔性策略五个方面进行探讨和总结，希望能和大家在后续春节红包项目上一起学习交流。

2020腾讯QQ春节红包主要以答题的玩法，结合中国传统文化（成语、诗词、对联、历史等）的方式进行，达到寓教于乐的效果。

对于这种大体量的运营活动，除了前端、后台的大力支撑，客户端又是从哪些方面来保证整个活动的灵活性、稳定性和用户体验的呢？

• 配置 —— 通过配置控制众多可变参数，灵活应对活动变化
• 错峰 —— 解决活动高峰后台服务负载过高的问题，新错峰方案提升用户感知体验
• 数据上报 —— 即保证活动数据的及时上报，又避免过度消耗资源
• 资源预下载 —— 解决活动高峰CDN带宽压力过高问题的同时，提升用户体验
• 柔性策略 —— 确保活动不会对其它业务产生太大影响

一、配置

整个春节红包活动是通过全局配置进行控制的，可动态修改，以灵活应对活动的变更。根据产品需求，结合需求变更的可能性，以及通用能力的可复用性，本次春节红包总共定义了四份配置：

1. 入口配置

包含活动入口吊坠、小程序入口Banner和一些控制开关等配置内容。春节红包活动横跨小年、除夕、大年初一，每天有4场答题活动，有些场次为商家专场，因此入口配置中提前以列表形式定义好了各天各场次的具体活动信息。

2. 大插屏配置

包含活动预热大插屏的配置内容，由于刚开始时需求的不确定性，独立出来作为一份配置，后来还增加了分会场呼吸灯的配置内容。

3. 错峰配置

包含本次春节红包活动客户端错峰方案的配置内容，独立配置，可供手Q其它通用运营业务复用。

4. 预下载配置

包含春节红包活动客户端需要提前预下载的资源配置内容，本次活动资源预覆盖接入使用了QQ钱包业务搭建的资源预下载系统，因此配置参照了QQ钱包预下载系统制定的格式。

二、错峰

错峰，目的是为了解决春节红包活动高峰对抽奖后台负载带来瞬间冲击的问题。 以往春节红包活动的错峰方案，主要有两种：

1. 通过客户端缓冲过程，控制对抽奖后台的请求

通过控制参与抽奖的频率、限制抽奖的次数等方式来进行错峰，如摇一摇、刷一刷等。

2. 通过对活动入口随机时间错峰显示，控制对抽奖后台的请求

将所有用户随机均匀地映射到活动开始后的一段时间区间内，使用户错峰显示入口进入参与活动，如2019年春节的福袋。错峰时间的算法形如：hash(uin) % gap。

3. 我们的错峰方案

上述两种错峰方式，第二种与本次春节红包活动场景是比较吻合的。不过，该方案存在一个问题：由于其随机性，使得有用户反馈身边其他人都能看到活动入口参与抽奖了，而自己却一直看不到入口。针对方案二的问题，我们引入了 用户地理位置 的因素进行改进，下图描述了总体错峰方案：

具体方案实现流程如下：

首先，我们定义了一份 错峰配置 ，包含 错峰时间间隔 和 区域划分列表 ，将全国用户根据地理位置adcode划分为多个区域批次。对处于同一批次的用户，他们看到活动入口的时间段是一样的。假设配置活动的开始时间为9:00，错峰时间间隔为1分钟，那么第一批用户能看到入口的时间为9:00~9:01，第二批用户能看到入口的时间为9:01~9:02，以此类推。主要流程如下：

1. 根据用户地理位置adcode和错峰配置进行映射，得到映射后的分区索引i；
2. 计算得到 一次错峰时间：T1 = T0 + i*interval ；
3. 对于同一批次的用户，通过随机时间，将这些用户随机均匀地映射分布到对应较小的时间段内，计算得到 二次错峰时间：T2 = T1 + hash(uin)%interval ；
4. 得到的二次错峰时间T2即为用户 实际可以看到入口参与活动的时间：T = T2 ；
5. 对于地理位置一次错峰可能出现的异常情况，如用户未授权获取地理位置（占比30%左右）、国外用户无adcode未匹配到分区索引等，客户端可采取一定的 兜底策略 ，如根据用户账号uin进行随机映射到某个分区：i = hash(uin) % regions.count 。

该错峰方案实现时抽离了业务依赖，并走独立配置，可供其它通用性运营业务复用。同时，该错峰方案还申请了专利。

三、数据上报

1. 意义

春节红包的数据，不仅是衡量活动运营的质量指标，还会影响到活动的招商。通过对数据进行监控，产品同学可以根据实际活动情况调整产品策略，开发同学可以及时发现并定位问题。同时，数据还是申请活动资源的重要依据。

2. 核心诉求

春节红包这种大型全民活动的数据，主要具有 上报数据量大 、 上报并发高 、 上报场景多样 的特点。对于春节红包数据上报，主要有三方面的核心诉求：

• 数据能够及时上报 （实时性需求）
• 避免为及时上报而导致资源的过度消耗 （如客户端性能、网络开销；后台性能、扩容资源等）
• 确保上报服务的稳定可用 （要有可调整和容错的能力）

3. 为何不使用现有的数据上报

为什么不直接使用手Q现有的数据上报系统呢？主要是基于如下几方面的考虑：

• 可能影响其它长期运营的正常业务
• 定制化成本高（上报后台需要做一些秒级监控、UV统计等定制逻辑）
• 上报控制不够灵活、生效慢（通过配置控制上报逻辑，调整后配置覆盖需要一定时间才能全部生效）
• 人力、沟通成本等其它方面的考虑

4. 春节红包数据上报

针对春节红包数据的特点及核心诉求，我们设计了本次春节红包数据上报方案。 （1）数据上报架构：

• 调用层 封装了各上报场景的通用上报能力，通过 接口层 的统一上报接口将上报数据转发给逻辑层进行处理。Native、H5均通过原生统一上报接口走SSO通道上报，上报更可靠且无需重复开发；
• 逻辑层 主要包括数据预处理、数据上报策略和容错机制三部分内容。其中， 数据预处理 负责对上报的数据进行聚合、过滤和转换； 数据上报策略 通过后台可控的参数来控制数据上报的时机、频率、大小和存储，确保数据能够及时上报又不影响客户端和后台的性能，而且能够实时动态调整； 容错机制 制定了过载策略和降级策略，提供应对上报后台过载的措施；
• 基础层 即系统和手Q封装提供的一些基础能力，如文件I/O、安全加/解密等。

（2）数据上报的实现流程：

• 客户端通过一个串行队列来处理所有上报的数据，对数据首先会进行聚合、过滤和转换的预处理，然后将预处理的数据先写到内存缓存中，当满足保存文件的时机时，再异步写到磁盘文件中；
• 为避免频繁写文件对CPU、磁盘等带来的影响，客户端每隔一段时间写一次文件；为防止内存中数据丢失，客户端在前后台切换、杀进程、app crash场景下也会保存文件进行补偿；
• 当满足上报时机时，会触发数据上报请求，并清空缓存数据同时保存文件；
• 上报请求回包中带有上报控制相关信息，提供了灵活调整的能力。

5. 遇到的问题分析与解决

（1）相同埋点数据增大请求包大小

春节红包的数据中，有多类埋点数据触发多次的情况（如曝光、点击等），因此一个上报请求包中可能会存在多条相同的埋点数据，增大了请求包大小。通过对请求包中的数据进行 二次聚合 （批量上报其实是对上报请求做了一次聚合），经测试平均可减小 请求包大小28% 。

另外，针对特定的需求场景，有些数据可能是不能聚合的。例如，我们对于操作时间超过1小时的相同数据是不会进行聚合处理的，因为今年春节活动有场次的概念，每场活动间隔1个小时，产品同学可能需要以场次维度统计相关数据，若合并可能会干扰数据统计的准确性。

（2）上报请求次数过多

前期演练监控上报请求发现，一场答题活动结束后，客户端上报的请求次数比预估中的偏多，与抽奖请求的比例超过了2:1（预估上报请求峰值与抽奖请求峰值的比例大约为5:4）。假如抽奖请求到达到了峰值，那可能上报请求的峰值会更高，需要上报后台扩容更多的机器。

我们针对上报请求的top用户日志进行分析，发现主要有两方面原因：

• 用户频繁前后台切换触发多次上报请求：初始前后台切换上报的频控时间设置了10s比较短，可能导致用户多次触发只有几条数据的请求；
• 一些关键指标数据（如覆盖数据）最开始走的是实时上报，会有多个只有一条数据的上报请求。

针对这两个原因，我们采取了相应的措施：

• 调整前后台切换触发上报的时间间隔 ，将秒级改为分钟级，后台可控；
• 关键指标数据改为批量上报 ，并通过每日一检的方式增加触发时机。

解决之后上报请求数小于抽奖请求数，比例降到了1.0以下。经测试平均单用户 上报请求数降低了71.4% 。

（3）关键指标数据不准确

针对前期的几次演练，我们统计了配置、资源的覆盖率，发现所得到的结果与预想中的有些出入。我们所使用的配置系统是在登录级别拉取的，下发成功率高于95%，而演练时统计上报数据配置的覆盖率范围在80~88%之间，怀疑可能覆盖上报的数据丢失了。

我们针对部分有活跃（前台登录）但却没有覆盖上报的用户进行了分析，发现这些用户确实是拉取到配置并触发了覆盖上报，但上报的数据可能丢失了。一方面可能是在内存的数据未及时同步到文件中，因为初始设置写文件的频率为每30秒写一次，时间略长，用户杀进程或退后台等操作场景下，内存中的数据可能会丢失；另一方面也可能是网络原因导致上报数据的丢失。针对这两个原因，我们采取的对应措施：

• 缩短保存文件的时间间隔 （对多个值测试综合性能和时间效率考虑取值10秒），后台可控，并进行 多时机补偿 ，包括前后台切换、杀进程和App Crash三种场景。经测试，对比每次都写文件，每10秒写一次文件能够 降低对CPU影响66.7%，降低对磁盘的影响87.9% 。

• 确保关键指标数据上报成功，并过滤冗余数据 。把覆盖类指标每日一检的方式改为每次登录/断网重连时就触发覆盖检查，并加上一定的频控，覆盖检查得出结果后即上报。当覆盖数据实际触发上报到后台并成功回包后，本地记录上报的状态，这样当下次触发覆盖检查上报前，若判断该覆盖数据已上报过，就不再上报，直接作为冗余数据过滤掉。相比每日一检的方式（每天都会产生多条覆盖数据上报），这种方式单用户 最多可以节省93%的覆盖数据量 。

解决后，之后演练的覆盖类数据恢复了正常，配置覆盖率在97%~99%之间。

6. 容错机制

下图为上报数据的流通流程：

在客户端数据上报到后台的链路中，SSO接入层和上报服务后台均有过载的风险。针对这两个风险，我们分别用过载策略和降级策略来应对。

（1）SSO接入层过载

如果SSO接入层过载了，所采用的的 过载策略 是：由SSO接入层直接回包，客户端根据过载标记，将批量上报的batchSize值设置为最大值，并翻倍上报的频率时间，从而降低客户端的上报频率。

（2）上报服务后台过载

针对上报服务后台过载的情况，我们制定了一套 降级策略 ，后台回包中包含了两个降级信息：

• reportLevel ：上报级别，默认为0
• reportLevelTime ：上报级别有效时间，当reportLevel>0时有效

我们设定了4个上报级别，如下图所示，客户端根据后台设置的上报级别，来降级上报服务。如果上报级别设置为1，则客户端会将所有实时上报降级为批量上报；更进一步的，可以设置上报级别为2来降级屏蔽非用户行为类的数据上报；甚至可以设置上报级别为3来屏蔽所有数据的上报。通过上报级别有效时间，来确保客户端能够恢复正常的上报逻辑。

7. 可优化点

下图为本次春节红包活动在除夕当天的数据上报请求曲线，实际上报请求峰值为预估上报请求峰值的13.33%。

从曲线可以明显的发现，每场答题活动开始时，数据上报都有一个尖峰，这是因为客户端未 对数据上报进行错峰 引起的。这也是本数据上报方案的可优化点之一，错峰方式可以简单的随机错峰上报，亦可参考第二部分内容的错峰方案。另一个可优化的点，我们在触发数据上报请求时，可以 带上触发上报的时机 ，这有助于分析用户触发数据上报的行为。

四、资源预下载

春节红包活动不仅涉及资源众多，而且有些资源还比较大。如果这些资源都由客户端通过实时下载的方式使用，不仅会对CDN带宽造成巨大的压力，同时也会对用户参与活动的体验造成很大的影响。自然而然想到最常规最有效的解决办法就是资源预下载。对于资源预下载的能力，包括但不限于需要考虑以下几点：

• 资源能够正常预下载到本地
• 业务接入的开发效率 （提供更便捷通用的接口，集成资源判断、实时下载、资源文件预处理等逻辑）
• 考虑资源过大时可能引起的CDN带宽激增问题 （需要制定相应的流控方案）
• 预下载过程不应该影响到其它业务 （如手Q启动时的消息加载、其它业务资源的实时下载等）
• 资源管理 （下载、更新、删除、防篡改、淘汰机制等）
• 预下载配置管理 （存储、更新、合并、去重等）
• 等等...

今年春节红包活动，接入使用的是QQ钱包业务搭建的资源预下载系统，此处就不深入详细介绍，只针对今年春节红包活动在如下几个方面内容做讨论。

1. 预下载配置问题

预下载配置为JSON格式，接入手Q配置系统进行发布时，需要填写一份涉及所有预下载资源的配置内容，如果通过人工理解手写配置，不仅易出错而且效率低下，轻则影响客户端资源的正常预下载，重则JSON解析处理不当可能会导致app产生崩溃，在春节如此大体量用户情况下会造成相当大的影响。我们的处理办法是，由春节红包活动的管理平台根据预下载配置的格式，一键导出自动生成预下载配置内容，再到配置平台上发布。同时，客户端拉取到预下载配置时，对所拉取的配置内容进行 JSON Schema 校验，确保这是一个正确的配置后才会使用。若检查发现配置格式异常，会立刻上报告警通知相关产品、开发人员，以及时发现配置问题并采取措施修复。

2. CDN带宽预估

春节红包的资源多且大，要覆盖全网用户做资源预下载，需要持续足够长一段时间。CDN需提前做好资源分配，以满足活动资源覆盖的带宽需求。 因此，我们需要对春节红包活动的CDN带宽进行预估：提前多久开始预下载资源？CDN需要分配多少离线带宽和在线带宽？假设我们提前D天下发了预下载配置：