im即时通讯-社交软件红包技术解密(10):2020年春节红包手q客户端技术实践

 一、导言

 

 自2020年春节以来,已经过去了两个多月。回顾腾讯q春节红包活动的玩法,主要是以问答的形式结合中国传统文化(成语、诗词、对联、历史等)进行。),从而达到寓教于乐的效果。

 

 _1.jpg

 ▲2020年春节QQ红包活动

 

 对于如此大量的即时通讯社交应用操作活动,除了前台和后台的大力支持之外,还有哪些方面可以保证Q客户端整个红包活动的灵活性、稳定性和用户体验?有了这个问题,让我们一起读课文的其余部分。

 

 二、内容概述

 

 本文将回顾今年的春节红包活动,从活动配置、高峰转移、数据上报、资源预下载、Q客户灵活策略五个方面进行讨论和总结,希望在后续的春节红包项目中与大家学习和交流。

 

 具体来说,这些技术手段主要包括以下几个方面:

 

 

 1)配置:许多可变参数由配置控制,以灵活地响应活动变化

 2)峰移:解决高峰活动时后台服务负荷高的问题,新的峰移方案改善了用户的感知体验

 3)数据报告:确保及时报告活动数据,避免过度消耗资源

 4)资源预下载:改善用户体验,同时解决活动高峰期CDN带宽压力大的问题;

 5)灵活策略:确保活动不会对其他业务产生太大影响。

 第三,一系列文章

 

 系列文章目录:

 

 

 社交软件红包解密技术(一):全面解密QQ红包的技术方案——架构、技术实现等。

 社交软件红包解密技术(二):微信解密摇号红包技术从0到1的演进

 “社交软件红包技术解密(三):微信抖红包雨背后的技术细节”

 社交软件红包技术解密(4):微信红包系统如何应对高并发

 社交软件红包解密技术(五):如何实现微信红包系统的高可用性

 社交软件红包解密技术(六)——微信红包系统存储层架构的演进实践

 社交软件红包解密技术(七):支付宝红包海量高并发技术实践

 社交软件红包解密技术(八):全面解密微博红包的技术方案

 社交软件红包解密技术(九):谈设计、容灾、运维、架构等。手问春节红包

 " "(*本文)

 

 其他相关文章:

 

 

 技术的过去:“QQ群”和“微信红包”是怎么来的?》

 QQ 18年:解密8亿个月前的QQ后台服务接口隔离技术

 微信“红包照片”背后的技术问题

 第四,关于“配置”

 

 整个春节红包活动由全局配置控制,全局配置可以动态修改,以灵活应对活动的变化。根据产品需求,结合需求变化的可能性和通用功能的可重用性,为这个春节红包定义了四种配置。

 

 1)入口配置:

 

 包括可移动入口挂件,小程序入口横幅和一些控制开关。春节红包活动跨越除夕夜、除夕夜和元旦,每天有4次答疑活动,其中一些是商家的特别活动。因此,每天每个事件的具体活动信息在入口配置中预先以列表的形式定义。

 

 _2.jpg

 

 2)大屏幕插入配置:

 

 它包含活动预热大屏幕插入的配置内容。由于一开始需求的不确定性,它作为一个配置单独存在,后来又增加了分会场呼吸灯的配置内容。

 

 _3.jpg

 

 3)峰值偏移配置:

 

 它包含了春节红包活动客户移峰填谷方案的配置内容,可以独立配置,也可以被其他常规操作重用。

 

 4)预下载配置:

 

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

 

 V.关于“错峰”

 

 

 5.1。以往春节红包活动的移峰填谷方案

 

 移峰填谷的目的是为了解决春节期间红包活动的高峰期给彩票的背景负荷带来即时冲击的问题。过去,春节红包活动的高峰期有两个方案。

 

 1)通过客户端缓冲进程,控制对彩票后台的请求:

 

 通过控制参加抽奖的频率、限制抽奖的次数等。,峰是交错的,如摇动和刷动。

 _4.png

 

 2)通过显示活动入口的随机时间峰值偏移来控制对彩票背景的请求;

 

 所有用户随机平均映射到活动开始后的一段时间,这样用户可以在错误的高峰展示入口进入参与活动,如2019年春节的祝福包。峰值偏移时间的算法形式是散列(uin)%间隙。

 _5.png

 

 5.2。我们使用的峰值偏移方案

 

 上一节提到的两种移峰填谷的方式,第二种与春节红包活动场景十分吻合。

 

 然而,这个方案有一个问题:由于它的随机性,我们周围的其他人可以看到参与抽奖的活动入口,但他们不能一直看到入口。

 

 为了解决方案2的问题,我们引入了用户的地理位置来改进它。下图描述了整体峰值偏移方案:

 _6.jpg

 

 具体方案的实施过程如下:

 _7.png

 

 首先,我们定义了一个移峰配置,包括一系列移峰时间间隔和区域划分,并根据地理位置和代码将全国用户划分为多个区域批次。

 

 对于同一批中的用户,他们可以看到同一时间段的活动门户。假设配置活动的开始时间是9: 00,峰值偏移的时间间隔是1分钟,第一组用户可以在9:00到9: 01看到入口,第二组用户可以在9: 01到9: 02看到入口,依此类推。

 

 主要过程如下:

 

 

 1)根据用户地理位置adcode和移峰配置进行映射,得到映射后的分区索引I;

 2)计算一次峰移时间:T1 = T0+I *间隔;;

 3)对于同一批中的用户,通过随机时间将这些用户随机均匀地映射分布到相应的较小时间段,次峰移时间按T2 = t1+哈希(uin)%区间计算;

 4)获得的二次峰移时间T2是用户能够实际看到参与活动的入口的时间:T = T2;;

 5)对于地理位置一次达到峰值时可能出现的异常情况,如用户未被授权获取地理位置(约占30%),外来用户没有广告码且与分区索引不匹配,客户端可以采取一定的策略,如根据用户帐户uin: i =哈希(uin)%区域随机映射到分区

 

 当峰移方案被实现时,它脱离了服务依赖,独立配置,可以被其他通用操作服务重用。

 

 同时,峰移方案也申请了专利。以下是专利信息:

 _xxxx.png

 

 六.关于“数据报告”

 

 

 6.1。意义

 

 春节红包数据不仅是衡量活动质量的一个指标,也影响着活动的投资。通过监控数据,产品学生可以根据实际活动调整产品策略,开发学生可以及时发现和定位问题。同时,数据也是申请活动资源的重要依据。

 

 6.2。核心呼吁

 

 大型全国性活动春节红包的数据主要具有上报数据量大、上报并发性高、上报场景多样的特点。

 

 对于春节红包数据报表,主要有三个核心需求:

 

 

 1)数据可以及时报告(实时要求);

 2)避免因及时报告而导致的资源过度消耗(如客户端性能和网络开销);后台性能、扩展资源等。);

 3)确保稳定可用的报告服务(具有可调和容错能力)。

 

 

 6.3。为什么不使用现有数据进行报告

 

 为什么不直接使用Q现有的数据报告系统?

 

 主要基于以下考虑:

 

 

 (一)可能影响其他长期经营的正常业务;

 2)定制成本高(二级监控、紫外线统计等一些定制逻辑需要在后台完成);

 3)报告控制不够灵活,生效缓慢(通过配置报告逻辑,调整后的配置覆盖需要一定时间才能生效);

 4)考虑人力、通讯成本等方面。

 

 

 6.4、春节红包数据上报

 

 根据春节红包数据的特点和核心需求,设计了春节红包数据上报方案。

 

 

 6.4.1数据报告架构

 

 _8.png

 

 如上图所示:

 

 

 1)调用层:封装了每个报告场景的通用报告功能,通过接口层的统一报告接口将报告数据转发给逻辑层进行处理。本地和H5通过本地统一报告接口通过单点登录渠道报告,这更可靠,不需要重复开发;

 2)逻辑层:主要包括三个部分:数据预处理、数据报告策略和容错机制。其中,数据预处理负责汇总、过滤和转换上报的数据;数据报告策略通过后台可控参数控制数据报告的时间、频率、大小和存储,确保数据能够在不影响客户端和后台性能的情况下及时报告,并能够实时动态调整;容错机制制定过载策略和降级策略,并提供在报告背景下处理过载的措施;

 3)基础层:系统和手工封装提供的一些基本功能,如文件输入/输出、安全加密/解密等。

 

 

 6.4.2数据报告的实施过程

 

 _9.png

 

 如上图所示:

 

 

 1)客户端通过串行队列处理所有上报的数据,并通过聚合、过滤和转换对数据进行预处理,然后将预处理后的数据先写入内存缓存,当满足文件保存时间时,再异步写入磁盘文件;

 2)为了避免频繁的文件写入对中央处理器、磁盘等的影响。,客户端定期写入文件;为了防止内存中的数据丢失,客户端还会保存文件,以便在前台和后台切换、进程终止和应用崩溃的情况下进行补偿;

 3)当满足上报时机时,触发数据上报请求,清空缓存数据并保存文件;

 4)报表请求回复包包含报表控制相关信息,提供灵活调整的能力。

 

 

 6.5。遇到问题的分析和解决

 

 

 6.5.1使用相同的隐藏点数据增加请求数据包的大小

 

 在春节红包的数据中,隐藏着多种数据触发器(如曝光、点击等)。),因此在一个报告请求包中可能有许多相同的隐藏数据,这增加了请求包的大小。通过对请求包中的数据进行二次聚合(事实上,批处理报告是提交请求的一次聚合),测试结果表明请求包的大小平均可以减少28%。

 

 此外,对于特定的需求场景,某些数据可能无法聚合。例如,我们不会将运行时间超过一个小时的相同数据聚合在一起,因为今年的春节活动有会话的概念,每个事件间隔一个小时。产品学生可能需要计算会话维度中的相关数据,这可能会影响数据统计的准确性。

 

 _10.png

 

 

 6.5.2提交的请求过多

 

 在前一个练习中,监控和报告请求发现,在回答活动之后,客户报告的请求数超过了估计数,请求与彩票请求的比率超过了2:1(估计峰值报告请求与峰值彩票请求的比率约为5:4)。如果彩票请求达到峰值,则报告请求的峰值可能更高,并且有必要向后台报告以扩展更多的机器。

 

 _11.jpg

 

 我们分析了提交请求的顶级用户日志,发现有两个主要原因:

 

 

 1)用户频繁地在前台和后台之间切换以触发多个报告请求:为在前台和后台之间初始切换而设置的频率控制时间相对较短,这可能导致用户仅用几个数据就触发多个请求;

 2)一些关键指标数据(如覆盖率数据)会在开始时实时提交,并且会有多个提交请求,只有一个数据。

 

 出于这两个原因,我们采取了相应的措施:

 

 

 1)通过前后切换来调整触发报告的时间间隔,并将第二级改为分钟级,以便控制背景;

 2)关键指标数据改为批量报告,通过日常检查增加触发时间。

 

 结算后,报告的请求数少于彩票请求数,比例已降至1.0以下。经过测试,单个用户提交的平均请求数减少了71.4%。

 

 

 6.5.3关键指标数据不准确

 

 根据之前的演练,我们计算了分配和资源覆盖,发现结果与预期有些不同。我们使用的配置系统是在登录级别拉出来的,分发成功率高于95%。但是,在演练期间,统计报告数据配置的覆盖率在80%到88%之间,并且怀疑报告的数据可能会丢失。

 

 我们分析了一些活跃的用户(在前台登录)但没有报告,发现这些用户确实拉了配置并触发了报告,但报告的数据可能会丢失。一方面,可能是内存中的数据没有及时与文件同步,因为写入文件的初始设置频率是每30秒一次,这要花一点时间,内存中的数据可能会在用户终止进程或退出后台等操作场景中丢失;另一方面,报告数据的丢失可能是由网络原因造成的。

 

 鉴于这两个原因,我们采取了相应的措施:

 

 1)缩短保存文件的时间间隔(取值10秒测试多值的综合性能和时间效率),背景可控,多机会补偿:包括三种场景:前台和后台切换,查杀过程和应用崩溃。经过测试,与每次写入文件相比,每10秒写入文件对CPU的影响降低了66.7%,对磁盘的影响降低了87.9%。

 

 _12.png

 

 2)确保关键指标数据上报成功,过滤冗余数据:改变覆盖指标的日常检查方式,每次登陆/断开网络重新连接时触发覆盖检查,并增加一定的频率控制,以便覆盖检查后上报结果。当覆盖数据实际触发上报至后台并成功返回数据包时,本地记录上报状态,因此如果在下次触发覆盖检查报告前判断覆盖数据已经上报,则不上报,直接作为冗余数据过滤掉。与每日检查法(每天报告多个覆盖数据)相比,该方法可为单个用户保存高达93%的覆盖数据。

 

 _13.png

 

 解决方案后,钻取的覆盖类数据后来恢复正常,配置覆盖率在97%到99%之间。

 

 6.6。容错机制

 

 下图显示了上报数据的循环过程:

 _14.png

 

 在将客户端数据报告给后台的链接中,单点登录访问层和报告服务后台都有过载的风险。鉴于这两种风险,我们采用过载策略和降级策略来应对。

 

 1)单点登录接入层过载:如果单点登录接入层过载,采用的过载策略是:单点登录接入层直接返回数据包,客户端根据过载标志将批量上报的批量大小值设置为最大值,并将上报频率和时间加倍,从而降低客户端的上报频率。

 

 2)报告服务背景过载:鉴于报告服务背景过载,我们制定了一套降级策略,后包包含两个降级信息:

 

 报告级别:报告级别,默认为0

 报表级别Time:报表级别的生效时间,当报表级别> 0时生效

 

 我们设置了四个升级级别,如下图所示,客户将根据后台设置的升级级别降低升级服务。如果报告级别设置为1,客户端会将所有实时报告降级为批处理报告。此外,报告级别可以设置为2,以降级和屏蔽非用户行为的数据报告;您甚至可以将报告级别设置为3,以屏蔽所有数据的报告。报告级别的有效时间确保客户端可以恢复正常的报告逻辑。

 

 _15.png

 

 6.7。优化点

 

 下图显示了除夕夜春节红包活动的数据上报请求曲线。报告请求的实际峰值是报告请求的估计峰值的13.33%。

 

 _16.png

 

 从曲线中可以清楚地发现,在每次回答活动开始时,数据报告都有一个峰值,这是由于客户在数据报告中没有出现错误的峰值。这也是该数据报告方案的优化点之一。移峰模式可以是简单的随机移峰报告,也可以参考第二部分中的移峰方案。

 

 另一个可以优化的地方是,当我们触发数据报告请求时,我们可以抓住机会触发报告,这有助于分析用户触发数据报告的行为。

 

 七.关于“资源预下载”

 

 

 7.1。概观

 

 春节红包活动不仅涉及到很多资源,而且有些资源还比较大。如果客户端通过实时下载来使用这些资源,不仅会给CDN带宽带来很大压力,还会对用户参与活动的体验产生很大影响。

 

 自然,最常见和最有效的解决方案是资源预下载。

 

 预下载资源的能力包括但不限于以下考虑事项:

 

 

 1)资源可以在本地正常下载;

 2)服务访问的开发效率(提供更方便、更通用的接口,集成资源判断、实时下载、资源文件预处理等逻辑);

 3)考虑资源过剩导致的CDN带宽激增问题(需要制定相应的流量控制方案);

 4)预下载过程不应影响其他服务(如Q启动时的消息加载、其他服务资源的实时下载等)。);

 5)资源管理(下载、更新、删除、防篡改、消除机制等。);

 6)预下载配置管理(存储、更新、合并、重复数据消除等)。);

 7)等待...

 

 今年的春节红包活动使用的是QQ钱包业务搭建的资源预下载系统,这里不再详细介绍。今年的春节红包活动只讨论以下几个方面。

 

 7.2。预下载配置问题

 

 预下载配置是JSON格式的。当访问Q配置系统进行发布时,需要填写与所有预下载资源相关的配置内容。如果手动理解手写配置,不仅容易出错,而且效率低下,这将影响客户端资源的正常预下载。此外,不适当的JSON解析和处理可能会导致应用崩溃,这将对春节期间如此大量的用户产生相当大的影响。

 

 我们的处理方法是春节红包活动管理平台根据预下载配置格式,通过点击导出,自动生成预下载配置内容,并在配置平台上发布。与此同时,当客户端提取预下载的配置时,将对提取的配置内容执行JSON模式检查,以确保在使用之前它是正确的配置。如果在检查中发现配置格式异常,会立即报警,通知相关产品和开发人员,以便及时发现配置问题并采取措施进行修复。

 

 7.3。码分多址带宽估计

 

 春节红包有很多资源,所以需要足够长的时间覆盖整个网络用户进行预下载。CDN需要预先分配资源,以满足活动资源的带宽要求。

 

 因此,我们需要估计春节红包活动的CDN带宽:我们应该多早开始预下载资源?CDN需要分配多少离线带宽和在线带宽?

 

 假设我们提前d天发布了预下载配置。

 

 1)离线带宽估计:

 

 应该分配离线带宽资源,以便所有用户可以在d天内顺利下载所有资源。假设Q中的用户总数为n,并且要预下载的离线资源的总大小为m千字节(KB),则可以估计所有用户预下载的所有离线资源的总流量(单位:位):

 

 总预下载流量= M * 1024 * 8 * N

 

 

 也就是说,下载这么多流量资源需要d天,离线带宽值(单位:Gbps)由估计系数c:

 

 离线带宽=总预下载流量* c/(d * 86400 * 1024 * 1024 * 1024)=(m * 8 * n)* c/(d * 86400 * 1024 * 1024)

 

 

 2)在线带宽估计:

 

 在线带宽资源的分配取决于活动期间实时下载资源的估计峰值。对于活动中涉及的所有资源,我们根据资源使用入口级别将它们分为四个资源级别,并且不同资源级别的请求峰值是不同的。

 

 _17.png

 

 根据每个活动入口的估计峰值和练习期间的转换率数据,获得各级资源的峰值。此外,有必要考虑资源预下载的影响,以便估计在线带宽。

 

 对于每个资源,假设其在线资源大小为R千字节(KB),资源的预期峰值为PW/s,资源的预下载覆盖率为90%,则资源的在线带宽峰值为(单位:Gpbs):

 

 在线带宽=(r * 1024 * 8)*(p * 10000 * 0.1)/(1024 * 1024 * 1024)

 

 

 

 7.4。覆盖率和命中率

 

 预下载支持配置网络参数以控制预下载当前资源的网络环境。春节红包的整体资源比较大,所以我们把所有资源都配置成只能在Wifi网络环境下预下载,以防止用户手机流量的消耗。因此,我们整体资源的覆盖率并不太高,因为仍有许多用户的网络状态是非Wifi。

 

 当然,覆盖率只是衡量预下载功能的一个指标,另一个重要指标是资源预下载的命中率。命中,指示用户在使用资源时是否命中本地预下载的资源。当用户进入主活动门户时,我们增加了资源的点击检查:如果用户进入主活动页面,预下载配置中的所有资源都是预先在本地预下载的,即被认为是点击;否则,根据活动当天的第一个条目,它被视为未命中。据报道统计,春节期间资源预下载红包的点击率超过90%。

 

 理想情况下,预下载应该达到以较低的覆盖率获得较高命中率的最佳效果,这表明大多数参与活动的用户基本上覆盖了所有资源,并且是我们的目标用户。因此,对于目标用户明确的服务,可以通过白名单的方式将预下载配置控制为仅分发给目标用户。

 

 八、关于“灵活战略”

 

 春节红包活动在手问信息列表中有一个吊坠入口,活动主要以H5页面的形式进行,这可能会对手问产生以下三种影响

 

 1)对刷新下拉消息列表中的消息的影响:

 

 基于用户对以往春节红包的认知,在春节红包开始之前,一些用户会习惯性地去下拉列表中查找活动条目,在分会场设置的呼吸灯也会引导用户下拉列表。这种行为将触发离线消息提取,这将在活动高峰时给消息背景带来额外的压力。

 

 _18.jpg

 

 为了消除对刷新下拉消息列表中的消息的影响,我们禁止用户在每次活动开始之前和之后以及第一次显示呼吸灯之后的一段时间内刷新消息。仍然有一个错误的视觉刷新消息的过程,但是拉脱机消息的请求实际上不会被触发。通过在配置中增加无刷开关和无刷时间,可以灵活调整。

 

 这里有一个细节。我们在事件前后分别控制禁刷时间,以防止禁刷时间过长,减少禁刷消息对正常离线消息的影响。

 

 _19.png

 

 2)对网址安全检查的影响:

 

 打开一个H5网页在手问,WebView将检查网页网址拦截的网址安全性,只有通过检查后才能继续加载网页内容。本次春节红包活动主要以H5模式进行,有很多网址链接。如果他们都要接受安全检查,这将增加活动峰会检查背景的压力。

 

 _20.png

 

 为了消除对背景检查的影响,采取的措施是对春节红包活动的所有页面进行网址安全检查。通过在配置中添加url安全检查开关和url前缀列表,所有活动页面的URL都是内部域名。此外,阻止url安全检查还可以在一定程度上加快活动页面的加载速度,尤其是在网络环境较弱的情况下。

 

 3)对离线包更新检查的影响:

 

 春节红包活动的大部分页面都支持离线包。当使用WebView打开支持脱机包的页面时,将触发脱机包的异步更新检查,这也将在活动的高峰期给脱机包的背景增加很多压力。

 

 消除这种影响的方法是在所有支持离线包页面的网址中添加一个切换参数,如果客户端判断它有这个参数,它将直接阻止离线包的更新检查。

 

 然后,如果前端页面在活动期间发送新版本的离线包,客户端应该如何更新它?我们设计了一个按需更新方案。总体思路是:当进入主活动页面时,页面会拉一个离线包版本配置,并检查本地离线包版本是否与配置中指定的版本一致。如果不一致,更新检查将通过在不屏蔽开关参数的情况下启动资源请求来触发,并且请求的目标对象是1字节文件或1像素图片。

 

 九、写在末尾

 

 2020年春节红包持续了近4个月。经过多次演练、迭代和优化后,团队的所有成员不断完善产品体验、开发细节和测试场景。

 

 在参与这一大型全国性运营活动的整个过程中,我深深地感受到,在设计或实现一个看似简单的功能时,我必须更加系统地思考,力求有理有据,考虑方方面面。当遇到哪怕是最小的问题时,我们都应该关注它并找到它的根源。

 

----------------------------------------------------------------------------------

哇谷im_im即时通讯_私有云_公有云-哇谷云科技官网-JM沟通

IM下载体验 - 哇谷IM-企业云办公IM即时聊天社交系统-JM 沟通下载

IM功能与价格 - 哇谷IM-提供即时通讯IM开发-APP搭建私有化-公有云-私有化云-海外云搭建

新闻动态 - 哇谷IM-即时通讯热门动态博客聊天JM沟通APP

哇谷IM-JM沟通热门动态博客短视频娱乐生活

关于哇谷-哇谷IM-提供企业即时通讯IM开发-语音通话-APP搭建私有化-公有云-私有化云-海外云搭建

联系我们 - 哇谷IM-即时通讯IM私有化搭建提供接口与SDK及哇谷云服务

即时通讯IM融云世界

IM即时通讯钉钉技术:企业IM钉钉在后端架构上的优越之处

新的市场叫板环信、融云、腾讯云!开源版IM即使聊天工具

企业IM即时通讯聊天办公APP钉钉技术分析交流

哇谷云-怎么样正确认识海外云服务器

公有云和私有云之间有什么区别?类似融云、环信云、网易云、哇谷云?