im即时通讯 QQ、支付宝、微信、聊天和诚信红包技术构架方案

时间:2020-10-20

商城源码

 一、导言

 自2015年春节以来,QQ春节红包经历了几个阶段,如企业红包(2015)、刷红包(2016)和AR红包(2017)。通过不断的游戏创新,这项活动稳步上升,成为春节的一大看点,为火热的春节增添了一抹亮色。在2017年的除夕,ar红包和刷红包创下新高,有3.42亿用户拿到了红包和37.77亿个红包。

 那么,QQ红包的技术方案是什么?它的整体结构是什么?重要系统是如何设计的?为了保证用户体验,对移动QQ的移动终端做了哪些优化?今年的QQ红包有哪些新的尝试,问题是如何解决的?本文将从架构入手,对手机QQ进行优化,然后对个性化的红包和增强现实进行全新的游戏性,从而为大家全面解密QQ红包。

 补充说明:QQ团队分享的另一篇文章,“社交软件红包技术解密(九):谈功能逻辑、容灾、运维、架构等。从产品的角度来看,这是不同的描述。

 支付宝、微信、聊天、诚信_1.jpeg

 第二,关于作者

 支付宝、微信、聊天、诚信_无标题-1.jpg

 ▲两位作者,徐凌峰(左)和周海发(右)

 2006年加入腾讯的徐凌峰是会员系统的后台领导。他曾参与管理信息系统、网络安全、谈论空间、WAP音乐、超级Q、会员等项目,对开源组件和虚拟化感兴趣,并致力于推广Docker虚拟化和开源组件的应用和实践。

 海发洲(周海发):2011年加入腾讯,从事即时通讯基础系统的开发和运营,先后参与了一键通的统一登录和消息漫游存储改造项目,连续三年参与并负责QQ春节红包的后台系统架构设计,积累了多年的海量分布式高性能系统设计经验。

 第三,一系列文章

 系列文章目录:

 “支付宝、微信、聊天、诚信”(*本文)

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

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

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

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

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

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

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

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

 社交软件红包解密技术(十):2020年春节红包手q客户端技术实践

 其他相关文章:

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

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

 "每月活动8.89亿次的超级即时通讯微信如何进行安卓兼容性测试?"

 “开源图书馆:后台框架的基石,支持微信8亿用户在一台机器上拥有数百万的连接(源代码下载)”

 "微信技术总监谈建筑:微信之路——走向简(演讲全文)"

 “微信技术总监谈建筑:微信之路——走向简(PPT讲座)[附件下载]”

 如何解读《微信技术总监谈建筑:微信之路——通向简》

 微信大用户后台系统存储架构(视频+PPT)[附件下载]

 “微信异步转型实践:8亿月度活动和单机连接背后的后台解决方案”

 "微信朋友圈海量技术PPT[附件下载]"

 “架构方式:3名程序员在微信朋友圈(有视频)中平均每天发布10亿条消息。”

 “快速裂变:见证微信强大后台架构从0到1的演变(一)”

 “快速裂变:见证微信强大后台架构从0到1 (2)的演变”

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

 "微信技术共享:微信的海量即时聊天信息序列号生成实践(算法原理)"

 "微信技术共享:微信大规模即时通讯聊天信息序列号生成实践(灾难恢复计划)"

 四.QQ红包的总体结构和重要系统

 QQ春节红包在除夕夜整整一个小时里一个接一个地发放,在除夕夜达到高峰,这是大量用户互相残杀的典型场景。如何应对大量用户刷红包的洪流,确保他们刷好并安全到达,是QQ红包设计中需要解决的关键技术难题。此外,红包项目涉及很多业务系统,如移动QQ移动终端、移动QQ后台、QQ钱包(财付通)系统、礼券系统、公共号码等。这个过程既长又多,每个系统的性能吞吐量差异很大。如何确保每个系统形成一个有机的整体,并以协调和有效的方式提供服务也是困难之一。

 下图显示了简化的QQ红包架构,包括:接入层、抽奖系统、存储系统、传递系统、公共号码信息通知和CDN资源等。请对以下内容有一个全面的理解,以便于阅读。

 支付宝、微信、聊天、诚信_1.jpg

 ▲简化的QQ红包系统架构

 本节将重点介绍接入层、彩票系统和递送系统。

 4.1。接入层

 接入层是红包后台服务的大门,负责预处理彩票请求,以确保有效的请求被传输到后端服务。为了保证其高可用性和稳定性,接入层还可以实时控制手机的QQ请求频率,从而避免大量请求挤压接入层造成的不可控情况。

 在大规模服务场景中,为了避免网络开销,方便后端服务使用缓存来提高性能,接入层采用一致的哈希寻址,确保同一用户的请求只由同一红包彩票逻辑机处理。

 4.2。彩票系统

 4.2.1基本介绍

 作为QQ红包的核心系统,抽奖系统在接受用户抽奖请求、按照合理设计的概率完成抽奖操作、安全保存抽奖结果、顺利发货的过程中发挥着关键作用。面对大量的彩票请求,如何及时响应是彩票系统面临的一个难题。

 为了解决这些问题,我们采用了一些设计方法:

 1)在接入层采用一致的哈希算法:同一用户的彩票请求只转发给同一彩票系统进行处理;

 2)抽奖系统采用缓存机制,加快了抽奖过程,降低了对存储层的访问压力;

 3)奖金分配机制:理顺彩票流程,各种奖金按比例有序发放;

 4)流程和对账机制:确保彩票数据最终无误地发布到用户账户。

 彩票系统的架构如下图所示:

 支付宝、微信、聊天、诚信_2.jpg


 4.2.2缓存机制

 商业要求用户可以限制每次刷活动的获胜时间和参与时间(30秒)。如果每个彩票请求都来自用户,则用户的中奖历史信息首先从存储层获得,然后判断用户是否有资格进行彩票,这将不可避免地在大量高并发请求的情况下对存储层造成巨大压力。因此,我们引入了本地内存缓存层来存储用户的中奖历史信息。当请求到来时,用户的获胜历史信息将首先从缓存层获得。如果在缓存层没有找到,就从存储层获得,这样就不会对存储层造成太大的压力,同时可以满足业务需求。我们使用开源的Memcached组件来实现缓存层。

 4.2.3一致的哈希寻址

 红包彩票系统是一个分布式系统。因此,为了使缓存机制有效,我们使用一致的哈希路由算法来寻址移动QQ接入层,以确保同一用户(uin)的请求总是落在同一逻辑机器上进行处理。

 支付宝、微信、聊天、诚信_3.jpg

 4.2.4协议处理模块

 由于移动QQ的后台既要处理客户端的二进制请求,又要处理其他网络系统的HTTP请求,因此协议处理模块的主要任务是兼容各种格式的协议,并为后端模块提供最简单的结构。因此,我们开发了一个Protobuf格式的交互协议(它与JSON格式兼容,并将统一转换成Protobuf处理),并将其传递给后端模块。

 4.2.5定额管理模块

 手机QQ春节红包是通过许多定期的“活动”分发的。每项活动可以分配多少现金,可以分配多少虚拟商品,分配的比例是多少,所有这些都是配额数据。

 此外,我们应该准确控制现金和虚拟商品的分发速度,这样,无论用户何时来参加活动,他们都有机会得到红包,而不是在最初几分钟就被用户一扫而光。

 支付宝、微信、聊天、诚信_4.jpg

 配额信息由配额管理工具检查和修改,每次修改都会生成一个新的序列号。一旦配额代理发现SeqNo已更改,它将更新本地共享内存。因为代理采用双缓冲区设计,所以在更新完成之前不会影响当前的业务流程。

 4.2.6彩票模块

 以彩票为中心,QQ红包的抽奖算法并不复杂,但满足产品的需求非常重要。

 我们的设计理念是至少满足以下要求:

 1)每个项目的现金和发行速度可以控制在第二级;

 2)便于调整现金和各项目的分配比例;

 3)尽量确保所有的红包都分发出去。

 为此,我们设计了以下彩票流程算法:

 支付宝、微信、聊天、诚信_5.jpg

 值得注意的是,只要因配额限制而未能分发红包,我们将继续尝试向用户分发其他奖品的红包,直到没有奖品可分发为止,这样我们就可以确保尽可能多地分发奖品。

 4.2.7流量系统设计

 流程系统用于保存活动过程中彩票的流程记录,并对活动后的奖金分配和获奖者进行统计和核对。该系统还定期重做和协调失败的请求,以确保奖品被分配到用户的账户。

 管道系统架构如下:

 支付宝、微信、聊天、诚信_6.jpg

 由于管道需要记录用户的中奖信息和收件人,并且数据量巨大,因此彩票逻辑层在本地采用按顺序写文件的方法进行记录。彩票逻辑层将定期将本地流文件同步到远程流系统,以进行汇总和备份。同时,流程系统将重做失败的流程,并向彩票逻辑层发送请求,彩票逻辑层将调用交付系统的接口来完成交付操作。

 4.2.8存储层的选择

 存储层的设计一直是后台架构设计的重点和难点。目前,腾讯成熟的NoSQL存储系统包括CKV和杂货店。经过一番比较,我们选择杂货店的原因如下。

 1)具有条件判断的强大分布式原子算术运算;

 在彩票逻辑中,需要计算每一个奖金,因此拥有一个高效可靠的分布式原子加法计数器是非常重要的。杂货店支持有条件判断的原子加法计数器,它可以判断奖励计数值和配额,并通过调用一次接口来增加奖励计数值。

 2)灵活的数据类型:

 杂货支持键-键-行数据存储格式,可以灵活存储用户红包的中奖信息,为获取用户的单个红包或红包列表提供了丰富的界面。

 3)方便部署和扩展:

 杂货店有特殊的团队支持,易于部署和扩展。

 4)平滑限频设计:

 每一种奖品,对应的业务都有自己的容量和能力,而且每个业务的能力也是不同的(如黄钻4w/s、京东2k/s等)。)。为了保证红包活动的持续,彩票系统必须严格按照业务控制分配峰值。服务峰值可实时调整,避免因服务方评估不足而导致过载。

 支付宝、微信、聊天、诚信_7.jpg

 考虑到这种情况,如果在1秒钟开始时请求都被发送到服务侧,由于服务侧的不同架构实现,它可能触发服务侧的频率限制或过载保护。因此,我们将频率限制的粒度调整为100毫秒,以便在1秒内相对均匀地分发奖品,从而解决了上述问题。

 4.3。QQ红包递送系统

 QQ红包奖品包括现金和礼券。现金匹配财付通,礼券分为腾讯内部虚拟商品和第三方礼券。最终礼物将进入用户账户(QQ钱包余额、QQ卡优惠券或第三方系统账户)。虽然彩票系统处理顺畅,但长时间大流量交付也可能导致业务系统无法正常提供高峰服务能力。如何将前、后两者联系起来,不仅可以防止彩票系统无法顺利投递商品,从而给投递系统(本身)带来压力,还可以保护后端业务系统,以更快的速度安全地将奖品分发到账户,这是投递系统的关键设计点。

 交付系统设计遵循以下策略:

 1)快速和慢速分离;

 2)异步削峰;

 3)灵活处理;

 4)保护业务系统;

 5)最终一致性。

 交付系统架构如下图所示:

 支付宝、微信、聊天、诚信_8.jpg

 速度和速度的分离:

 现金和礼券后端系统完全不同。现金通过QQ钱包系统分配到财付通账户,要求实时到达,不得延误。但是,礼券对接的后端业务千差万别,服务能力和性能也各不相同。为了不让缓慢的礼券发行影响快速的现金发行,现金渠道和礼券渠道是分开的,不会相互干扰。

 异步削峰:

 由于抽奖的时间完全是随机的,所以抽奖系统无法绝对顺利地交付商品。让彩票系统直接向业务系统发送递送请求是不可接受的,这将导致不可预测的问题和严重情况下业务系统的雪崩。此外,对于第三方礼券,如游戏礼包和滴滴礼券,用户账户可能不存在(用户不玩游戏,或者用户没有第三方账户),因此有必要指导用户在交付之前创建账户,这要求交付系统临时存储奖品信息并具有延迟交付的能力。

 在交付系统中,开源RocketMQ消息中间件作为异步消息队列,临时存储交付请求,然后礼券交付模块根据每个服务的限速配置统一调用服务接口进行交付。

 灵活处理:

 礼券奖品以异步方式发放到用户账户,发放速度可能赶不上除夕夜高峰时的抽奖速度,并且会延迟一段时间到达,这可能会给不明真相的用户带来麻烦。因此,在用户获胜信息页面中,将提示用户在24小时(或48小时)内到达。交付过程中的每一步都可能异常失败,导致交付失败。因此,项目详细信息页面上的按钮支持多次交付启动。在“礼券派送”模块中,您可以根据派送状态尝试派送几次,并确保奖品只发放一次。

 保护业务系统:

 如前所述,交付系统通过异步消息队列将彩票系统与业务开发分开,彩票洪峰不会直接影响业务系统,从而隔离和保护业务系统。

 礼券交付模块为每项业务单独配置限速阈值,并严格以不超过每项业务交付限速阈值的速度交付奖品。如果业务超时或提示超速,根据一定的比较,会再次减速。

 礼券交付模块将首先检查奖品在存储系统中是否真实有效,然后检查交付状态存储中的状态是否正常。只有真正需要交付的奖品才会向业务系统发送交付请求,以确保交付的有效性,并避免错误交付和多次发生。

 最终一致性:

 由于采用了异步交付,彩票中奖时的奖金不能保证立即分配到用户账户。但是,用户的奖品不会丢失。通过将它们临时存储在异步队列中,礼券交付模块以合适的速度逐渐将奖品分发到用户的帐户。

 如果交付过程中出现延迟或失败,用户可以多次提取交付请求,并且系统支持多次提交。

 如果多次交付仍然失败,协调工具将在第二天将用户的彩票数据与来自流量系统的交付数据进行协调,并为交付异常的用户再次启动交付。如果调解仍然失败,提醒经理进行干预。

 第五,移动QQ移动终端的优化策略

 普通用户并不在乎QQ红包的背景有多复杂,他们在手机QQ上抓取红包的经历直接决定了用户对QQ红包的评价。对于用户来说,看到红包后能否顺利抓取和刷掉是最直接的痛苦点,因此有必要尽可能减少延迟,以消除被卡住的体验,即使在网络环境较弱的情况下,用户也应该有更好的体验。为了实现这一目标,QQ移动终端采用了以下优化策略:

 1)资源预加载:

 QQ红包中使用的静态资源,如页面、图片、JS等。,将分发到各个地方的CDN以提高访问速度,并且只有动态变化的内容才会从后台实时提取。然而,即使所有的静态资源都由CDN分配,CDN的压力也不能被绝对地削减。由于有大量的人同时访问红包页面,根据83万次/秒的峰值和20万次/秒的一个页面的评价,大约需要158.3G的CDN带宽,这将立即给CDN带来巨大的压力。为了减轻CDN的压力,QQ红包利用移动QQ的离线打包机制,预先将与红包相关的静态资源预加载到移动QQ上,可以大大减轻CDN的压力。

 目前,手机QQ离线套餐有两种预装方式:

 A.将静态资源放入预装列表:当用户再次登录QQ时,监控离线包是否更新并按需加载(一天可覆盖60%,两天可覆盖80%,适合预热和大容量);

 主动推送离线包:将离线包推送至当前在线用户。(推送可在2小时内完成,覆盖总量的40%左右,适用于紧急情况。)预装离线包后,除夕CDN流量没有异常高峰,相对稳定。

 2)缓存和延迟:

 2 . 59亿用户同时在线,用户刷机时的峰值高达83万次/秒。如果这些用户的所有操作请求同时涌向后台,即使后台能够抵抗,所需的带宽和设备资源成本也是天文数字。为了尽可能地减轻后台服务器的压力,根据用户的画笔体验,用户不必每次都请求后台。因此,移动QQ对用户在移动终端上的刷操作进行计数,并在固定时间(1~3秒)将汇总数据异步提交给后台彩票,然后将彩票结果发送回移动QQ进行显示。这不仅保证了无忧无虑的“刷牙”体验,还大大减轻了背景的压力。彩票结果也是无意中产生的,用户体验是完全完整的。

 3)峰值偏移:

 当用户被分组时,刷红包的开始时间(企业明星红包、ar红包等)。)按不同的分组是不同的,但错开一段时间(1~5分钟),这样通过错开每轮刷红包的开始时间,可以有效地平滑用户的请求高峰。

 4)动态调整:

 移动终端和移动QQ的背景不是两个孤立的系统,而是一个整体。移动QQ系统有一套完整的负荷监控系统。当后台负载上升到警戒线时,移动QQ的移动终端可以根据后台负载情况动态减少发送到后台的请求,防止后台过载和雪崩。

 5)总量限制和清洁:

 在刷红包和AR红包的过程中,当用户赢得的奖品数量达到极限(例如,五个)时,用户不能再赢得奖品。此时,用户的抽奖请求不再发送到后台,但移动终端会直接通知用户“您没有中奖,请稍后再试”,并清除AR红包地图中的红包显示。

 第六,红包创新游戏挑战

 春节红包大战已经从企业红包演变为刷红包、个性化红包和ar红包。游戏不断创新,用户体验更好,活动也有所改进。在为期17年的春节期间,参与者的数量也从2亿增加到3.42亿。

 6.1。个性化的红包

 6.1.1基本信息

 QQ个性化红包是对红包外观的大胆尝试。有了这个功能,用户可以在信封上刻上他们的姓氏和/或其他字符(提供自动简化和传统转换)。此外,我们还提供卡通红包,有新年气氛、QQ家庭、游戏图片、卡通图片等,大大提高了QQ红包的趣味性和观赏性。个性化红包功能推出后,超过30%的红包用户选择使用个性化红包。2016年春节期间,共有1500万用户使用该功能,2016年除夕,发送的个性化红包数量超过8000万。

 支付宝、微信、聊天、诚信_11.jpg

 在共同的基础上,个性化的红包允许用户修改红包的信封,显示个性和适应现场。因此,设计的关键在于让用户操作顺畅,不仅保持发送和抓取红包的流畅体验,而且展现个性和乐趣。

 个性化红包流程架构如下图所示:

 支付宝、微信、聊天、诚信_22.jpg

 从上图可以看出,简化的红包发放流程经历了红包移动终端->财付通->红包背景->手机QQ AIO(聊天互动窗口)->拆除(抓取)红包页面等流程。,而且过程很长(有些细节被忽略,而实际过程更复杂)。在这些步骤中,如果每一步都去后台判断个性化的红包状态,将不可避免地影响红包发放的流畅性。

 为了尽可能不影响用户的红包体验,个性化的红包在架构和操作上做了很多解耦和灵活的设计。包括个性化字体预先绘制、资源预加载、功能切换和容灾灵活处理等。

 6.1.2预先绘制字体

 个性化红包支持所有简体和繁体汉字,并支持一些简体汉字转换成繁体汉字。为了改善使用“姓氏红包”的用户的体验,我们使用预先生成的方法生成普通的姓氏图片,并在用户的手机QQ空闲时将其保存在本地。其他人不常使用姓氏,当他们被展示时,他们是合成的。合成后的数据在本地保存一次,下次在本地读取。

 手机QQ的移动终端在空闲时会画出一幅很好的字体图,并支持定期更新背景图和字体库。对于不常见的单词,它会启动个性化字体引擎来生成相应的个性化地图。

 当用户发出或收到红包时,已经生成了个性化的背景和字体图,因此不需要再次生成它们,并且接收和发送红包的流畅体验没有被破坏。

 支付宝、微信、聊天、诚信_33.jpg

 资源预加载

 个性化的红包材料是预先准备好的,并上传到CDN网络。手机QQ在免费时会提前从CDN下载资料文件,并定期检查资料的更新情况,以便及时更新。

 6.1.4功能开关

 用户是否设置了个性化的红包,选择了个性化的红包地图样式,启用了个性化的红包等信息,如果每一个判断都是从背景中拉出来的,那么必然会增加背景压力。事实上,用户对个性化红包的设置信息并没有太大的改变,通过手机QQ的移动终端就可以获得红包商城的实时设置状态。因此,我们设计将这些用户状态标志从后台拉出来,在登录移动QQ时保存在移动QQ的移动终端中,并在红包的过程中把标志信息传递给下游服务,通过红包商城设置的个性化红包标志实时更新移动QQ的本地配置。

 这种设计有几个优点:

 1)用户的个性化设置不再依赖于背景,红包流程完全在本地操作,没有任何延迟,不影响红包的发放;

 2)标志标志可用作容灾开关。如果个性化红包被临时取消或后台出现故障,个性化红包功能可以被临时屏蔽并恢复为默认的红包样式,以保证红包功能可以随时正常使用;

 3)标志标志可以支持扩展。在红包背景中,可以支持付费红包风格(付费购买)、特权红包风格(如超级独家)等。,并支持红包商城扩展各种个性化红包;

 4)除了从后台拉标志外,当标志因业务调整而变化时,红包后台可以主动将标志状态推送到手机的QQ移动终端,让用户及时感知变化,进一步提升用户体验。

 6.1.5容灾的灵活处理

 与移动QQ平台的功能相比,个性化红包系统相对独立,运行和更新速度快,因此系统的各个功能组件可能会出现更多的问题。如果个性化红包业务出现问题,影响到正常的红包发放或手机QQ功能的使用,将对QQ的声誉产生很大的负面影响。我们在系统中设计了几种容灾和灵活的处理措施,可以在个性化红包服务出现异常时降低服务等级,在最差时取消个性化红包功能。

 灵活措施1:当用户登录时未能拉出个性化的红包标志时,采用默认的红包样式;

 灵活措施2:当红包背景拉个性化设置认证细节时(是否付费,是否对会员独占等)。)从个性化的红包背景,如果拉动不正常,则采用默认的红包样式;

 灵活措施3:个性化红包的特点是用户输入姓氏并指定显示的文本。如果遇到敏感词或需要暂时脱机,可以通过向手机QQ发送FLAG标志来暂时取消个性化红包功能,并恢复默认的红包样式。

 6.2。AR红包

 6.2.1概述

 AR红包是“伦敦商学院+AR天堂红包”的缩写。这款创新的游戏赢得了用户的一致好评,共有2.57亿用户参与,共收到20.5亿个红包和礼券,赢得了良好的声誉和积极的收获。

 支付宝、微信、聊天、诚信_44.jpg

 6.2.2缓存设计

 LBS+AR红包和以前的红包的最大区别在于,还有一个地理位置关联。全国有数以千万计的地理位置信息,结合活动任务奖励数据生成大量的配置数据,需要快速实时读取。这是系统设计中的一大挑战。

 配置数据具有以下特征:

 1)有大量的数据(1亿个),这些数据彼此密切相关。使用MySQL数据库集群存储,构建一个网络可视化配置平台,实现自动灾难恢复和备份功能;

 2)“一次性分配,随处使用”,配置的读取量远远高于写入量。基本思想是设计和开发一个缓存,放弃写性能,并将读性能优化到极致。

 千兆位配置数据,彩票系统如何快速检索?考虑到业务使用场景、配置数据大小和MySQL性能,可以提前构建全缓存并有序组织,同步模块负责将构建的配置数据同步到彩票系统,供业务流程直接使用。为了保证配置数据的完整性,构造缓存采用双缓存设计,只有在构造或同步完成后才切换到最新的配置。

 支付宝、微信、聊天、诚信_55.jpg

 6.2.3地图打点和检查

 基于位置服务的红包活动离不开与地理位置相关的业务互动。在增强现实的红色信封中,用户打开地图时会定期向背景报告坐标。后台需要根据坐标获取周围活动和任务的可用启动点。发射点将被提前筛选,以清除存在安全隐患的区域,并避免给用户带来人身安全问题。本节主要介绍如何管理这些启动点。

 地图网格:

 根据坐标将整个二维平面分成边长相同的正方形网格,根据用户的坐标通过简单的数学运算即可得到相应的网格编号,时间复杂度为O(1)。网格是查询的最小粒度。每个查询将返回5*5个任务点,以用户周围的25个网格为中心。

 支付宝、微信、聊天、诚信_66.jpg

 点:

 红包是在任务维度中传递的,每个任务都与一个兴趣点集相关联。每个兴趣点集合包含数百万到数百万个兴趣点,并且每个兴趣点具有纬度和经度信息。

 打点是预先建立从网格到任务列表的映射。所有点阵数据都按顺序组织并存储在共享内存中,二进制搜索用于提高读取性能。

 计数过程:

 1)客户报告经度和纬度;

 2)根据经纬度计算中心网格标识;

 3)根据中心网格标识和半径配置,获取周围网格列表;

 4)获取打点系统中该区域所有兴趣点和任务信息;

 5)检查任务状态并将其返回给客户端。

 6.2.4采集系统

 采集系统主要负责汇总各行政区域的红包发放情况数据,主要提供以下功能:

 1)实时返回区级行政区域的红包数;

 2)实时接受主逻辑的查询,返回到奖金分配状态;

 3)返回活动预测、参数配置等辅助信息。

 因为红包是按照行政区划发放的,所以每个行政区划大约有10个任务,每个任务都与不同类型的红包相关联。如果每次查询区级红包额度时都实时计算并汇总红包状态数据,则扩散导致的包额开销会比较大。因此,我们仍然使用双缓冲区缓存来解决这个问题,一个进程负责将收集的数据写入缓存,另一个进程提供查询服务。此外,根据存储层的压力,可以适当调整收集频率,以使统计数据尽可能实时。

 支付宝、微信、聊天、诚信_77.jpg

 七.本文摘要

 自2015年以来,QQ红包在除夕夜的收发情况如下表所示。可以看出,参加人数和红包总数都在增加。

 支付宝、微信、聊天、诚信_88.jpg

 QQ红包业务复杂,访问量大,涉及业务多,流程长。项目的成功离不开相关兄弟部门的大力支持和能力配合。特别感谢即时通讯产品部、财付通、即时通讯平台部、SNG市场部、SNG商业广告中心、增值渠道部、社会用户体验设计部、集团营销与公共关系部、增值产品部、社会与绩效广告部、网络质量部、即时通讯综合部和架构平台部

热门资讯