本文来自腾讯QQ技术团队工程师许灵锋、周海发的技术分享。
自 2015 年春节以来，QQ 春节红包经历了企业红包（2015 年）、刷一刷红包（2016 年）和 AR 红包（2017 年）几个阶段，通过不断创新玩法，活跃度节节攀升，成为春节一大玩点，给火红的春节带来一抹亮色。2017 年除夕，AR 红包、刷一刷红包再创新高，抢红包用户数达 3.42 亿，共刷出红包 37.77 亿个。
那么，QQ 红包的技术方案究竟是怎样的？其整体架构如何？重要的系统是如何设计的？为了保证用户的体验，手机 QQ 移动端做了哪些优化？今年的 QQ 红包又做了哪些新的尝试，遇到的问题是如何解决的呢？本文将从架构开始，到手机 QQ 移动端优化，再到个性化红包和 AR 新玩法，为大家全面解密 QQ 红包技术方案。
- 即时通讯/推送技术开发交流4群： [推荐] - 移动端IM开发入门文章：《》
▲ 两位作者，许灵锋（图左者）和周海发（图右者）
turboxu（许灵锋）：2006 年加入腾讯，会员体系后台负责人，从事过 MIS 系统、网络安全、滔滔（空间说说）、WAP 音乐、超 Q、会员等项目，对开源组件、虚拟化感兴趣，致力于推动 Docker 虚拟化和开源组件的应用和实践。
haifazhou（周海发）：2011 年加入腾讯，从事 IM 基础系统开发和运营，先后参与过 PTLogin 统一登录和消息漫游存储改造项目，连续三年参与并负责 QQ 春节红包后台系统架构设计，在海量分布式高性能系统设计方面积累了多年经验。
《》 《》 《》 《》 《》 《》 《》 《》 《》 《》
QQ 春节红包以一个又一个的整点刷红包活动贯穿年三十，在除夕夜达到顶峰，是典型的海量用户秒杀场景，如何应对海量的用户刷红包洪流，保证刷得爽，红包安全到账，是 QQ 红包设计要解决的关键技术难点。另外，红包项目涉及手机 QQ 移动端、手机 QQQ 后台、QQ
钱包（财付通）系统、礼券系统、公众号等诸多业务系统，流程长且多，各系统性能吞吐量差异很大，如何保证各系统形成一个有机整体，协调高效提供服务，也是难点之一。
下图为简化后 QQ 红包的架构，包括：接入层、抽奖系统、存储系统、发货系统、公众号消息通知和 CDN 资源等几部分，请大家先有一个整体的认知，便于阅读下文。
▲ 简化后的QQ红包系统架构
本节将重点讲解接入层、抽奖系统和发货系统。
接入层是红包后台服务的大门，负责抽奖请求预处理，确保有效的请求才透传给后端服务。为保证自身高可用、高稳定，接入层还可实时控制手机 QQ 请求频率，避免海量请求压垮接入层，出现不可控局面。
在海量服务场景下，为避免网络开销，方便后端服务使用 cache 提升性能，接入层采用了一致性 Hash 寻址，保证同一个用户的请求只会落在同一台红包抽奖逻辑机器处理。
抽奖系统作为 QQ 红包的核心系统，在承接用户抽奖请求，按设计合理的几率完成抽奖操作，将抽奖结果安全落地保存，并顺利发货等过程中，起到了关键作用。面对海量抽奖请求，如何及时作出响应，是抽奖系统面临的难题。
为了解决这些问题，我们采用了一些设计方法：
1）在接入层采用一致性 Hash 算法：同一用户的抽奖请求只会转发到相同的抽奖系统处理 ;
2）抽奖系统采用缓存机制：在加快抽奖过程的同时也减少了对存储层的访问压力；
3）奖品配额机制：平滑抽奖过程，各类奖品按比例有序抽中；
4）流水和对账机制：保证抽奖数据最终无差错发放到用户账户中。
抽奖系统的架构如下图所示：
业务要求在每个刷一刷的活动中，能对用户中奖次数、参与时间（30
秒）进行限制。如果用户的每个抽奖请求到来时，先到存储层获取用户的中奖历史信息，再判定用户是否还有抽奖资格，在海量高并发的请求场景下，势必会对存储层造成巨大的压力。所以这里我们引入了本地内存缓存层，用于保存用户的中奖历史信息，每次请求到来时，会先到缓存层获取用户的中奖历史信息，如果在缓存层没找到，才会到存储层获取，这样就不会对存储层造成太大的压力，同时也能实现业务的需求。缓存层我们采用开源
红包抽奖系统是一个分布式的系统，因此为了使缓存机制生效，我们在手机 QQ 接入层使用了一致性 hash 的路由算法进行寻址，保证同一个用户（uin）的请求总会落在同一台逻辑机器进行处理。
由于手机 QQ 后台既要处理客户端的二进制请求，也要处理其他 Web 系统的 HTTP 请求，所以协议处理模块的首要任务就是兼容各种格式的协议，给后端模块一个最简单的结构。为此我们制定了 Protobuf 格式的交互协议（兼容 JSON 格式，会统一转换成 Protobuf 处理），传给后端模块。
手机 QQ 春节红包是通过很多场定时“活动”来发放红包的。每场活动里面能发放多少现金，能发放多少虚拟物品，发放的比例如何，这些都是配额数据。
更进一步，我们要做到精确控制现金和虚拟物品的发放速度，使得无论何时用户来参加活动，都有机会获得红包，而不是所有红包在前几分钟就被用户横扫一空。
配额信息由配额管理工具负责检查和修改，每次修改都会生成新的 SeqNo。一旦配额 agent 发现 SeqNo 发生变化，则会更新本地共享内存。由于 agent 采用双 buffer 设计，所以更新完成前不会影响当前业务进程。
聚焦到抽奖，QQ 红包的抽奖算法其实并不复杂，但是能否满足产品需要非常重要。
我们的设计思路是至少需要满足如下需求：
1）可以在秒级别控制现金和每种物品的发放速度；
2）可以方便调整现金和每种物品的发放比例；
3）尽量保证红包全部发放出去。
为此，我们设计了如下的抽奖流程算法：
需要说明的是，只要是因为配额限制发放红包失败，我们都会继续尝试给用户发放其他奖品的红包，直到没有奖品可以发放，这样我们就能保证把奖品尽可能发放出去。
流水系统用于保存活动过程中的抽奖流水记录，在活动后对奖品发放和领用进行统计和对账。该系统还定时对领用失败的请求进行重做和对账，确保奖品发放到用户账户里。
由于流水需要记录用户中奖的信息和领用的的情况，数据量巨大，所以抽奖逻辑层本地采用顺序写文件的方式进行记录。抽奖逻辑层会定期的把本地的流水文件同步到远程流水系统进行汇总和备份，同时，流水系统会对领用失败的流水进行重做，发送请求到抽奖逻辑层，抽奖逻辑层会调用发货系统的接口完成发货操作。
存储层的设计向来都是后台架构设计中的重点和难点。目前腾讯公司内部较成熟的 NoSQL 存储系统有 CKV、Grocery，经过一番对比我们选择使用 Grocery，主要原因有以下几点。
1）强大的带条件判断的分布式原子算数运算：
抽奖逻辑里需要对每个奖品进行计数，避免多发少发，所以一个高效可靠的分布式原子加计数器显得格外重要，Grocery 支持带条件判断的原子加计数器，调用一次接口就能完成奖品计数值与配额的判断以及奖品计数值的增加。
Grocery 支持 Key-Key-Row 类型的数据存储格式，可以灵活的存储用户的红包中奖信息，为获取用户单个红包或者红包列表提供了丰富的接口。
Grocery 有专门的团队支持，易于部署和扩容。
每一种奖品，对应的业务都有他们自己的容量能力，且各业务的能力也不尽相同（如黄钻 4w/s，京东 2k/s 等）。为保证红包活动持续进行，抽奖系统必须严格按业务控制派发峰值。派发峰值支持实时可调，避免由于业务方评估不足引起过载。
考虑这样一种场景，如果请求是在 1 秒的最开始全部涌到业务方，受限于业务方不同的架构实现，有可能会触发业务方的频率限制或者是过载保护。为此，我们将频限粒度调整到百毫秒，这样奖品就会在 1 秒内相对平均的发放，从而解决了上述问题。
4.3、QQ 红包发货系统
QQ 红包奖品包括现金和礼券两类，现金对接财付通，礼券又分腾讯公司内部虚拟物品和第三方礼券。最终礼品落地到用户的账户（QQ 钱包余额、QQ
卡券或第三方系统账户）中。虽然抽奖系统有作平滑处理，但持续长时间的大流量发货，也可能导致业务系统不能正常提供峰值下的服务能力。如何承上启下，既预防抽奖系统不能平滑地发货导致压跨发货系统（自身），又能保护后端业务系统的情况下，以较快的速度将奖品安全发放到账，是发货系统的设计要点。
发货系统设计遵循以下策略：
发货系统架构如下图所示：
现金和礼券后端的系统完全不同，现金通过 QQ 钱包系统发放入财付通账户，要求实时到账不能延迟。而礼券对接的后端业务千差万别，服务容量和性能各不相同。为了不让慢速的礼券发放影响快速的现金发放，将现金通道与礼券通道分离，互不干扰。
由于用户来抽奖的时机完全是随机的，抽奖系统并不能做到绝对平滑发货。任由抽奖系统将发货请求直接透传到业务系统，将出现不可预知的问题，严重时可能会导致业务系统雪崩，这是不能接受的。另外象游戏礼包类、滴滴券等第三方礼券，可能用户账户并不存在（用户并不玩该款游戏，或用户并没有第三方账户），需要先引导用户创建账户才能发货，这就要求发货系统有暂存奖品信息，具备延后发货的能力。
发货系统采用开源的 RocketMQ 消息中间件作为异步消息队列，暂存发货请求，再由礼券发货模块根据各业务的限速配置均匀地调用业务接口进行发货。
礼券类奖品通过异步方式发放到用户账户，在除夕高峰值可能发放速度跟不上抽奖速度，会延后一些时间才能到账，这对不明真相用户可能会造成困扰。因此在用户中奖信息页面中，会提示用户 24 小时（或 48 小时）到账。发货过程的每个步骤，都有可以异常失败，导致发货不成功，因此在物品详细页面的按钮支持多次发起发货，在“礼券发货”模块根据发货状态，可以多次尝试发货，并保证一个奖品只发放一次。
前面已经提过，发货系统通过异步消息队列，将抽奖系统与业务开发隔离开，抽奖洪峰不会直接影响业务系统，对业务系统起来隔离保护作用。
礼券发货模块针对每个业务单独配置限速阈值，对各业务的发货严格以不超过限速阈值的速度发放奖品，如果业务有超时或提示超速，再按一定比较再减速。
礼券发货模块首先会到存储系统检查奖品是否真实有效，再到发货状态存储检查状态是否正常，只有真正需要的发货的奖品才向业务系统发起发货请求，确保发货的有效性，避免错发和多发。
由于采用异步发货，抽奖时刻奖品不能保证立即发放到用户账户中。但用户的奖品不会丢失，通过在异步队列中暂存，礼券发货模块逐步以合适的速度将奖品发放到用户账户中。
如果发货过程中有延时或失败，用户可以通过多次领取提起发货请求，系统支持多次提交。
如果多次发货仍然失败，对账工具第 2 天会从流水系统中将用户抽奖数据与发货数据进行对账，对发货异常用户再次发起发货。如果对账仍然失败，则提醒管理人员介入处理。
普通用户不会关心 QQ 红包的后台有多复杂，他们在手机QQ移动端抢红包时的体验直接决定着用户对 QQ 红包的评价。对用户来说，看到红包后能否顺畅的抢和刷，是最直接的体验痛点，因此需要尽可能降低延迟以消除卡顿体验，甚至在弱网环境下，也要能有较好的体验。为了实现该目标，手机QQ移动端采取了以下优化策略：
QQ 红包中用到的不经常变化的静态资源，如页面，图片，JS 等，会分发到各地 CDN 以提高访问速度，只有动态变化的内容，才实时从后台拉取。然而即使所有的静态资源都采用了 CDN 分发，如果按实际流量评估，CDN 的压力仍然无法绝对削峰。因为同时访问红包页面的人数比较多，按 83 万 / 秒的峰值，一个页面按 200K 评估，约需要 158.3G 的 CDN 带宽，会给 CDN
带来瞬间很大的压力。为减轻 CDN 压力，QQ 红包使用了手机 QQ 离线包机制提前把红包相关静态资源预加载到手机QQ移动端，这样可大大降低 CDN 压力。
目前手机 QQ 离线包有两种预加载方式：
a. 将静态资源放入预加载列表：用户重新登录手机 QQ 时监测离线包是否有更新并按需加载（1 天能覆盖 60%，2 天能覆盖 80%，适合预热放量情况）；
b. 主动推送离线包：向当前在线用户推送离线包。（2 个小时可以完成推送，覆盖总量的 40% 左右，适合紧急情况）通过离线包预加载后，除夕当天的 CDN 流量并没有出现异常峰值，比较平稳。
2.59 亿用户同时在线，用户刷一刷时的峰值高达 83 万 / 秒，如果这些用户的操作请求全部同时拥向后台，即使后台能抗得住，需要的带宽、设备资源成本也是天文数字。为了尽可能减轻后台服务器压力，根据用户刷一刷的体验，用户每次刷的操作都向后台发起请求是没有必要的，因此手机 QQ 在移动端对用户刷一刷的操作进行计数，定时（1~3 秒）异步将汇总数据提交到后台抽奖，再将抽奖结果回传到手机 QQ
移动端显示。这样既保证了“刷”的畅快体验，也大大减轻后台压力，抽奖结果也在不经意间生产，用户体验完全无损。
对用户进行分组，不同组的用户刷一刷红包（企业明星红包、AR 红包等）的开始时间并不相同，而是错开一段时间（1~5 分钟），这样通过错开每一轮刷红包的开始时间，可以有效平滑用户刷一刷的请求峰值。
手机 QQ 移动端和后台并不是两个孤立的系统，而是一个整体。手机 QQ 系统搭建有一整套的负载监控体系，当后台负载升高到警戒线时，手机 QQ 移动端可以根据后台负载情况，动态减少发向后台的请求，以防止后台出现超载而雪崩。
在刷一刷红包和 AR 红包过程中，当用户已经抽中的奖品数达到一个限值（例如 5 个），用户不能再中奖，这时用户的抽奖请求不再向后台发送，而是移动端直接告知用户“未中奖，请稍后再试”，和清除 AR 红包地图中的红包显示。
春节红包大战，从企业红包演变到刷一刷红包、个性化红包和 AR 红包，玩法不断创新，用户体验更好，活跃度提升，参与人数也从 2 亿增长到 17 年春节的 3.42 亿。
QQ 个性红包是在红包外观上的一次大胆尝试，借助该功能，用户可使用霸气的书法体将自己的姓氏／或其他文字（提供自动简繁体转换）镌刻在红包封皮上。此外，我们还提供了具有新年氛围的贺岁红包、与腾讯 IP 紧密结合的 QQ family、游戏形象、动漫形象等卡通红包，大大提高了 QQ 红包的趣味性与观赏性。个性红包功能上线后，有超过 30% 的红包用户选择使用个性红包。在 2016
年春节期间共有 1500 万用户使用该功能，2016 年除夕当晚突破 8 千万的个性红包发送量。
个性红包在普通基础上，允许用户修改红包封皮，展示个性，应合场景，因此设计的要点是使用户操作顺畅，既保持发、抢红包的流畅体验，又能显示个性和有趣好玩。
个性化红包流程架构如下图所示：
从上图可以看出，简化后的红包的发放过程经历红包移动端 -> 财付通 -> 红包后台 -> 手机 QQ AIO（聊天交互窗口）-> 拆（抢）红包页面等过程，流程较长（忽略了一些细节，实际流程更复杂），在这些步骤过程中如果每一步都走后台判断个性化红包状态，必然影响到红包的发放流畅性。
为了尽量不影响用户发红包体验，个性化红包在架构和运营上作了很多解藕和柔性设计。包括个性字体提前绘制，资源预加载，功能开关和容灾柔性处理等。
个性化红包支持所有简体与繁体汉字，并支持部分简体汉字转换成繁体汉字，为了改善使用“姓氏红包”用户的体验，我们把常用的 300 个姓氏，使用预生成的方式，在用户手机 QQ 空闲的时候生成常用的姓氏图片保存到本地。其他的非常用姓氏，在展示的时候合成，合成一次保存在本地，下次在本地读取。
手机 QQ 移动端在空闲时绘制好字体贴图，支持定时更新背景图和字体库，对非常用字，则启动个性化字体引擎生成对应的个性化贴图。
用户在发放或收到红包时，个性化背景和字体贴图已经生成好，不需要再生成，收发红包流畅体验无损。
个性化红包封素材提前制作好，上传到 CDN 网络，手机 QQ 在空闲时提前从 CDN 下载素材文件，并定时检查素材更新情况，及时更新。
用户是否设置个性红包，选择的个性红包贴图样式，是否启用个性红包等信息，如果每次判断都从后台拉取，势必增加后台压力。用户对个性红包的设置信息，其实变化不大，并且访问红包商场实时设置的状态的结果在手机 QQ 移动端是存在的。因此我们设计将这些用户状态 FLAG 在手机 QQ 登录时，从后台拉取一次后保存在手机 QQ 移动端，在发红包的过程中将 FLAG
信息传递到下游服务中，通过红包商城设置的个性化红包标志，实时更新手机 QQ本地配置。
这样的设计有几个好处：
1）用户的个性化设置不再依赖于后台，发红包过程完全本地操作，没有任何延时，不影响红包的发放；
2）FLAG 标志可以作为容灾开关，如果临时取消个性红包，或后台故障，可以临时屏蔽个性红包功能，恢复为默认红包样式，保障任何时刻红包功能正常可用；
3）FLAG 标志可支持扩展，在红包后台可以根据扩展，支持付费红包样式（付费购买）、特权红包样式（如超会专享）等，支持红包商城扩展各种各样的个性化红包；
4）除了从后台拉取 FLAG，当业务有调整导致 FLAG 变化，红包后台可以向手机 QQ 移动端主动 push FLAG 状态，使得用户及时感知变化，进一步增强用户使用体验。
相对于手机 QQ 平台功能，个性红包系统相对独立，运营和更新很快，系统各功能组件出现问题的几率可能较多，如果个性红包业务出现问题，而影响到正常红包发放或手机 QQ 功能的使用，会对 QQ 口碑造成很大负面影响。我们在系统中设计了多处容灾和柔性处理措施，在个性红包业务异常时，能降级提供服务，最差时取消个性红包功能。
柔性措施一：用户登录时拉取个性红包 FLAG 失败时，采用默认红包样式；
柔性措施二：红包后台向个性化红包后台拉取个性化设置鉴权详情（是否付费、是否会员专享等）时，如果拉取异常，采用默认红包样式；
柔性措施三：个性化红包由用户输入姓氏，指定显示文字，可能遇到敏感字或需要临时下线，可以通过向手机 QQ 下发 FLAG 标志，临时取消个性红包功能，恢复到默认红包样式。
AR 红包是“LBS+AR 天降红包”的简称，这个创新的玩法得到了用户的一致好评，参与用户 2.57 亿次，共计领取红包和礼券 20.5 亿个，获得了口碑和活跃的双丰收。
LBS+AR 红包与以往的红包最大的不同在于多了一重地理位置关联，全国有上千万的地理位置信息，结合活动的任务奖品数据产生了海量的配置数据，而这些数据都需要快速实时读取。这是系统设计的一大挑战。
1）数据量很大（亿级），数据间有紧密的关联，我们采用 MySQL 数据库集群存储，并构建有 Web 可视化配置投放平台，实现自动容灾和备份的功能；
2）“一次配好，到处使用”，配置读量远高于写量，基本思想是设计开发一种缓存，放弃写性能，将读性能优化到极致。
上千兆的配置数据，如何供抽奖系统快速检索？考虑到业务使用场景、配置数据大小及 MySQL 性能，可以采用预先构建全量缓存并进行有序组织，由同步模块负责将构建好的配置数据同步到抽奖系统，供业务进程直接使用。为保证配置数据完整性，构建缓存采用双 Buffer 设计，只有构建或同步完成后才切换到最新配置。
6.2.3 地图打点与查点
基于 LBS 的红包活动离不开地理位置相关的业务交互。在 AR 红包中，用户打开地图会定期向后台上报坐标，后台需要根据坐标获取周围可用的活动任务投放点，投放点事先都会进行安全筛查，去掉具有安全隐患的区域，避免给用户带来人身安全问题，本节主要介绍如何管理这些投放点。
将整个二维平面根据坐标分成边长相等的正方形格子，根据用户的坐标用简单的数学运算即可获取相应的格子 ID，时间复杂度 O(1)。一个格子是一次查询的最小粒度。每次查询会返回以用户为中心周围 5*5 共计 25 个格子的任务点。
红包是以任务维度投放的，每个任务关联一个 POI 集合，每个 POI 集合中包含几个到上百万不等的 POI 点，每个 POI 点都有一个经纬度信息。
打点即是事先建立格子到任务列表的映射。所有格子数据有序组织并存储在共享内存里，使用二分查找提升读性能。
1） 客户端上报经纬度；
2） 根据经纬度计算中心格子 ID；
3） 根据中心格子 ID 及半径配置，获取周围格子列表；
4） 在打点系统中获得此片区域全部 POI 和任务信息；
5） 检查任务状态后返回给客户端。
采集系统主要负责汇总各行政区红包发放状态数据，主要提供以下功能：
1）实时返回区级行政区红包计数；
2）实时接受主逻辑的查询，返回奖品发放状态；
3）返回活动预告以及参数配置等辅助信息。
由于红包是按行政区进行投放的，每个行政区约投放 10 个任务，每个任务又关联多种类型的红包，如果每次查询区级红包余量时，都实时计算和汇总红包状态数据，扩散带来的包量开销会比较大，为此，我们还是采用双 Buffer 缓存来解决该问题，一个进程负责将采集到的数据写到缓存，另一组进程提供查询服务。另外，还可以根据存储层的压力，适当地调整采集的频率，使得统计数据尽可能实时。
自 2015 年起，历年除夕当天 QQ 红包收发情况如下表所示，可以看出，参与人数和红包首发总个数都是节节升高。
QQ 红包业务复杂，海量访问，涉及业务多，流程长，项目的成功离不开相关兄弟部门的大力支持和能力合作，特别感谢即通产品部、财付通、即通平台部、SNG 市场部、SNG 商业广告中心、增值渠道部、社交用户体验设计部、集团市场与公关部、增值产品部、社交与效果广告部、网络质量部、即通综合部、架构平台部、社交平台部、网络运营部等 15 个兄弟部门相关同事的付出和给力支持。
[1] QQ、微信团队原创技术文章： 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》
《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 >> [2] 有关QQ、微信的技术故事： 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》 《》
