揭秘：春晚微信红包，是如何抗住 100 亿次请求的？

Hollis的新书限时折扣中，一本深入讲解Java基础的干货笔记！

从事软件开发多年，我偏爱架构设计。无论是电商系统、 交系统还是金融系统，我基本都有涉猎。

对于初级工程师而言，最基本的要求是要实现功能，但对于高级工程师和专家工程师而言，更多是要关注架构和性能。

今天，来聊聊红包问题，你可能疑惑：春晚微信红包，是如何扛住 100 亿次请求的，今天就一起来看看这篇分享。

链接：https://www.infoq.cn/article/weixin-bonus-load/=t

我们看一下这个系统，我们当时做了一个原型系统，比较简单，它已经实现了所有的功能，摇那个手机的时候会通过客户端发出一个请求，接入服务器，然后摇一摇服务，进行等级判断，判断以后把结果给到后端，可能摇到拜年或红包，假设摇到红包，上面有 LOGO 和背景图，客户端把这个 LOGO 和背景图拉回去，用户及时拆开红包，拆的请求会来到红包系统，红包系统进行处理之后会到支付系统，到财富通的转帐系统，最终用户拿到红包。拿到钱以后，只是其中一份，还有好几份是可以分享出去，我们称之为 “分裂红包”，通过信息系统转发给好友或群里，好友跟群里的人可以再抢一轮。

整个过程归一下类，叫资源流、信息流、业务流、资金流，今天讲的主要是资源流跟信息流。

原始系统看起来比较简单，是不是修改一下直接拿到春晚上用就可以了不行的。到底它有什么样的问题呢，为什么我们不能用，在回答这个问题之前想请大家看一下我们面临的挑战。

1、我们面临怎样的挑战p>

第一个挑战是比较容易想到的，用户请求量很大，当时预计 7 亿观众，微信用户也挺多的，当时预估一下当时峰值达到一千万每秒，通过图对比一下，左边是春运抢火车票，一秒钟请求的峰值是 12 万，第二个是微信系统，微信系统发消息有个小高峰，那时候峰值每秒钟是 33 万，比较高一点的是预估值一千万每秒，右边是春晚时达到的请求峰值是 1400 万每秒。

这个活动跟春晚是紧密互动的，有很多不确定因素，体现在几个方面。一个是在开发过程中，我们的活动怎么配合春晚，一直没有定下来，很可能持续到春晚开始前，显然我们的客户端跟我们的系统到那时候才发布出去，这时候我们的开发就会碰到比较多的问题了，这是第一个。

第二个挑战，在春晚过程中，因为春晚是直播型节目，节目有可能会变，时长会变，顺序会变，活动过程跟春晚节目紧密衔接在一起，自己也是会有挑战的，这也是不确定的因素。再就是我们系统是定制的，专门为春晚定制，只能运行这么一次，这是挺大的挑战，运行一次的系统不能通过很长的时间，检查它其中有什么问题很难，发出去了以后那一次要么就成功了，要么就失败了。

第三个挑战，因为春晚观众很多，全国人民都在看，高度关注，我们必须保证成功，万一搞砸了就搞砸在全国人民面前了。这么大型的活动在业界少见，缺少经验，没有参考的东西。还有就是我们需要做怎样的准备才能保证万无一失或者万有一失，保证绝大部分用的体验是 OK 的，有很多问题需要我们不断地摸索思考。原型系统不能再用的，再用可能就挂了。

2、原型系统存在哪些问题h2>

原型系统有哪些问题呢个是在流量带宽上，大量的用户请求会产生大量的带宽，预估带宽峰值是 3000pb 每秒，假设我们资源是无限的能够满足带宽需求，也会碰到一个问题，用户摇到以后有一个等待下载的过程。第二个问题，在接入质量这一块，我们预估同时在线 3.5 亿左右，特别是在外 一旦产生波动的时候怎么保证用户体验不受损而系统正常运作。第三个挑战，请求量很大，1000 万每秒，如何转到摇一摇服务，摇一摇服务也面临一千万请求量，我们系统要同时面对两个一千万请求量，这不是靠机器的，大家都有分布式的经验，这么大请求量的时候任何一点波动都会带来问题，这是一个很大的挑战。

3、我们是如何解决这些问题的h2>

针对以上几点，我们详细看一下每一点我们是怎么做到的。我们首先看一下信心指数，把这个系统拿到春晚去跑有多少信心，这里的指数是 10，如果这个系统拿到春晚去用，而且还成功了，这个概率是 10%。当然我们的系统不能建立在运气的基础上，应该怎么做个，在带宽这一块客户端可以摇到多种多样的结果，结果大部分都是静态资源，静态资源我们可以提前制作出来下发到客户端，在后台做了资源推送的服务，客户端拿到列表以后可以先行下载，客户端利用闲时把资源拉过去。碰到几个问题，资源交付情况的问题，需要增量的发下去；二是资源更新；三是资源下载失败，失败的话怎么办呢；四是资源覆盖率，依靠这个系统下载资源的用户，比如覆盖率只有 20%、30%，两个东西就没有意义了，覆盖率要达到 90% 左右；五是离线资源下载，万一有些人把里面的东西修改了，可能会产生意想不到的结果，怎么保证离线资源的安全。

这里有个数据，2 月 9 到 2 月 18 下发资源 65 个，累积流量 3.7PB，峰值流量 1Tb/s。通过这种方式解决了下载资源的问题。

前面说道摇一摇请求，其实是在接入服务做的，红包也是在接入服务里发出去的，为了在发红包过程中不依赖这个系统，我们把红包的种子文件在红包系统里生成出来，切分，分到每个接入服务器里，每个接入服务器里都部署了专门的红包文件。一个红包不能发两次，红包的发放速率需要考虑，发放红包一定有用户拆，拆了还要再抢，我们需要精确控制，确保所有请求量都是在红包系统能够接受的范围内。在这个过程中还会有另外一个风险，用户摇到红包之后还可以有一些分裂红包分出去，他也可以不分享，不分享的也不会浪费，可以回收过来，会通过本地拉回去。这部分因为是比较少量的，问题不大，因为所有红包已经发出去了，只是补充的。这里我们就搞定了红包发放。

二是怎么样保证红包不被多领或恶意领取，每个客户领三个红包，这是要做限制的，但这是有代价的，就是存储的代价。

我们在我们的协议里后台服务接入的摇一摇文件里下发红包的时候写一个用户领取的情况，客户端发再次摇一摇请求的时候带上来，我们检查就行了，这是一个小技巧，这种方式解决用户最多只能领三个、企业只能领一个限制的问题。这个只能解决正版客户端的问题，恶意用户可能不用正版，绕过你的限制，这是有可能的。怎么办呢办法是在 Agent 里面，通过检查本机的数据能够达到一个目的，摇一摇接入服务例有 638 台，如果迫到不同的机器，我们是长连，还可以短连，还可以连到另一台服务器，可以连到不同的地方去。还有一个问题是人海战术，有些人拿着几万、几十万的 抢，抢到都是你的，那怎么办呢没有太好的办法，用大数据分析看用户的行为，你平时养 的吗，正常养 吗，都会登记出来。

怎样跟春晚现场保持互动解决的问题有两个，一个是要迅速，不能拖太长时间，比如现在是刘德华唱歌，如果给出的明星摇一摇还是上一个节目不太合适，要求我们配置变更需要迅速，二是可靠。我们怎么做的呢p>

我们前面解决的问题都是解决用户能摇到红包，服务器还不会坏掉，但是对摇红包来说那是第一步，后面还有好几步，还要把红包拆出来，还要分享，分享完以后其它人可以抢，这个体验是要保证的，简单分析一下可以发现前面是本人操作，后面是好友操作，这里就存在一个契机，你可以做一些服务，一旦出现问题是可以利用的点，可以做延时。剩下的问题是保证本人操作比较好，后面出点问题可以延迟，有延迟表示有时间差处理那个东西。

1、核心体验是什么p>

这里面我们需要确保成功，确保体验是完全 OK 的，确保成功的时候前面提到原型的系统里解决了摇到红包的问题，剩下的就是拆红包和分享红包。怎么样确保拆红包和分享红包的用户体验p>

2、如何确保拆 / 分享红包的用户体验p>

拆红包和分享红包可以做一下切割，可以切割成两个部分，一个是用户的操作，点了分享红包按纽，之后是转帐，对我们来说确保前面一点就可以了，核心体验设计的东西再次缩小范围，确保用户操作这一步能够成功。怎么确保呢称之为 “铁三角” 的东西，拆 / 分享红包 = 用户操作 + 后台彰武逻辑。这是我们能做到的最高程度了。

3、还能做得更极致吗p>

但我们还可以做的更好一点，前面这个用户看起来还是成功的，只是入帐入的稍微迟一点点，用户感觉不到。如果我们异步队列这里挂了，或者 络不可用了，概率比较低，我们有三个数据中心，挂掉一个问题不大，万一真的不能用呢，我们又做了一次异步，分两部分：一个是业务逻辑，校验这个红包是不是这个用户的，还有一个透传队列，把这个数据再丢到后边，其实可以相信本机的处理一般是可以成功的，只要做好性能测试基本上是靠谱的。在后面出现问题的时候我们用户的体验基本不受损，保证绝大多数用户的体验是 OK 的。

V0.8 预览版

我们又做了 0.8 的版本，预览版，信心指数 70，我们认为这个东西有七成把握是可以成功的。

2 月 18 跑出来的结果是这样的，当时摇了 110 亿次，峰值是 8.1 亿每分钟，1400 万每秒。

完

我的新书《深入理解Java核心技术》已经上市了，上市后一直蝉联京东畅销榜中，目前正在6折优惠中，想要入手的朋友千万不要错过哦~长按二维码即可购买~

注意：雪花算法并不是ID的唯一选择！

看完这妹纸的日更作业， 友直呼：中国计算机界的神！

有道无术，术可成；有术无道，止于术

好文章，我在看??

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92605 人正在系统学习中