如上图所示，摇那个手机的时候会通过客户端发出一个请求，接入服务器，然后摇一摇服务，进行等级判断，判断以后把结果给到后端，可能摇到拜年或红包，假设摇到红包，上面有LOGO和背景图，客户端把这个LOGO和背景图拉回去，用户及时拆开红包，拆的请求会来到红包系统，红包系统进行处理之后会到支付系统，到财富通的转帐系统，最终用户拿到红包。

拿到钱以后，只是其中一份，还有好几份是可以分享出去，我们称之为“分裂红包”，通过信息系统转发给好友或群里，好友跟群里的人可以再抢一轮。

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

原始系统看起来比较简单，是不是修改一下直接拿到春晚上用就可以了？肯定不行的。

到底它有什么样的问题呢，为什么我们不能用，在回答这个问题之前想请大家看一下我们面临的挑战。

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

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

这个活动跟春晚是紧密互动的，有很多不确定因素，体现在几个方面：

1）在开发过程中，我们的活动怎么配合春晚，一直没有定下来，很可能持续到春晚开始前，显然我们的客户端跟我们的系统到那时候才发布出去，这时候我们的开发就会碰到比较多的问题了；
2）在春晚过程中，因为春晚是直播型节目，节目有可能会变，时长会变，顺序会变，活动过程跟春晚节目紧密衔接在一起，自己也是会有挑战的，这也是不确定的因素；
3）再就是我们系统是定制的，专门为春晚定制，只能运行这么一次，这是挺大的挑战，运行一次的系统不能通过很长的时间，检查它其中有什么问题很难，发出去了以后那一次要么就成功了，要么就失败了；
4）因为春晚观众很多，全国人民都在看，高度关注，我们必须保证成功，万一搞砸了就搞砸在全国人民面前了。这么大型的活动在业界少见，缺少经验，没有参考的东西。还有就是我们需要做怎样的准备才能保证万无一失或者万有一失，保证绝大部分用的体验是OK的，有很多问题需要我们不断地摸索思考。原型系统不能再用的，再用可能就挂了。

4.3、原型系统存在哪些问题？

原型系统有哪些问题呢？

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

4.4、我们是如何解决这些问题的？

针对以上几点，我们详细看一下每一点我们是怎么做到的。

我们首先看一下信心指数，把这个系统拿到春晚去跑有多少信心，这里的指数是10，如果这个系统拿到春晚去用，而且还成功了，这个概率是10%。

当然我们的系统不能建立在运气的基础上，应该怎么做？

1）带宽利用：在带宽这一块客户端可以摇到多种多样的结果，结果大部分都是静态资源，静态资源我们可以提前制作出来下发到客户端，在后台做了资源推送的服务，客户端拿到列表以后可以先行下载，客户端利用闲时把资源拉过去。碰到几个问题，资源交付情况的问题，需要增量的发下去；
2）资源更新；
3）下载失败：资源下载失败，失败的话怎么办呢；
4）资源覆盖率：依靠这个系统下载资源的用户，比如覆盖率只有20%、30%，两个东西就没有意义了，覆盖率要达到90%左右；
5）离线下载：离线资源下载，万一有些人把里面的东西修改了，可能会产生意想不到的结果，怎么保证离线资源的安全。

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

再就是外网接入质量，在上海跟深圳两地建立了十八个接入集群，每个城市有三网的介入，总共部署了638台接入服务器，可以支持同时14.6亿的在线。

所有用户的请求都会进入到接入服务器，我们建立了18个接入集群，保证如果一个出现问题的时候用户可以通过其它的接入。

但是在我们内部怎么把请求转给摇一摇服务，摇一摇处理完还要转到后端，怎么解决呢？

解决这个问题代价非常大，需要很多资源，最终我们选择把摇一摇服务去掉，把一千万每秒的请求干掉了，把这个服务挪入到接入服务。除了处理摇一摇请求之外，所有微信收消息和发消息都需要中转，因为这个接入服务本身，摇一摇的逻辑，因为时间比较短，如果发消息也受影响就得不偿失了。

不过，这恰好有一个好处，我们的接入服务的架构是有利于我们解决这个问题的。

在这个接入节点里分为几个部分。一个是负责网络IO的，提供长链接，用户可以通过长链接发消息，回头可以把请求中转到另外一个模块，就是接入到逻辑模块，平时提供转发这样的功能，现在可以把接入逻辑插入。这样做还不够，比方说现在做一点修改，还需要上线更新，摇一摇的活动形式没有怎么确定下来，中间还需要修改，但是上线这个模块也不大对，我们就把接入的逻辑这一块再做一次拆分，把逻辑比较固定、比较轻量可以在本地完成的东西，不需要做网络交互的东西放到了接入服务里。

另外一个涉及到网络交互的，需要经常变更的，处理起来也比较复杂的，做了个Agent，通过这种方式基本上实现了让接入能够内置摇一摇的逻辑，而且接入服务本身的逻辑性不会受到太大的损伤。解决这个问题之后就解决了接入的稳定性问题，后面的问题是摇一摇怎么玩，摇一摇怎么玩是红包怎么玩，在红包过程中怎么保证红包是安全的呢，红包涉及到钱，钱是不能开玩笑的。

还有一个问题是怎样跟春晚保持互动，春晚现场直播，我们怎么跟现场直播挂钩衔接起来。

先看红包如何发放。

前面说到摇一摇请求，其实是在接入服务做的，红包也是在接入服务里发出去的。

为了在发红包过程中不依赖这个系统，我们把红包的种子文件在红包系统里生成出来，切分，分到每个接入服务器里，每个接入服务器里都部署了专门的红包文件。

一个红包不能发两次，红包的发放速率需要考虑，发放红包一定有用户拆，拆了还要再抢，我们需要精确控制，确保所有请求量都是在红包系统能够接受的范围内。

在这个过程中还会有另外一个风险，用户摇到红包之后还可以有一些分裂红包分出去，他也可以不分享，不分享的也不会浪费，可以回收过来，会通过本地拉回去。这部分因为是比较少量的，问题不大，因为所有红包已经发出去了，只是补充的。这里我们就搞定了红包发放。

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

我们在我们的协议里后台服务接入的摇一摇文件里下发红包的时候写一个用户领取的情况，客户端发再次摇一摇请求的时候带上来，我们检查就行了，这是一个小技巧，这种方式解决用户最多只能领三个、企业只能领一个限制的问题。但这个只能解决正版客户端的问题，恶意用户可能不用正版，绕过你的限制，这是有可能的。

怎么办呢？一个办法是在Agent里面，通过检查本机的数据能够达到一个目的，摇一摇接入服务例有638台，如果迫到不同的机器，我们是长连，还可以短连，还可以连到另一台服务器，可以连到不同的地方去。

还有一个问题是人海战术，有些人拿着几万、几十万的号抢，抢到都是你的，那怎么办呢？这个没有太好的办法，用大数据分析看用户的行为，你平时养号的吗，正常养号的话，都会登记出来。

怎样跟春晚现场保持互动？需要解决的问题有两个：

1）是要迅速，不能拖太长时间，比如现在是刘德华唱歌，如果给出的明星摇一摇还是上一个节目不太合适，要求我们配置变更需要迅速；

2）是可靠。

我们怎么做的呢？

春晚现场我们是专门有同学过去的，在他们电脑装了系统，可以跟我们后台进行交互的，节目变了节切一下，变动的请求会发到后台。

我们部署两套，一套在深圳、一套在上海，在这个配置里还准备了三步服务，哪一步都可以，同时还可以同步这个数据，这个数据还可以下发到所有的接入机器，会把它同步过去，不是用一种方式，而是用三种方式。

通过这种方式可以迅速的在一千台服务器成功，是不是能够达到配置一定能够用？不一定，春晚现场是不可控的，万一指令没有发出怎么办？如果六个配置服务都挂了怎么办，从上一个节目切到下一个节目的时候发生这种问题不是太大，但是主持人在十点三十的时候如果摇红包一摇啥都没有，这就怒了，口播出不来也就挂了。

怎么做的呢？主持人肯定有口播，口播的时间点我们大致知道，虽然不知道精确的时间点，比如彩排的时候告诉我们一个时间，后来变了，我们大致知道时间范围，可以做倒计时的配置，比如十点半不管你有没有口播我们都要发红包了。

如果节目延时太长了，你的红包十分钟发完了，之后摇不到，那也不行，这种情况下我们做了校正：在节目过程中我们不断校正倒计时的时间，设了一个策略，定了一个流程，半小时的时候要通知一下我这个时间，因为它是预估的，节目越到后面能定下来的时间范围越精确，提前告诉我们，我们就可以调整。

那时候现场是在春晚的小会议室，在小会议室看不到现场什么情况，也是通过电视看，结果电视没信号了，就蒙了，校准就不知道现在怎么回事，进行到哪一步了，当时很着急，还好后来没事，后续的几个节目还是校正回来了，最终我们是精确的在那个时间点出现了抢红包。

前面讲了怎么在系统解决流量的问题、请求量的问题，最重要的一点是我们预估是一千万每秒，但如果春晚现场出来的是两千万、三千万或四千万怎么办，是不是整个系统就挂掉了。

我们就是采用过载保护，过载保护中心点是两点，前端保护后端，后端拒绝前端：

1）一个是在客户端埋入一个逻辑，每次摇变成一个请求，摇每十秒钟或五秒钟发送一个请求，这样可以大幅度降低服务器的压力，这只会发生到几个点；
2）一个是服务访问不了、服务访问超时和服务限速。实时计算接入负载，看CPU的负载，在衔接点给这台服务器的用户返回一个东西，就是你要限速了，你使用哪一档的限速，通过这种方式，当时有四千万用户在摇我们也能扛得住。

五、进一步优化：v0.5测试版

这是我们的0.5测试版，对这个我们的信心指数是50，为什么只有50%的把握？

我们前面解决的问题都是解决用户能摇到红包，服务器还不会坏掉，但是对摇红包来说那是第一步。后面还有好几步，还要把红包拆出来，还要分享，分享完以后其它人可以抢，这个体验是要保证的。

简单分析一下可以发现前面是本人操作，后面是好友操作。

这里就存在一个契机，你可以做一些服务，一旦出现问题是可以利用的点，可以做延时。剩下的问题是保证本人操作比较好，后面出点问题可以延迟，有延迟表示有时间差处理那个东西。

1）核心体验是什么？

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

2）如何确保拆/分享红包的用户体验？

拆红包和分享红包可以做一下切割，可以切割成两个部分：

1）一个是用户的操作，点了分享红包按纽；
2）之后是转帐。

对我们来说确保前面一点就可以了，核心体验设计的东西再次缩小范围，确保用户操作这一步能够成功。

怎么确保呢？我们称之为“铁三角”的东西，拆/分享红包=用户操作+后台业务逻辑。这是我们能做到的最高程度了。

3）还能做得更极致吗？

但我们还可以做的更好一点，前面这个用户看起来还是成功的，只是入帐入的稍微迟一点点，用户感觉不到。如果我们异步队列这里挂了，或者网络不可用了，概率比较低，我们有三个数据中心，挂掉一个问题不大。万一真的不能用呢？

我们又做了一次异步，分两部分：

1）一个是业务逻辑，校验这个红包是不是这个用户的；
2）还有一个透传队列，把这个数据再丢到后边，其实可以相信本机的处理一般是可以成功的，只要做好性能测试基本上是靠谱的。

在后面出现问题的时候我们用户的体验基本不受损，保证绝大多数用户的体验是OK的。

六、继续打磨：v0.8预览版

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

大家知道设计并不等于实现，设计的再好实践有问题也很崩溃。

正式发布前我们必须要保证：

1）是全程压测；
2）是专题CODE REVIEW；
3）是内部演练；
4）是线上预热；
5）是复盘与调整。

技术复盘包括两部分：

1）有问题的时候可以把异常问题看出来；
2）二是很正常，跑的时候是不是跟想象的一样，需要对正常情况下的数据做预估的重新评估，看看是不是符合预期。

我们进行了两次预热：

1）一次是摇了3.1亿次，峰值5000万一分钟，100万每秒，跟我们估算的一千万每秒差很远，当时只是针对iPhone用户，放开一个小红点，你看到的时候可以抢，发放红包5万每秒，春晚当晚也是五万每秒；
2）后面又发了一次，针对前面几个问题再做一次。

七、正式交付：v1.0正式版

做完这两次连接后面就迎接2月18号春晚的真正考验。这是1.0正式版，信心指数达到80，我们认为80%是可以搞定的。

剩下20%在哪里？有10%是在现场，现场不可能一帆风顺，有可能现场摇的很High，但后面到处灭火，10%是在现场处置的时候有比较好的预案和方案能够解决，另外10%是人算不如天算，一个很小的点出现问题导致被放大所有用户受影响也是有可能的，我们很难控制了。要做出完美无缺的基本不太可能，剩下10%就是留运气。

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

我今天跟大家的分享到这里。谢谢大家。

（原文链接：点此进入）

八、后续：文章中的热门题解答

提问 1：第一个是有一个压测，压测是怎么做的？怎么做到模拟这么大的量？还有两个不太明白的地方，防用户重复刷红包的地方会拉用户已经发的红包的历史记录，这个地方每次都会请求的话是不是每次单点？

张文瑞：先回答你压测的问题，压测分几个阶段，有一个压测工具，压测工具符合请求量的去压它，有了这个东西之后后面有全流程的压测，从所有东西的起点开始，把整个流程能够串起来，压测工具压的时候肯定要压线网系统，我们留了测试集群，放的是同样的机器去压，能够产生的结果跟我们是不是对得上。另外我们的接入，如果没有真正验证过一千万每秒的话单机测好像可以，但是比较危险。我们在客户端里做了一个触发。

提问 2：实际上还是发了一千万的请求？

张文瑞：不一定是一千万每秒。我们部署的几个集群，每个集群里几组机器，保证那部分OK就可以了。

对于第二个恶意领取的问题，其实不会有那个请求，第一个是通过Cookie，另外一部分是通过本机的Agent，通过本地计算是通过本地，是本地访问，是功能内存，不需要跑到后面访问，客户请求需要跑到后端访问。

提问 3：汇总的数据量不是很大吗？

张文瑞：有的用户可能摇到好几个。汇总这里整个挂掉是没有问题的，也不是完全没影响，对破解协议之类的，跟用户对抗的时候会受损，这部分数据就没有同步了，假设这个服务挂了或同步的网络出问题了，一般是不会出问题的，你不能让用户摇到十个红包，不能让大部分用户摇到十个红包然后其它用户没有。其它的层层递进，先做单机的，又做跨机的，前一层并不依赖后一层，你挂掉对我们来说也是可以接受的。

提问 4：最终发放的时候是靠红包系统，红包系统每秒处理多少个？

张文瑞：红包发放是在接入那里发出去的，红包不参与发放。用户拆红包的动作是要进入红包系统的，我们这里放过去的量在每秒钟五万，就是放出去，让用户摇到红包五万，红包系统本身他们预设处理十秒以上。

提问 5：还有一个问题是跟产品相关的，你用了Cookie和单机的校验，但可靠性不高，这样的情况下怎么做承诺你的设计能够承担，你怎么做产品方面分析的承诺呢？一个用户只能收到三个红包，假设这个时候有六个呢？

张文瑞：用户能摇到的红包是三个，但是他还可以抢。

提问 6：他拿到的三个红包是在接入那一块你给他算或了？是这样吗？

张文瑞：对。

提问 7：六百个服务器并发接入，如果很短的时间去接入的话呢。

张文瑞：用正版的客户端做不到这一点，他一定是拿了自己写的自动机或模拟机并发模拟。所以我们对产品的承诺正常用户是保证领三个红包，每个企业最多领到一个，但是有恶意用户，我们会一直提高对抗的水平，但是道高一尺魔高一丈，他永远想办法搞定你，我们靠后面的机制，就是多机共享数据来搞定。99.999%的情况下它可能是OK的，但是存在那么一点可能挂掉，如果挂掉我们就牺牲出那一部分，那没办法了。因为资源不是无限制的，有限资源你能做到最好的东西。

提问 8：我刚才听到在微信朋友圈那边到会有四个IDC，我连接哪个IDC写入数据的时候就写那个，再同步到其它的IDC上，怎么保证发红包的时候有那么大的量。

张文瑞：我们不用同步。用户只连到其中一个IDC，对用户进行切分，那个用户可能是属于上海的或加拿大的，你是上海的就只能连接上海的。数据本身也不需要同步的。我们的做法是这样的，我们计算出来每秒发放五万个，算好每个机发放多少，那台机按照那个量发就可以了。在红包这一块不用同步，后面的数据就靠用户点、拆。