QQ 红包技术方案全解密 (一)

作者:许灵锋

前言

自2015年春节以来,QQ春节红包经历了企业红包(2015年)、刷一刷红包(2016年)和AR红包(2017年)几个阶段,通过不断创新玩法,活跃度节节攀升,成为春节一大玩点,给火红的春节带来一抹亮色。2017年除夕,AR红包、刷一刷红包再创新高,抢红包用户数达 3.42 亿,共刷出红包 37.77 亿个。

那么,QQ红包的技术方案究竟是怎样的?其整体架构如何?重要的系统是如何设计的?为了保证用户的体验,手Q终端做了哪些优化?今年的QQ红包又做了哪些新的尝试,遇到的问题是如何解决的呢?本文将从架构开始,到手Q终端优化,再到个性化红包和AR新玩法,为大家全面解密QQ红包技术方案。

一、QQ红包整体架构及重要系统

QQ春节红包以一个又一个的整点刷红包活动贯穿年三十,在除夕夜达到顶峰,是典型的海量用户秒杀场景,如何应对海量的用户刷红包洪流,保证刷得爽,红包安全到账,是QQ红包设计要解决的关键技术难点。另外,红包项目涉及手Q终端、手Q后台、QQ钱包(财付通)系统、礼券系统、公众号等诸多业务系统,流程长且多,各系统性能吞吐量差异很大,如何保证各系统形成一个有机整体,协调高效提供服务,也是难点之一。

下图为简化后QQ红包的架构,包括接入层、抽奖系统、存储系统、发货系统、公众号消息通知和CDN资源等几部分,请大家先有一个整体的认知,便于阅读下文。

本文将重点讲解接入层、抽奖系统和发货系统。

1.接入层

接入层是红包后台服务的大门,负责抽奖请求预处理,确保有效的请求才透传给后端服务。为保证自身高可用、高稳定,接入层还可实时控制手Q请求频率,避免海量请求压垮接入层,出现不可控局面。

在海量服务场景下,为避免网络开销,方便后端服务使用cache提升性能,接入层采用了一致性Hash寻址,保证同一个用户的请求只会落在同一台红包抽奖逻辑机器处理。

2.抽奖系统

抽奖系统作为QQ红包的核心系统,在承接用户抽奖请求,按设计合理的几率完成抽奖操作,将抽奖结果安全落地保存,并顺利发货等过程中,起到了关键作用。面对海量抽奖请求,如何及时作出响应,是抽奖系统面临的难题。

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

  • 在接入层采用一致性Hash算法,同一用户的抽奖请求只会转发到相同的抽奖系统处理;
  • 抽奖系统采用缓存机制,在加快抽奖过程的同时也减少了对存储层的访问压力; 奖品配额机制,平滑抽奖过程,各类奖品按比例有序抽中;

流水和对账机制,保证抽奖数据最终无差错发放到用户账户中;

抽奖系统的架构如下图所示:

(1)缓存机制

业务要求在每个刷一刷的活动中,能对用户中奖次数、参与时间(30秒)进行限制。如果用户的每个抽奖请求到来时,先到存储层获取用户的中奖历史信息,再判定用户是否还有抽奖资格,在海量高并发的请求场景下,势必会对存储层造成巨大的压力。所以这里我们引入了本地内存缓存层,用于保存用户的中奖历史信息,每次请求到来时,会先到缓存层获取用户的中奖历史信息,如果在缓存层没找到,才会到存储层获取,这样就不会对存储层造成太大的压力,同时也能实现业务的需求。缓存层我们采用开源Memcached组件实现。

(2)一致性hash寻址

红包抽奖系统是一个分布式的系统,因此为了使缓存机制生效,我们在手Q接入层使用了一致性hash的路由算法进行寻址,保证同一个用户(uin)的请求总会落在同一台逻辑机器进行处理。

(3)协议处理模块

由于手Q后台既要处理客户端的二进制请求,也要处理其他Web系统的HTTP请求,所以协议处理模块的首要任务就是兼容各种格式的协议,给后端模块一个最简单的结构。为此我们制定了Protobuf格式的交互协议(兼容JSON格式,会统一转换成Protobuf处理),传给后端模块。

(4)配额管理模块

手Q春节红包是通过很多场定时“活动”来发放红包的。每场活动里面能发放多少现金,能发放多少虚拟物品,发放的比例如何,这些都是配额数据。

更进一步,我们要做到精确控制现金和虚拟物品的发放速度,使得无论何时用户来参加活动,都有机会获得红包,而不是所有红包在前几分钟就被用户横扫一空。

配额信息由配额管理工具负责检查和修改,每次修改都会生成新的SeqNo。一旦配额agent发现SeqNo发生变化,则会更新本地共享内存。由于agent采用双buffer设计,所以更新完成前不会影响当前业务进程。

(5)抽奖模块

聚焦到抽奖,QQ红包的抽奖算法其实并不复杂,但是能否满足产品需要非常重要。我们的设计思路是至少需要满足如下需求:

  • 可以在秒级别控制现金和每种物品的发放速度;
  • 可以方便调整现金和每种物品的发放比例;
  • 尽量保证红包全部发放出去。

为此,我们设计了如下的抽奖流程算法:

需要说明的是,只要是因为配额限制发放红包失败,我们都会继续尝试给用户发放其他奖品的红包,直到没有奖品可以发放,这样我们就能保证把奖品尽可能发放出去。

(6)流水系统设计

流水系统用于保存活动过程中的抽奖流水记录,在活动后对奖品发放和领用进行统计和对账。该系统还定时对领用失败的请求进行重做和对账,确保奖品发放到用户账户里。

流水系统架构如下:

由于流水需要记录用户中奖的信息和领用的的情况,数据量巨大,所以抽奖逻辑层本地采用顺序写文件的方式进行记录。抽奖逻辑层会定期的把本地的流水文件同步到远程流水系统进行汇总和备份,同时,流水系统会对领用失败的流水进行重做,发送请求到抽奖逻辑层,抽奖逻辑层会调用发货系统的接口完成发货操作。

(7)存储层选型

存储层的设计向来都是后台架构设计中的重点和难点。目前腾讯公司内部较成熟的NoSQL存储系统有CKV、Grocery,经过一番对比我们选择使用Grocery,主要原因有以下几点:

强大的带条件判断的分布式原子算数运算

抽奖逻辑里需要对每个奖品进行计数,避免多发少发,所以一个高效可靠的分布式原子加计数器显得格外重要,Grocery支持带条件判断的原子加计数器,调用一次接口就能完成奖品计数值与配额的判断以及奖品计数值的增加;

灵活的数据类型

Grocery支持Key-Key-Row类型的数据存储格式,可以灵活的存储用户的红包中奖信息,为获取用户单个红包或者红包列表提供了丰富的接口;

部署、扩容方便

Grocery有专门的团队支持,易于部署和扩容。

平滑限频设计

每一种奖品,对应的业务都有他们自己的容量能力,且各业务的能力也不尽相同(如黄钻4w/s,京东2k/s等)。为保证红包活动持续进行,抽奖系统必须严格按业务控制派发峰值。派发峰值支持实时可调,避免由于业务方评估不足引起过载。

考虑这样一种场景,如果请求是在1秒的最开始全部涌到业务方,受限于业务方不同的架构实现,有可能会触发业务方的频率限制或者是过载保护。为此,我们将频限粒度调整到百毫秒,这样奖品就会在1秒内相对平均的发放,从而解决了上述问题。

3.QQ红包发货系统

QQ红包奖品包括现金和礼券两类,现金对接财付通,礼券又分腾讯公司内部虚拟物品和第三方礼券。最终礼品落地到用户的账户(QQ钱包余额、QQ卡券或第三方系统账户)中。虽然抽奖系统有作平滑处理,但持续长时间的大流量发货,也可能导致业务系统不能正常提供峰值下的服务能力。如何承上启下,既预防抽奖系统不能平滑地发货导致压跨发货系统(自身),又能保护后端业务系统的情况下,以较快的速度将奖品安全发放到账,是发货系统的设计要点。发货系统设计遵循以下策略:

  • 快慢分离
  • 异步削峰
  • 柔性处理
  • 保护业务系统
  • 最终一致性

发货系统架构如下图所示:

快慢分离

现金和礼券后端的系统完全不同,现金通过QQ钱包系统发放入财付通账户,要求实时到账不能延迟。而礼券对接的后端业务千差万别,服务容量和性能各不相同。为了不让慢速的礼券发放影响快速的现金发放,将现金通道与礼券通道分离,互不干扰。

异步削峰

由于用户来抽奖的时机完全是随机的,抽奖系统并不能做到绝对平滑发货。任由抽奖系统将发货请求直接透传到业务系统,将出现不可预知的问题,严重时可能会导致业务系统雪崩,这是不能接受的。另外象游戏礼包类、滴滴券等第三方礼券,可能用户账户并不存在(用户并不玩该款游戏,或用户并没有第三方账户),需要先引导用户创建账户才能发货,这就要求发货系统有暂存奖品信息,具备延后发货的能力。

发货系统采用开源的RocketMQ消息中间件作为异步消息队列,暂存发货请求,再由礼券发货模块根据各业务的限速配置均匀地调用业务接口进行发货。

柔性处理

礼券类奖品通过异步方式发放到用户账户,在除夕高峰值可能发放速度跟不上抽奖速度,会延后一些时间才能到账,这对不明真相用户可能会造成困扰。因此在用户中奖信息页面中,会提示用户24小时(或48小时)到账。发货过程的每个步骤,都有可以异常失败,导致发货不成功,因此在物品详细页面的按钮支持多次发起发货,在“礼券发货”模块根据发货状态,可以多次尝试发货,并保证一个奖品只发放一次。

保护业务系统

前面已经提过,发货系统通过异步消息队列,将抽奖系统与业务开发隔离开,抽奖洪峰不会直接影响业务系统,对业务系统起来隔离保护作用。

礼券发货模块针对每个业务单独配置限速阈值,对各业务的发货严格以不超过限速阈值的速度发放奖品,如果业务有超时或提示超速,再按一定比较再减速。

礼券发货模块首先会到存储系统检查奖品是否真实有效,再到发货状态存储检查状态是否正常,只有真正需要的发货的奖品才向业务系统发起发货请求,确保发货的有效性,避免错发和多发。

最终一致性

由于采用异步发货,抽奖时刻奖品不能保证立即发放到用户账户中。但用户的奖品不会丢失,通过在异步队列中暂存,礼券发货模块逐步以合适的速度将奖品发放到用户账户中。

如果发货过程中有延时或失败,用户可以通过多次领取提起发货请求,系统支持多次提交。

如果多次发货仍然失败,对账工具第2天会从流水系统中将用户抽奖数据与发货数据进行对账,对发货异常用户再次发起发货。如果对账仍然失败,则提醒管理人员介入处理。

二、手Q终端的优化策略

普通用户不会关心QQ红包的后台有多复杂,他们在手Q终端抢红包时的体验直接决定着用户对QQ红包的评价。对用户来说,看到红包后能否顺畅的抢和刷,是最直接的体验痛点,因此需要尽可能降低延迟以消除卡顿体验,甚至在弱网环境下,也要能有较好的体验。为了实现该目标,手Q终端采取了以下优化策略:

1.资源预加载

QQ红包中用到的不经常变化的静态资源,如页面,图片,JS等,会分发到各地CDN以提高访问速度,只有动态变化的内容,才实时从后台拉取。然而即使所有的静态资源都采用了CDN分发,如果按实际流量评估,CDN的压力仍然无法绝对削峰。因为同时访问红包页面的人数比较多,按83万/秒的峰值,一个页面按200K评估,约需要158.3G的CDN带宽,会给CDN带来瞬间很大的压力。为减轻CDN压力,QQ红包使用了手Q离线包机制提前把红包相关静态资源预加载到手Q终端,这样可大大降低CDN压力。

目前手Q离线包有两种预加载方式:

  • 将静态资源放入预加载列表,用户重新登录手Q时监测离线包是否有更新并按需加载(1天能覆盖60%,2天能覆盖80%,适合预热放量情况)。
  • 主动推送离线包,向当前在线用户推送离线包。(2个小时可以完成推送,覆盖总量的40%左右,适合紧急情况)通过离线包预加载后,除夕当天的CDN流量并没有出现异常峰值,比较平稳。

2.缓存和延时

2.59 亿用户同时在线,用户刷一刷时的峰值高达83万/秒,如果这些用户的操作请求全部同时拥向后台,即使后台能抗得住,需要的带宽、设备资源成本也是天文数字。为了尽可能减轻后台服务器压力,根据用户刷一刷的体验,用户每次刷的操作都向后台发起请求是没有必要的,因此手Q在终端对用户刷一刷的操作进行计数,定时(1~3秒)异步将汇总数据提交到后台抽奖,再将抽奖结果回传到手Q终端显示。这样既保证了“刷”的畅快体验,也大大减轻后台压力,抽奖结果也在不经意间生产,用户体验完全无损。

3.错峰

对用户进行分组,不同组的用户刷一刷红包(企业明星红包、AR红包等)的开始时间并不相同,而是错开一段时间(1~5分钟),这样通过错开每一轮刷红包的开始时间,可以有效平滑用户刷一刷的请求峰值。

4.动态调整

手Q终端和后台并不是两个孤立的系统,而是一个整体。手Q系统搭建有一整套的负载监控体系,当后台负载升高到警戒线时,手Q终端可以根据后台负载情况,动态减少发向后台的请求,以防止后台出现超载而雪崩。

5.总量限制和清理

在刷一刷红包和AR红包过程中,当用户已经抽中的奖品数达到一个限值(例如5个),用户不能再中奖,这时用户的抽奖请求不再向后台发送,而是终端直接告知用户“未中奖,请稍后再试”,和清除AR红包地图中的红包显示。

接下文《QQ 红包技术方案全解密 (二)》

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据小魔方

左手用R右手Python系列——百度地图API调用与地址解析/逆解析

地理位置信息的解析与逆解析可能是我们在分析地理位置数据时所面临的最棘手的问题了,好在现在很多主流的在线 地图厂商地给开发者提供了免费的API接口调用。 这一篇以...

3837
来自专栏技术翻译

用于在所有级别上构建微服务的29个顶级工具

关于微服务有很多很棒的文章。对于那些一直没有接受微服务的人,或者新手,本文是为了提供顶级开源工具的整合。微服务架构,或仅微服务,是用于开发软件系统的高度可扩展的...

772
来自专栏安智客

Google的TEEOS----Trusty

前面聊了许多厂商的TEE实现,当然少不了Google! 目前各个厂商通常会在此ARM TrustZone基础上各自实现自己的TEE OS系统,对Rich OS的...

2847
来自专栏喵了个咪的博客空间

Kubernetes(一) - Docker管理工具

1143

Docker 的五大优点:持续部署、版本控制、可移植性、隔离性和安全性

我相信 Docker 不需要我过多介绍,它是目前最热门的开源项目之一。您可以使用 Docker 在容器中添加一个抽象层以部署不同的应用程序。在 Docker 生...

3118
来自专栏编程坑太多

『中级篇』Kubenetes简介(60)

PS:了解我的老铁都知道,概念讲的少,更多重在实践,通过实践更好的理解概念,从下次开始怼k8s的环境和集群。如果跟我一起学的老铁,应该可以感受的到,在学习doc...

1113
来自专栏CSDN技术头条

如何解决容器网络性能及复杂网络部署问题?

近两年,容器已经随着 Docker 技术的传播火遍全球,现在已经有越来越多的企业用户在开发、测试甚至生产环境中开始采用 Docker 等容器技术。 然而,目前主...

32710

分布式系统的架构问题

原文地址:https://dzone.com/articles/architecture-concerns-for-distributed-systems

19510

从架构的角度看分布式系统

应用程序架构正在从一个大而全的模型逐步发展为一个更加分布式的模型。这个变化的关键动力来源之一是云计算的到来及因此而拥有的不断增长的计算规模。对于一个主要从事构建...

1887
来自专栏云计算

OpenShift的容器镜像(第1部分):目标

本文来源于2017 EMEA (Europe, the Middle East and Africa,欧洲,中东和非洲) 红帽技术交流会议的会议记录,与会者包括...

2006

扫码关注云+社区