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

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

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

今天跟大家分享的主题是如何实现 “有把握” 的春晚摇一摇系统。回忆一下春晚的活动，有什么样的活动形式呢？

当时我们是直接复用客户端摇一摇入口，专门给春晚摇一摇定制了一个页面，可以摇出 “现金拜年”、“红包”。底下的红包肯定是大家比较感兴趣的，也是今天下午重点介绍的内容。比较精彩的活动背后一定会有一个设计比较独到的系统。

V0.1 原型系统

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

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

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

1、我们面临怎样的挑战？

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

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

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

第三个挑战ÿ