我们看一下这个系统，当时做了一个原型系统，比较简单，它已经实现了所有的功能。

如上图所示，摇那个手机的时候会通过客户端发出一个请求，接入服务器，然后摇一摇服务，进行等级判断，判断以后把结果给到后端，可能摇到拜年或红包，假设摇到红包，上面有LOGO和背景图，客户端把这个LOGO和背景图拉回去，用户及时拆开红包，拆的请求会来到红包系统，红包系统进行处理之后会到支付系统，到财富通的转帐系统，最终用户拿到红包。
拿到钱以后，只是其中一份，还有好几份是可以分享出去，我们称之为“分裂红包”，通过信息系统转发给好友或群里，好友跟群里的人可以再抢一轮。
整个过程归一下类，叫：资源流、信息流、业务流、资金流，今天讲的主要是资源流跟信息流。
原始系统看起来比较简单，是不是修改一下直接拿到春晚上用就可以了？肯定不行的。
到底它有什么样的问题呢，为什么我们不能用，在回答这个问题之前想请大家看一下我们面临的挑战。

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

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

原型系统有哪些问题呢？
 

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

 

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

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

采用资源预下载

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

 

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

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