你开奖了吗？细数大厂春节红包背后的技术支撑

本文转载自 InfoQ

除了大年三十看春晚，参与各大 App 的春节红包活动也逐渐成为了中国人的过年传统。红包也不再只是“钱”，而是承担了更多的角色，成为了应用的流量入口和增长引擎。春节红包的实现，背后少不了大数据、云计算、支付结算等新技术的支持。本文搜集了支付宝、微信、快手、QQ 四家大厂公开分享过的春节红包技术实践，以飨读者。

1 你扫福了吗？支付宝红包的实现

“敬业福，你扫到了吗？”相信大家最近应该经常听到这句话。支付宝集五福已经成为了大多数人春节的必备互动，2020 年春节有 3 亿多人集齐了五福，而今年的集福活动又有了新花样，除了传统的 AR 扫福和蚂蚁森林，增加写福字和芭芭农场。

其中，扫福字得福卡可能是参与人数最多的，为了解决高并发的问题，采用了客户端 + 服务端并行处理的架构体系，可支持两种识别方式：所有图片都传至服务端做处理，这样识别精度更高，但是服务器端能处理的数量有限；二是先走客户端检测，客户端无法识别的再上传服务端。客户端检测能力稍弱，但将计算能力分散到各终端，能极大缓解服务端的压力。

这么多人参与的集五福活动，其背后的技术支撑是怎样的？支付宝团队曾经分享过他们的技术保障，在数据方面比较特别的是采用了 GeaBase 和 OceanBase 两款数据库。

由于集五福活动有很多用户互动的场景，以好友福卡排名榜为例，虽然看上去只是计算每个好友的福卡总数，再进行排序，但是当用户量级上去之后，这个事情的难度就增加了。假设每人有十个好友，参与活动的用户是亿级，那么查询量级就会达到数十亿级，并且需要实时更新福卡数量。

在这种情况下，Oracle、MySQL 等普通关系型数据库的表现不是特别突出，查询用户好友还可以在毫秒内完成，而查询好友的好友，耗时就会指数级上升，查询越深，耗时越长。因此，在集五福的应用场景中采用了蚂蚁金服自主研发的分布式图数据库 GeaBase。

由于数据的存储结构和查询规则不同，查询深度对于 Geabase 的速度几乎没有显著影响，关系型数据库 30 秒才能得到查询结果，而 GeaBase 只需要 0.168 秒；关系型数据库难以给出结果的查询，Geabase 也只需 2 秒即可完成。

在集五福这类全民活动中，洪峰流量对于服务器的承压能力来说是一场大考。在开奖的那一瞬间，就是交答卷和出成绩的时刻，每个用户的中奖逻辑后面都有数十条数据，整体就有几十亿数据需要同步。这些数据需要在 2 分钟内完成同步，并发数高达每秒上千万。

如何更有效率，更节省成本地调配服务器资源呢？OceanBase 在其中发挥了作用，它可以在分钟级别内调度资源承接流量，也可以在洪峰过去之后，快速回收资源，避免浪费。

2 你抢红包了吗？微信红包的实现

过年期间，在各种微信群中抢红包已经成为一种大家喜闻乐见的欢度春节的方式。今年微信红包比较新鲜的变化是可以自己制作个性化的红包封面。

微信红包的使用步骤，相信大家都很熟悉，主要包括包、发、抢、拆、查询发送红包和收红包数量，其中比较关键的是发红包和抢红包。这是我们普通用户的角度，从微信团队的角度看，红包系统由三部分组成：信息流、业务流和资金流。这三部分在组织架构上由不同的后台团队完成：信息流——微信后台，业务流——微信支付后台，资金流——财付通后台。

2016 年除夕活动时的红包系统架构

抢红包阶段如何做到既轻量又可靠？根据微信团队介绍，主要是通过三种方式：

• 零 RPC 调用：一般情况下客户端发起的请求都是通过接入服务转发给具体的业务服务处理的，会产生 RPC 调用。但摇一摇逻辑直接嵌入接入服务中，接入服务可以直接处理摇一摇请求，派发红包。

• 零数据库存储：在抢红包的过程中，微信团队完全不使用数据库，可以达到几个数量级的性能提升，同时可靠性有了更好的保障。

• 异步化：用户抢到红包后不会同步进行后续的账务处理，请求会被放入红包异步队列，再通过异步队列转给微信支付后台，由微信支付后台完成后续业务逻辑。

同时，为了应对网络分裂的问题，微信团队在每个数据中心都建设三个独立的数据园区，可以做到在任意一个数据园区出现网络分裂等故障，甚至彻底变成园区孤岛后，另外两个数据园区可以无损承接整个数据中心的请求。

3 你扔骰子了吗？快手红包的实现

2021 年 2 月 5 日，快手在香港上市，开盘涨 194%，报 338 港元 / 股，发行价 115 港元 / 股，总市值一度高达 1.39 万亿港元。今年，快手策划了攒牛气分 21 亿活动，其中包括扔骰子、集福气、拼牛气等游戏。

2020 年，快手成为了央视春晚独家互动合作伙伴，在“春节 10 亿现金红包”活动中，快手红包互动总量达到了 639 亿次，红包站外分享次数达到 5.9 亿次。快手春晚直播间累计观看人次 7.8 亿，最高同时在线人数 2524 万。

快手在传统红包的基础上玩了很多新花样，增加了很多新年特效，例如新年灯牌、地标 AR、萌娃拜年、我的一生等等。

这些特效的实现应用了 MR、AR 等技术。MR 是混合现实技术，将春节元素与现实世界融合，创造了一个虚拟和物理对象共存、且能够实时交互的环境，带来沉浸式的用户体验。快手 App 的 MR 算法通过单摄像头来采集图像数据，利用深度学习和立体几何算法估算出相机的位置，然后实时输出 3D 数据，成功将 MR 效果融合到真实世界。

除了这些大家都能感受到的技术，还有一些背后默默支撑整个红包的技术实践。腾讯云高级工程师陈宏亮之前分享过腾讯云文件存储 CFS 如何支持快手应用广告推荐。

据了解，CFS 文件存储主要与 TKE 容器节点搭配，在春节期间为快手的广告推荐业务提供保障。CFS 主要参与三项具体的广告推荐业务流程，分别是模型文件发布、业务应用获取模型和广告推荐。春节期间，快手在腾讯云上使用了 3 个 TKE 容器集群共计 4000+ Node、Pod 数量超过 8000 个，以分摊业务压力。这些 Pod 要将所需的几十 GB 不等的一组模型文件全部加载后（该组合总共若干组），应用才能启动。

4 你刷一刷了吗？QQ 春节红包的实现

与其它平台的红包一样，QQ 春节红包也拥有多种形式，例如企业红包、刷一刷红包、AR 红包等。

据悉，QQ 春节红包项目涉及手机 QQ 移动端、手机 QQQ 后台、QQ 钱包（财付通）系统、礼券系统、公众号等诸多业务系统，流程长且多，各系统性能吞吐量差异很大。QQ 团队曾经分享过 QQ 2017 年春节红包背后的技术实践。

QQ 红包的简化架构主要是由以下部分组成：接入层、抽奖系统、存储系统、发货系统、公众号消息通知和 CDN 资源。其中，接入层是红包后台服务的大门，负责抽奖请求预处理，确保有效的请求才透传给后端服务；抽奖系统是 QQ 红包的核心系统，负责承接用户抽奖请求，按设计合理的几率完成抽奖操作，并将抽奖结果安全落地保存；发货系统主要是确保最终礼品落地到用户账户中，QQ 钱包余额、QQ 卡券或第三方系统账户。

春节红包的主要特点就是海量、秒杀，用户期望的是看到红包之后能够顺畅地抢到，因此降低延迟、消除卡顿就是最直接的体验，甚至在弱网环境中，也能如丝般顺滑。基于此，QQ 团队在技术上面做了很多优化。

首先是资源预加载，原本 QQ 红包中不经常变化的静态资源都会分发到各地 CDN 以提高访问速度，例如页面、图片、JS 等，只有动态变化的内容才会实时从后台拉取。但是即使所有静态资源都采用 CDN 分发也无法支持流量洪峰。因此，QQ 团队采用了一个方法：使用手机 QQ 离线包机制提前把红包相关静态资源预加载到手机 QQ 移动端，以此来减轻 CDN 压力。离线包预加载的方式有两种，一是将静态资源放入预加载列表，二是主动推送离线包。

其次是缓存和延时，当流量洪峰来临时，用户操作请求同时涌向后台，后台服务器是会崩溃的，即使后台扛住了，那么所需的带宽和设备资源成本也是天文数字。用户每次刷的操作都向后台发起请求是没必要的，因此，QQ 团队对用户的刷一刷次数做了汇总，定时异步将汇总数据提交到后台，再将结果反馈到 QQ 移动端。

再次是错峰，通过运营手段将不同红包活动分散在不同时间点，有效减少请求峰值。

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

标签：细数,红包,QQ,快手,微信,春节,开奖,大厂,后台
来源： https://blog.csdn.net/m0_46163918/article/details/113810233