qq红包怎么领

QQ红包技术⽅案全解密

原作者：许灵锋，周海发，InfoQ

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

QQ春节红包以⼀个⼜⼀个的整点刷红包活动贯穿年三⼗，在除⼣夜达到顶峰，是典型的海量⽤户秒杀场景，如何应对海量的⽤户刷红包洪

流，保证刷得爽，红包安全到账，是QQ红包设计要解决的关键技术难点。

另外，红包项⽬涉及⼿Q终端、⼿Q后台、QQ钱包（财付通）系统、礼券系统、公众号等诸多业务系统，流程长且多，各系统性能吞吐量差

异很⼤，如何保证各系统形成⼀个有机整体，协调⾼效提供服务，也是难点之⼀。

下图为简化后QQ红包的架构，包括接⼊层、抽奖系统、存储系统、发货系统、公众号消息通知和CDN资源等⼏部分，请⼤家先有⼀个整体

的认知，便于阅读下⽂。

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

接⼊层

接⼊层是红包后台服务的⼤门，负责抽奖请求预处理，确保有效的请求才透传给后端服务。为保证⾃⾝⾼可⽤、⾼稳定，接⼊层还可实时控

制⼿Q请求频率，避免海量请求压垮接⼊层，出现不可控局⾯。

在海量服务场景下，为避免⽹络开销，⽅便后端服务使⽤cache提升性能，接⼊层采⽤了⼀致性Hash寻址，保证同⼀个⽤户的请求只会落

在同⼀台红包抽奖逻辑机器处理。

抽奖系统

抽奖系统作为QQ红包的核⼼系统，在承接⽤户抽奖请求，按设计合理的⼏率完成抽奖操作，将抽奖结果安全落地保存，并顺利发货等过程

中，起到了关键作⽤。⾯对海量抽奖请求，如何及时作出响应，是抽奖系统⾯临的难题。

为了解决这些问题，我们采⽤了⼀些设计⽅法：

在接⼊层采⽤⼀致性Hash算法，同⼀⽤户的抽奖请求只会转发到相同的抽奖系统处理;

抽奖系统采⽤缓存机制，在加快抽奖过程的同时也减少了对存储层的访问压⼒；奖品配额机制，平滑抽奖过程，各类奖品按⽐例有序

抽中；

流⽔和对账机制，保证抽奖数据最终⽆差错发放到⽤户账户中；

抽奖系统的架构如下图所⽰：

缓存机制

业务要求在每个刷⼀刷的活动中，能对⽤户中奖次数、参与时间（30秒）进⾏限制。如果⽤户的每个抽奖请求到来时，先到存储层获取⽤

户的中奖历史信息，再判定⽤户是否还有抽奖资格，在海量⾼并发的请求场景下，势必会对存储层造成巨⼤的压⼒。

所以这⾥我们引⼊了本地内存缓存层，⽤于保存⽤户的中奖历史信息，每次请求到来时，会先到缓存层获取⽤户的中奖历史信息，如果在缓

存层没找到，才会到存储层获取，这样就不会对存储层造成太⼤的压⼒，同时也能实现业务的需求。

缓存层我们采⽤开源Memcached组件实现。

⼀致性hash寻址

红包抽奖系统是⼀个分布式的系统，因此为了使缓存机制⽣效，我们在⼿Q接⼊层使⽤了⼀致性hash的路由算法进⾏寻址，保证同⼀个⽤户

（uin）的请求总会落在同⼀台逻辑机器进⾏处理。

协议处理模块

由于⼿Q后台既要处理客户端的⼆进制请求，也要处理其他Web系统的HTTP请求，所以协议处理模块的⾸要任务就是兼容各种格式的协

议，给后端模块⼀个最简单的结构。为此我们制定了Protobuf格式的交互协议（兼容JSON格式，会统⼀转换成Protobuf处理），传给后

端模块。

配额管理模块

⼿Q春节红包是通过很多场定时“活动”来发放红包的。每场活动⾥⾯能发放多少现⾦，能发放多少虚拟物品，发放的⽐例如何，这些都是

配额数据。

更进⼀步，我们要做到精确控制现⾦和虚拟物品的发放速度，使得⽆论何时⽤户来参加活动，都有机会获得红包，⽽不是所有红包在前⼏分

钟就被⽤户横扫⼀空。

抽奖模块

聚焦到抽奖，QQ红包的抽奖算法其实并不复杂，但是能否满⾜产品需要⾮常重要。我们的设计思路是⾄少需要满⾜如下需求：

可以在秒级别控制现⾦和每种物品的发放速度

可以⽅便调整现⾦和每种物品的发放⽐例；

尽量保证红包全部发放出去。

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

需要说明的是，只要是因为配额限制发放红包失败，我们都会继续尝试给⽤户发放其他奖品的红包，直到没有奖品可以发放，这样我们就能

保证把奖品尽可能发放出去。

流⽔系统设计

流⽔系统⽤于保存活动过程中的抽奖流⽔记录，在活动后对奖品发放和领⽤进⾏统计和对账。该系统还定时对领⽤失败的请求进⾏重做和对

账，确保奖品发放到⽤户账户⾥。

流⽔系统架构如下：

由于流⽔需要记录⽤户中奖的信息和领⽤的的情况，数据量巨⼤，所以抽奖逻辑层本地采⽤顺序写⽂件的⽅式进⾏记录。

抽奖逻辑层会定期的把本地的流⽔⽂件同步到远程流⽔系统进⾏汇总和备份，同时，流⽔系统会对领⽤失败的流⽔进⾏重做，发送请求到抽

奖逻辑层，抽奖逻辑层会调⽤发货系统的接⼝完成发货操作。

存储层选型

存储层的设计向来都是后台架构设计中的重点和难点。⽬前腾讯公司内部较成熟的NoSQL存储系统有CKV、Grocery，经过⼀番对⽐我们

选择使⽤Grocery，主要原因有以下⼏点：

强⼤的带条件判断的分布式原⼦算数运算

抽奖逻辑⾥需要对每个奖品进⾏计数，避免多发少发，所以⼀个⾼效可靠的分布式原⼦加计数器显得格外重要，Grocery⽀持带条件判断的

原⼦加计数器，调⽤⼀次接⼝就能完成奖品计数值与配额的判断以及奖品计数值的增加；

灵活的数据类型

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

接⼝；

部署、扩容⽅便

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

平滑限频设计

每⼀种奖品，对应的业务都有他们⾃⼰的容量能⼒，且各业务的能⼒也不尽相同（如黄钻4w/s，京东2k/s等）。为保证红包活动持续进

⾏，抽奖系统必须严格按业务控制派发峰值。派发峰值⽀持实时可调，避免由于业务⽅评估不⾜引起过载。

考虑这样⼀种场景，如果请求是在1秒的最开始全部涌到业务⽅，受限于业务⽅不同的架构实现，有可能会触发业务⽅的频率限制或者是过

载保护。为此，我们将频限粒度调整到百毫秒，这样奖品就会在1秒内相对平均的发放，从⽽解决了上述问题。

QQ红包发货系统

QQ红包奖品包括现⾦和礼券两类，现⾦对接财付通，礼券⼜分腾讯公司内部虚拟物品和第三⽅礼券。最终礼品落地到⽤户的账户（QQ钱包

余额、QQ卡券或第三⽅系统账户）中。虽然抽奖系统有作平滑处理，但持续长时间的⼤流量发货，也可能导致业务系统不能正常提供峰值

下的服务能⼒。

如何承上启下，既预防抽奖系统不能平滑地发货导致压跨发货系统（⾃⾝），⼜能保护后端业务系统的情况下，以较快的速度将奖品安全发

放到账，是发货系统的设计要点。

发货系统设计遵循以下策略：

快慢分离

异步削峰

柔性处理

保护业务系统

最终⼀致性

发货系统架构如下图所⽰：

快慢分离

现⾦和礼券后端的系统完全不同，现⾦通过QQ钱包系统发放⼊财付通账户，要求实时到账不能延迟。

⽽礼券对接的后端业务千差万别，服务容量和性能各不相同。为了不让慢速的礼券发放影响快速的现⾦发放，将现⾦通道与礼券通道分离，

互不⼲扰。

异步削峰

由于⽤户来抽奖的时机完全是随机的，抽奖系统并不能做到绝对平滑发货。任由抽奖系统将发货请求直接透传到业务系统，将出现不可预知

的问题，严重时可能会导致业务系统雪崩，这是不能接受的。

另外象游戏礼包类、滴滴券等第三⽅礼券，可能⽤户账户并不存在（⽤户并不玩该款游戏，或⽤户并没有第三⽅账户），需要先引导⽤户创

建账户才能发货，这就要求发货系统有暂存奖品信息，具备延后发货的能⼒。

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

⼝进⾏发货。

柔性处理

礼券类奖品通过异步⽅式发放到⽤户账户，在除⼣⾼峰值可能发放速度跟不上抽奖速度，会延后⼀些时间才能到账，这对不明真相⽤户可能

会造成困扰。因此在⽤户中奖信息页⾯中，会提⽰⽤户24⼩时（或48⼩时）到账。

发货过程的每个步骤，都有可以异常失败，导致发货不成功，因此在物品详细页⾯的按钮⽀持多次发起发货，在“礼券发货”模块根据发货

状态，可以多次尝试发货，并保证⼀个奖品只发放⼀次。

保护业务系统

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

⽤。

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

⼀定⽐较再减速。

礼券发货模块⾸先会到存储系统检查奖品是否真实有效，再到发货状态存储检查状态是否正常，只有真正需要的发货的奖品才向业务系统发

起发货请求，确保发货的有效性，避免错发和多发。

最终⼀致性

由于采⽤异步发货，抽奖时刻奖品不能保证⽴即发放到⽤户账户中。但⽤户的奖品不会丢失，通过在异步队列中暂存，礼券发货模块逐步以

合适的速度将奖品发放到⽤户账户中。

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

如果多次发货仍然失败，对账⼯具第2天会从流⽔系统中将⽤户抽奖数据与发货数据进⾏对账，对发货异常⽤户再次发起发货。如果对账仍

然失败，则提醒管理⼈员介⼊处理。

⼿Q终端的优化策略

普通⽤户不会关⼼QQ红包的后台有多复杂，他们在⼿Q终端抢红包时的体验直接决定着⽤户对QQ红包的评价。对⽤户来说，看到红包后能

否顺畅的抢和刷，是最直接的体验痛点，因此需要尽可能降低延迟以消除卡顿体验，甚⾄在弱⽹环境下，也要能有较好的体验。

为了实现该⽬标，⼿Q终端采取了以下优化策略：

资源预加载

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.59亿⽤户同时在线，⽤户刷⼀刷时的峰值⾼达83万/秒，如果这些⽤户的操作请求全部同时拥向后台，即使后台能抗得住，需要的带

宽、设备资源成本也是天⽂数字。

为了尽可能减轻后台服务器压⼒，根据⽤户刷⼀刷的体验，⽤户每次刷的操作都向后台发起请求是没有必要的，因此⼿Q在终端对⽤户刷⼀

刷的操作进⾏计数，定时（1~3秒）异步将汇总数据提交到后台抽奖，再将抽奖结果回传到⼿Q终端显⽰。

这样既保证了“刷”的畅快体验，也⼤⼤减轻后台压⼒，抽奖结果也在不经意间⽣产，⽤户体验完全⽆损。

错峰

对⽤户进⾏分组，不同组的⽤户刷⼀刷红包（企业明星红包、AR红包等）的开始时间并不相同，⽽是错开⼀段时间（1~5分钟），这样通

过错开每⼀轮刷红包的开始时间，可以有效平滑⽤户刷⼀刷的请求峰值。

动态调整

⼿Q终端和后台并不是两个孤⽴的系统，⽽是⼀个整体。⼿Q系统搭建有⼀整套的负载监控体系，当后台负载升⾼到警戒线时，⼿Q终端可

以根据后台负载情况，动态减少发向后台的请求，以防⽌后台出现超载⽽雪崩。

总量限制和清理

在刷⼀刷红包和AR红包过程中，当⽤户已经抽中的奖品数达到⼀个限值（例如5个），⽤户不能再中奖，这时⽤户的抽奖请求不再向后台发

送，⽽是终端直接告知⽤户“未中奖，请稍后再试”，和清除AR红包地图中的红包显⽰。

红包创新玩法挑战

春节红包⼤战，从企业红包演变到刷⼀刷红包、个性化红包和AR红包，玩法不断创新，⽤户体验更好，活跃度提升，参与⼈数也从2亿增长

到17年春节的3.42亿。

个性化红包

QQ个性红包是在红包外观上的⼀次⼤胆尝试，借助该功能，⽤户可使⽤霸⽓的书法体将⾃⼰的姓⽒／或其他⽂字（提供⾃动简繁体转换）

镌刻在红包封⽪上。

此外，我们还提供了具有新年氛围的贺岁红包、与腾讯IP紧密结合的QQfamily、游戏形象、动漫形象等卡通红包，⼤⼤提⾼了QQ红包的

趣味性与观赏性。

个性红包功能上线后，有超过30%的红包⽤户选择使⽤个性红包。

在2016年春节期间共有1500万⽤户使⽤该功能，2016年除⼣当晚突破8千万的个性红包发送量。

个性红包在普通基础上，允许⽤户修改红包封⽪，展⽰个性，应合场景，因此设计的要点是使⽤户操作顺畅，既保持发、抢红包的流畅体

验，⼜能显⽰个性和有趣好玩。

个性化红包流程架构如下图所⽰：

从上图可以看出，简化后的红包的发放过程经历红包终端->财付通->红包后台->⼿QAIO（聊天交互窗⼝）->拆（抢）红包页⾯等过程，流程

较长（忽略了⼀些细节，实际流程更复杂），在这些步骤过程中如果每⼀步都⾛后台判断个性化红包状态，必然影响到红包的发放流畅性。

为了尽量不影响⽤户发红包体验，个性化红包在架构和运营上作了很多解藕和柔性设计。包括个性字体提前绘制，资源预加载，功能开关和

容灾柔性处理等。

字体提前绘制

个性化红包⽀持所有简体与繁体汉字，并⽀持部分简体汉字转换成繁体汉字，为了改善使⽤“姓⽒红包”⽤户的体验，我们把常⽤的300个

姓⽒，使⽤预⽣成的⽅式，在⽤户⼿Q空闲的时候⽣成常⽤的姓⽒图⽚保存到本地。其他的⾮常⽤姓⽒，在展⽰的时候合成，合成⼀次保存

在本地，下次在本地读取。

⼿Q终端在空闲时绘制好字体贴图，⽀持定时更新背景图和字体库，对⾮常⽤字，则启动个性化字体引擎⽣成对应的个性化贴图。

⽤户在发放或收到红包时，个性化背景和字体贴图已经⽣成好，不需要再⽣成，收发红包流畅体验⽆损。

资源预加载

个性化红包封素材提前制作好，上传到CDN⽹络，⼿Q在空闲时提前从CDN下载素材⽂件，并定时检查素材更新情况，及时更新。

功能开关

⽤户是否设置个性红包，选择的个性红包贴图样式，是否启⽤个性红包等信息，如果每次判断都从后台拉取，势必增加后台压⼒。⽤户对个

性红包的设置信息，其实变化不⼤，并且访问红包商场实时设置的状态的结果在⼿Q终端是存在的。因此我们设计将这些⽤户状态FLAG在

⼿Q登录时，从后台拉取⼀次后保存在⼿Q终端，在发红包的过程中将FLAG信息传递到下游服务中，通过红包商城设置的个性化红包标

志，实时更新⼿Q本地配置。

这样的设计有⼏个好处:

⽤户的个性化设置不再依赖于后台，发红包过程完全本地操作，没有任何延时，不影响红包的发放。

FLAG标志可以作为容灾开关，如果临时取消个性红包，或后台故障，可以临时屏蔽个性红包功能，恢复为默认红包样式，保障任何时

刻红包功能正常可⽤。

FLAG标志可⽀持扩展，在红包后台可以根据扩展，⽀持付费红包样式（付费购买）、特权红包样式（如超会专享）等，⽀持红包商城

扩展各种各样的个性化红包。

除了从后台拉取FLAG，当业务有调整导致FLAG变化，红包后台可以向⼿Q终端主动pushFLAG状态，使得⽤户及时感知变化，进⼀

步增强⽤户使⽤体验。

容灾柔性处理

相对于⼿Q平台功能，个性红包系统相对独⽴，运营和更新很快，系统各功能组件出现问题的⼏率可能较多，如果个性红包业务出现问题，

⽽影响到正常红包发放或⼿Q功能的使⽤，会对QQ⼝碑造成很⼤负⾯影响。我们在系统中设计了多处容灾和柔性处理措施，在个性红包业

务异常时，能降级提供服务，最差时取消个性红包功能。

柔性措施⼀：⽤户登录时拉取个性红包FLAG失败时，采⽤默认红包样式。

柔性措施⼆：红包后台向个性化红包后台拉取个性化设置鉴权详情（是否付费、是否会员专享等）时，如果拉取异常，采⽤默认红包样式。

柔性措施三：个性化红包由⽤户输⼊姓⽒，指定显⽰⽂字，可能遇到敏感字或需要临时下线，可以通过向⼿Q下发FLAG标志，临时取消个

性红包功能，恢复到默认红包样式。

AR红包

AR红包是“LBS+AR天降红包”的简称，这个创新的玩法得到了⽤户的⼀致好评，参与⽤户2.57亿次，共计领取红包和礼券20.5亿个，

获得了⼝碑和活跃的双丰收。

缓存设计

LBS+AR红包与以往的红包最⼤的不同在于多了⼀重地理位置关联，全国有上千万的地理位置信息，结合活动的任务奖品数据产⽣了海量的

配置数据，⽽这些数据都需要快速实时读取。这是系统设计的⼀⼤挑战。

配置数据有以下特点：

数据量很⼤（亿级），数据间有紧密的关联，我们采⽤MySQL数据库集群存储，并构建有Web可视化配置投放平台，实现⾃动容灾和

备份的功能；

“⼀次配好，到处使⽤”，配置读量远⾼于写量，基本思想是设计开发⼀种缓存，放弃写性能，将读性能优化到极致。

上千兆的配置数据，如何供抽奖系统快速检索？考虑到业务使⽤场景、配置数据⼤⼩及MySQL性能，可以采⽤预先构建全量缓存并进⾏有

序组织，由同步模块负责将构建好的配置数据同步到抽奖系统，供业务进程直接使⽤。为保证配置数据完整性，构建缓存采⽤双Buffer设

计，只有构建或同步完成后才切换到最新配置。

地图打点与查点

基于LBS的红包活动离不开地理位置相关的业务交互。在AR红包中，⽤户打开地图会定期向后台上报坐标，后台需要根据坐标获取周围可

⽤的活动任务投放点，投放点事先都会进⾏安全筛查，去掉具有安全隐患的区域，避免给⽤户带来⼈⾝安全问题，本节主要介绍如何管理这

些投放点。

地图格⼦

将整个⼆维平⾯根据坐标分成边长相等的正⽅形格⼦，根据⽤户的坐标⽤简单的数学运算即可获取相应的格⼦ID，时间复杂度O(1)。⼀个格

⼦是⼀次查询的最⼩粒度。每次查询会返回以⽤户为中⼼周围5*5共计25个格⼦的任务点。

打点

红包是以任务维度投放的，每个任务关联⼀个POI集合，每个POI集合中包含⼏个到上百万不等的POI点，每个POI点都有⼀个经纬度信息。

打点即是事先建⽴格⼦到任务列表的映射。所有格⼦数据有序组织并存储在共享内存⾥，使⽤⼆分查找提升读性能。

查点流程

客户端上报经纬度。

根据经纬度计算中⼼格⼦ID。

根据中⼼格⼦ID及半径配置，获取周围格⼦列表。

在打点系统中获得此⽚区域全部POI和任务信息。

检查任务状态后返回给客户端。

采集系统

采集系统主要负责汇总各⾏政区红包发放状态数据，主要提供以下功能：

1.实时返回区级⾏政区红包计数；

2.实时接受主逻辑的查询，返回奖品发放状态；

3.返回活动预告以及参数配置等辅助信息。

由于红包是按⾏政区进⾏投放的，每个⾏政区约投放10个任务，每个任务⼜关联多种类型的红包，如果每次查询区级红包余量时，都实时

计算和汇总红包状态数据，扩散带来的包量开销会⽐较⼤，为此，我们还是采⽤双Buffer缓存来解决该问题，⼀个进程负责将采集到的数据

写到缓存，另⼀组进程提供查询服务。另外，还可以根据存储层的压⼒，适当地调整采集的频率，使得统计数据尽可能实时。