一、引言
2020年春节早已过去两月有余，回顾本次腾讯手Q春节红包活动的玩法，主要以答题形式结合中国传统文化（成语、诗词、对联、历史等）的方式进行，达到寓教于乐的效果。
（本文同步发布于：http://www.52im.net/thread-2966-1-1.html）
二、内容概述
本文将回顾今年的春节红包活动中，针对手Q客户端在活动配置、错峰、数据上报、资源预下载和柔性策略五个方面进行探讨和总结，希望能和大家在后续春节红包项目上一起学习交流。
具体来说，这些技术手段主要是以下几个方面的内容：
1）配置：通过配置控制众多可变参数，灵活应对活动变化
2）错峰：解决活动高峰后台服务负载过高的问题，新错峰方案提升用户感知体验
3）数据上报：即保证活动数据的及时上报，又避免过度消耗资源
4）资源预下载：解决活动高峰CDN带宽压力过高问题的同时，提升用户体验；
5）柔性策略：确保活动不会对其它业务产生太大影响。
三、系列文章
系列文章目录：
《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》
《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》
《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》
《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》
《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
《社交软件红包技术解密(七)：支付宝红包的海量高并发技术实践》
《社交软件红包技术解密(八)：全面解密微博红包技术方案》
《社交软件红包技术解密(九)：谈谈手Q春节红包的设计、容灾、运维、架构等》
《社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践》（* 本文）
其它相关文章：
《技术往事：“QQ群”和“微信红包”是怎么来的
《QQ 18年：解密8亿月活的QQ后台服务接口隔离技术》
《微信“红包照片”背后的技术难题》
四、关于“配置”
整个春节红包活动是通过全局配置进行控制的，可动态修改，以灵活应对活动的变更。根据产品需求，结合需求变更的可能性，以及通用能力的可复用性，本次春节红包总共定义了四份配置。
1）入口配置：
包含活动入口吊坠、小程序入口Banner和一些控制开关等配置内容。春节红包活动横跨小年、除夕、大年初一，每天有4场答题活动，有些场次为商家专场，因此入口配置中提前以列表形式定义好了各天各场次的具体活动信息。
3）错峰配置：
包含本次春节红包活动客户端错峰方案的配置内容，独立配置，可供手Q其它通用运营业务复用。
4）预下载配置：
包含春节红包活动客户端需要提前预下载的资源配置内容，本次活动资源预覆盖接入使用了QQ钱包业务搭建的资源预下载系统，因此配置参照了QQ钱包预下载系统制定的格式。
五、关于“错峰”
5.1、以往春节红包活动的错峰方案
错峰，目的是为了解决春节红包活动高峰对抽奖后台负载带来瞬间冲击的问题。以往春节红包活动的错峰方案，主要有以下两种。
1）通过客户端缓冲过程，控制对抽奖后台的请求：
通过控制参与抽奖的频率、限制抽奖的次数等方式来进行错峰，如摇一摇、刷一刷等。
5.2、我们使用的错峰方案
上节提到的两种错峰方式，第二种与本次春节红包活动场景是比较吻合的。
不过，该方案存在一个问题：由于其随机性，使得有用户反馈身边其他人都能看到活动入口参与抽奖了，而自己却一直看不到入口。
针对方案二的问题，我们引入了用户地理位置的因素进行改进，下图描述了总体错峰方案：
首先，我们定义了一份错峰配置，包含错峰时间间隔和区域划分列表，将全国用户根据地理位置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）调用层：封装了各上报场景的通用上报能力，通过接口层的统一上报接口将上报数据转发给逻辑层进行处理。Native、H5均通过原生统一上报接口走SSO通道上报，上报更可靠且无需重复开发；
2）逻辑层：主要包括数据预处理、数据上报策略和容错机制三部分内容。其中，数据预处理负责对上报的数据进行聚合、过滤和转换；数据上报策略通过后台可控的参数来控制数据上报的时机、频率、大小和存储，确保数据能够及时上报又不影响客户端和后台的性能，而且能够实时动态调整；容错机制制定了过载策略和降级策略，提供应对上报后台过载的措施；
3）基础层：即系统和手Q封装提供的一些基础能力，如文件I/O、安全加/解密等。
6.4.2 数据上报的实现流程
6.5.2 上报请求次数过多
前期演练监控上报请求发现，一场答题活动结束后，客户端上报的请求次数比预估中的偏多，与抽奖请求的比例超过了2:1（预估上报请求峰值与抽奖请求峰值的比例大约为5:4）。假如抽奖请求到达到了峰值，那可能上报请求的峰值会更高，需要上报后台扩容更多的机器。
2）确保关键指标数据上报成功，并过滤冗余数据：把覆盖类指标每日一检的方式改为每次登录/断网重连时就触发覆盖检查，并加上一定的频控，覆盖检查得出结果后即上报。当覆盖数据实际触发上报到后台并成功回包后，本地记录上报的状态，这样当下次触发覆盖检查上报前，若判断该覆盖数据已上报过，就不再上报，直接作为冗余数据过滤掉。相比每日一检的方式（每天都会产生多条覆盖数据上报），这种方式单用户最多可以节省93%的覆盖数据量。
在客户端数据上报到后台的链路中，SSO接入层和上报服务后台均有过载的风险。针对这两个风险，我们分别用过载策略和降级策略来应对。
1）SSO接入层过载：如果SSO接入层过载了，所采用的的过载策略是：由SSO接入层直接回包，客户端根据过载标记，将批量上报的batchSize值设置为最大值，并翻倍上报的频率时间，从而降低客户端的上报频率。
2）上报服务后台过载：针对上报服务后台过载的情况，我们制定了一套降级策略，后台回包中包含了两个降级信息：
reportLevel：上报级别，默认为0
reportLevelTime：上报级别有效时间，当reportLevel>0时有效
我们设定了4个上报级别，如下图所示，客户端根据后台设置的上报级别，来降级上报服务。如果上报级别设置为1，则客户端会将所有实时上报降级为批量上报；更进一步的，可以设置上报级别为2来降级屏蔽非用户行为类的数据上报；甚至可以设置上报级别为3来屏蔽所有数据的上报。通过上报级别有效时间，来确保客户端能够恢复正常的上报逻辑。
从曲线可以明显的发现，每场答题活动开始时，数据上报都有一个尖峰，这是因为客户端未对数据上报进行错峰引起的。这也是本数据上报方案的可优化点之一，错峰方式可以简单的随机错峰上报，亦可参考第二部分内容的错峰方案。
另一个可优化的点，我们在触发数据上报请求时，可以带上触发上报的时机，这有助于分析用户触发数据上报的行为。
七、关于“资源预下载”
7.1、概述
春节红包活动不仅涉及资源众多，而且有些资源还比较大。如果这些资源都由客户端通过实时下载的方式使用，不仅会对CDN带宽造成巨大的压力，同时也会对用户参与活动的体验造成很大的影响。
自然而然想到最常规最有效的解决办法就是资源预下载。
对于资源预下载的能力，包括但不限于需要考虑以下几点：
1）资源能够正常预下载到本地；
2）业务接入的开发效率（提供更便捷通用的接口，集成资源判断、实时下载、资源文件预处理等逻辑）；
3）考虑资源过大时可能引起的CDN带宽激增问题（需要制定相应的流控方案）；
4）预下载过程不应该影响到其它业务（如手Q启动时的消息加载、其它业务资源的实时下载等）；
5）资源管理（下载、更新、删除、防篡改、淘汰机制等）；
6）预下载配置管理（存储、更新、合并、去重等）；
7）等等…
今年春节红包活动，接入使用的是QQ钱包业务搭建的资源预下载系统，此处就不深入详细介绍，只针对今年春节红包活动在如下几个方面内容做讨论。
7.2、预下载配置问题
预下载配置为JSON格式，接入手Q配置系统进行发布时，需要填写一份涉及所有预下载资源的配置内容，如果通过人工理解手写配置，不仅易出错而且效率低下，轻则影响客户端资源的正常预下载，重则JSON解析处理不当可能会导致app产生崩溃，在春节如此大体量用户情况下会造成相当大的影响。
我们的处理办法是，由春节红包活动的管理平台根据预下载配置的格式，一键导出自动生成预下载配置内容，再到配置平台上发布。同时，客户端拉取到预下载配置时，对所拉取的配置内容进行 JSON Schema 校验，确保这是一个正确的配置后才会使用。若检查发现配置格式异常，会立刻上报告警通知相关产品、开发人员，以及时发现配置问题并采取措施修复。
7.3、CDN带宽预估
春节红包的资源多且大，要覆盖全网用户做资源预下载，需要持续足够长一段时间。CDN需提前做好资源分配，以满足活动资源覆盖的带宽需求。
因此，我们需要对春节红包活动的CDN带宽进行预估：提前多久开始预下载资源DN需要分配多少离线带宽和在线带宽/p>
假设我们提前D天下发了预下载配置。
1）离线带宽的预估：
离线带宽资源的分配，要能满足所有用户能够在D天时间内，都能顺利预下载下来所有资源。假设手Q总用户数为N，需要预下载的离线资源总大小为M千字节（KB），那么可以估算出所有用户预下载所有离线资源的总流量（单位：bit）:
预下载的总流量 = M * 1024 * 8 * N
也就是说D天时间要下载这么多流量的资源，通过一个估算系数C，预估出离线带宽值（单位：Gbps）：
离线带宽 = 预下载的总流量 * C / ( D * 86400 * 1024 * 1024 * 1024 )= ( M * 8 * N ) * C / ( D * 86400 * 1024 * 1024 )
2）在线带宽的预估：
在线带宽资源的分配，取决于活动期间资源实时下载预估能达到的峰值。我们针对活动所涉及的所有资源，根据资源使用入口级别将其分为了4个资源等级，不同级别的资源其请求峰值是不一样的。
为消除对下拉消息列表刷新消息的影响，我们在每场活动开始时的前后一段时间内以及呼吸灯第一次展示后的一段时间内，禁止用户刷新消息，在视觉上仍然有一个假刷新消息的过程，但实际不会触发拉取离线消息的请求。通过在配置中添加禁刷开关和禁刷时间来进行控制，可灵活调整。
这里有个细节，我们将活动开始前后的禁刷时间分开控制，防止禁刷时间段过长，降低春节红包活动禁刷消息对正常离线消息拉取的影响。
为消除对检查后台的影响，采取的措施是针对所有春节红包活动的页面屏蔽url安全检查。通过在配置中添加url安全检查开关和url前缀列表来进行控制，所有活动页面的url走内部域名。另外，屏蔽url安全检查在一定程度上还可以加快活动页面的加载速度，弱网环境下会更加明显。
3）对离线包更新检查的影响：
本次春节红包活动的大部分页面均支持离线包，在使用WebView打开支持离线包页面时，会触发离线包的异步更新检查，在活动高峰期同样会给离线包后台增加不小的压力。
消除该影响的办法，是在所有支持离线包页面的url中，增加一个开关参数，客户端判断若带有该参数，则直接屏蔽离线包的更新检查。
那如果活动期间，前端页面发了新版本的离线包，客户端要怎么更新呢们设计了一套按需更新的方案，大致思路是：在进入主活动页面时，页面会拉取一份离线包版本配置，并检查本地离线包版本与配置中指定的版本是否一致，若不一致则触发更新检查，触发方式为发起一个不带屏蔽开关参数的资源请求，请求目标对象为一个1字节的文件或1像素的图片。
九、写在最后
2020春节红包历时近4个月，经过多次演练、迭代、优化，团队所有成员在产品体验、开发细节、测试场景等方面不断打磨。
在全程参与这种大型全民运营活动的过程中，感受颇深的是，在设计或实现某个看似简单的功能时，一定要多系统性地思考，尽量做到有依有据，考虑到各方各面。遇到哪怕看似再小的问题时，也要重视，寻其根因。
（—— 全文完 ——）
附录：有关微信、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设计团队分享：新版 QQ 8.0 语音消息改版背后的功能设计思路》
《微信团队分享：极致优化，iOS版微信编译速度3倍提升的实践总结》
《IM“扫一扫”功能很好做看微信“扫一扫识物”的完整技术实现》
《微信团队分享：微信支付代码重构带来的移动端软件架构上的思考》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-2966-1-1.html）
来源：hellojackjiang2011
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！