羊年春晚摇一摇活动已经落下帷幕现在回过头来看看这一全民参与的有趣的活动背后，有着怎样的后台系统这个系统又是如何被设计与实现出来的？

在了解这个系统の前先看看羊年春晚有哪些活动形式？春晚摇一摇复用了摇一摇入口但提供了全新的界面和交互内容。

在羊年春晚摇一摇界面里用戶摇动手机后，可以看到明星拜年、全家福、好友贺卡等精彩纷呈的活动页；也会有温馨的“休息一下”或让很多误以为中奖的“挂服務器”等特殊用途的页面。

大家最期待的肯定是摇同一个红包怎么发两次摇中同一个红包怎么发两次的幸运用户除了自己领到一份同一個红包怎么发两次（种子同一个红包怎么发两次）外，还可以领到若干份用于分享给其他好友的同一个红包怎么发两次（分裂同一个红包怎么发两次）

围绕这些活动，下面将会通过4个处于项目不同阶段的里程碑版本来介绍我们设计、实现这一系统过程中的一些思考和做法特别是标题里提到的“有把握”是由何而来。

原型系统很简单但已经基本实现了春晚摇一摇的需求。原型系统的架构见下图

原型系统看起来已经足够简单功能也基本完备，是不是可以稍加修改后直接用在春晚现场呢答案肯定是不行。那么问题来了：为什么不行

回答这一问题前，我们先看一下看似简单的活动背后面臨着哪些挑战？

海量用户请求预计请求峰值1000万/秒

1000万/秒究竟是多大的规模，可以通过下图更直观地感受下：

注：抢火车票数据引用自公开數据

春晚全程互动不确定因素多

这个系统需要跟羊年春晚全程紧密互动，从项目开始到结束有一系列的不确定因素会加大系统实现的複杂度：在开发阶段，针对节目与活动形式如何配合这 个问题的讨论有可能持续到春晚前如何使系统能服务多变的需求？在春晚现场節目数量多，节目时长甚至顺序都有可能调整如何做到现场节目与摇一摇活动无 缝衔接？

系统深度定制成败在此一举

作为专为春晚设計的系统，部署上线后真正能运行的时间就只有几个小时这几个小时内，常规系统所提倡的灰度发布、先扛住再优化等做法并不是太适鼡在这短暂的时间内，只有一次机会：要么成功要么失败。

全民高度关注必须成功

春晚会有7亿左右的观众，大家对这一活动抱有很夶期望全民瞩目之下，只能成功不能失败。

l缺少历史经验把握不大

如此大型的活动，对我们而言是史无前例的并没有太大的信心。前边提到的1000万/秒的峰值是如何估算出来各个环节会有多少用户参与？系统需要预留多少资源这些问题不会有现成的答案，都需要摸索与思考

可见，在看似简单的活动背后隐藏了巨大的挑战，之前假设的原型系统不太可能胜任需要做更深入的优化。

需要优化哪些環节比较显而易见的有三个：

春晚摇一摇需要用到大量的多媒体资源，这些资源都需要从CDN下载经过评估，带宽峰值需求是3Tb/s会带来巨夶的带宽压力。即使我们有无限的资源带宽需求能被满足，客户端在摇一摇后下载资源所需的等待时间也会带来很大的用户体验损害昰不可接受的。

接入是后台系统的第一道关所有请求都会到达接入。预计当晚会有3.5亿的在线如何尽可能保障外网接入质量？甚至在外網波动时也不受太大影响

1000万/秒的请求从外网涌进来后，都被路由给摇一摇服务也就是说摇一摇服务也将有1000万/秒的请求量。这意味着需偠确保系统内2个1000万/秒的高可用在分布式系统内，这是个挺大的问题

如果要对系统能否最终取得成功量化一个信心指数的话，这个原型系统的信心指数是10这个数字表示如果春晚摇一摇采用这套系统并取得成功，我们认为90%是靠运气也可以换种说法：拿这个系统到春晚摇┅摇，90%的可能会挂掉

系统肯定不能以运气为基础，这几个问题如何解决

V0.5的目标就是为了解决V0.1原型系统里的几个问题。

春晚使用的资源仳较多也比较大，但基本都是静态资源是可以提前几天下载到客户端的。保存到本地后在需要使用的时候，客户端直接从本地加载从而省去了集中在线下载所需的带宽需求，另外用户摇一摇时不再需要下载资源可以有更好的用户体验。下图展示了资源预下载过程

资源推送模块负责将资源上传到CDN，同时推送资源列表给客户端推送过程基于微信消息系统实现，可以在极短时间内把资源列表推送给幾亿的用户

资源预下载需要解决以下几个问题：

通过这套资源预下载系统， -  期间下发了资源65个，累计流量3.7PB其中闲时峰值达到1Tb/s。

要保證接入质量除了需要保证接入服务本身的稳定性外，需要做到：

• 具备在某些外网接入出现波动的时候能自动切换到正常接入服务的能仂；
• 保障网络与服务具备足够的冗余容量。

微信客户端已经具备了外网自动容灾切换的能力下边再看一下系统的外网部署情况。

我们重噺梳理了外网的部署最终在上海IDC和深圳IDC各设置了9个TGW接入集群。每个IDC都在3个不同的园区分别部署了电信、移动和联通的外网接入线路

另外，接入服务也进行了临时扩充两地共有638台接入服务器，最多支持14.6亿的同时在线

前面提到，系统需要面对预计1000万/秒从外网的请求同時还需要在内网转发同样是1000万/秒的请求给摇一摇服务，除此之外还需要在各种异 常情况下确保高可用。在如此海量请求之下在这个分咘式系统中，任何一点网络或服务的波动都可能是灾难性的这里边的困难程度可想而知。

正面解决这一问题的成本过高我们选择了去掉摇一摇服务——把摇一摇逻辑集成到了接入服务，从而去掉了1000万/秒的转发请求

但这样做，有一个前提：不能降低接入服务的稳定性洇为不单是春晚摇一摇请求，微信消息收发等基础功能的请求也需要通过接入服务来中转假如嵌入的摇一摇逻辑把接入服务拖垮，将得鈈偿失

接入服务的架构刚好有助于解决这个问题。

如上图所示接入服务有一个网络IO模块，这个模块维护了来自客户端的TCP连接收发数據，负责跟客户端通讯网络IO模块是作为独立的进程组运 作的，收到的请求通过本机共享内存发给接入逻辑模块处理接入逻辑模块也是┅组独立运行的进程，通常情况下是由请求中转逻辑通过RPC把请求转发给其他逻 辑服务器处理现在摇一摇逻辑作为嵌入逻辑，整合到了接叺逻辑模块由于网络IO模块与接入逻辑模块相互隔离，可以单独对接入逻辑模块进行升级不会影响 到已有的网络连接，这大大降低了嵌叺逻辑带来的风险

但这样还不够，还可以把嵌入到接入逻辑模块里的摇一摇逻辑尽可能简化只保留比较简单、稳定、只需要单机计算即可完成的轻量逻辑；把其他较复杂、可能需要经常变更、或需要跨机访问的逻辑独立为摇一摇agent，作为独立运行的进程通过本机共享内存与嵌入摇一摇逻辑通讯。

接入服务架构的修改使得内置摇一摇逻辑变得可能剩下的就是怎样实现春晚摇一摇逻辑？春晚摇一摇逻辑最偅要的是摇同一个红包怎么发两次摇同一个红包怎么发两次则需要重点解决以下问题：

 同一个红包怎么发两次如何发放？

所有同一个红包怎么发两次都源自同一个红包怎么发两次系统但为了在运行时不依赖同一个红包怎么发两次系统，同一个红包怎么发两次系统生成的種子同一个红包怎么发两次文件被提前部署到了接入服务为确保同一个红包怎么发两次文件不会被重复发放，有个 文件切分程序完成不哃机器的文件切分每台机只保留自己需要处理的那部分同一个红包怎么发两次；另外，为了确保同一个红包怎么发两次不漏还有另一個程序完成所有机器同一个红包怎么发两次文件的合并校验。

摇到同一个红包怎么发两次的用户如果选择不分享同一个红包怎么发两次這些同一个红包怎么发两次会被同一个红包怎么发两次系统回收，一部分作为种子同一个红包怎么发两次经由摇一摇agent回流到接入服务进行發放

摇一摇agent会根据预设的策略给内置的摇一摇逻辑提供可下发的种子同一个红包怎么发两次。同一个红包怎么发两次是每秒匀速下发的可以精确控制全局同一个红包怎么发两次下发速度，保持在同一个红包怎么发两次/支付系统能正常处理的范围之内

 怎样保障安全？

业務要求每个用户最多可以领取3个同一个红包怎么发两次并且每个赞助商最多1个。常规实现里需要在后台存储用户领取记录，每次摇一搖请求时取出来计算如果拿到 同一个红包怎么发两次还需要更新存储。但这里增加了对存储的依赖海量请求下，稳定性不易保障我們借鉴了HTTP协议的COOKIE，在摇一摇协议里也实现了类似的机 制：后台可以写入用户的同一个红包怎么发两次领取情况到COOKIE交由客户端保存，客户端在下次请求时带上来服务器再取出来判断。这就无需后台存储也可以实现同样的 目的

协议总是有可能被破解的，恶意用户可以制作洎动机绕开COOKIE检测机制。所以COOKIE检测机制只能用于绝大部分使用正常客户端的用户对于破解协议的恶意用户可以通过在本机存储同一个红包怎么发两次下发记录来打击。

虽然接入服务使用长连接但恶意用户可以不断重连，变换不同的服务器来获取同一个红包怎么发两次針对这种情况，我们设计了同一个红包怎么发两次发放汇总服务可以在所有接入服务上同步已经达到同一个红包怎么发两次领取上限的鼡户。

以上策略依次递进后一步较前一步更深入一层解决问题，但是在设计上前一步并不依赖后一步，即使后边的步骤出现故障无法按预期进行也不会影响前边的结果，在最差的情况下系统仍然可以保证单用户同一个红包怎么发两次个数限制的需求。

 如何与春晚现場同步互动

春晚摇一摇系统需要配合春晚现场节目进行互动，春晚切换节目或者主持人进行活动的口播时系统都需要同步切换活动配置。

这里一是要求快速二是要求稳定。为此我们设计了这样一个配置系统

春晚现场有一个配置前台，现场人员可以通过这个配置前台發送变更指令到后台后台有上海和深圳两个接收点，每个接收点由处于不同园区的3组冗余的配 置服务构成配置服务接收到配置后会同步到另一接收点，同时以文件形式下发到所有接入服务为确保同步成功，使用了RPC/RSYNC/变更系统三个冗余 变更通道来同时变更配置从配置前囼发起变更，到接入服务加载配置全程可以在10秒内完成。

看起来快速和稳定都满足了是不是就已经足够了？请思考以下异常场景：

• 春晚前台无法工作或网络故障指令无法发给配置服务；
• 所有配置服务均无法工作或网络故障，配置无法同步给接入服务

这些异常在春晚節目过程中临时出现的话，一般情况下影响并不大我们可以临时手工变更配置，赢得足够时间去修复系统但是，如果此时主持人正在號召 大家拿起手机抢同一个红包怎么发两次我们是没有足够的把握可以在极短时间内完成全系统的配置变更的，也就是说极有可能功亏┅篑关键配置变更不了，同一个红包怎么发两次根本出不来还有 一种类似的场景，就是抢同一个红包怎么发两次开始后也因为配置變更问题，结束不了没法切回其他活动，损坏用户体验

针对口播抢同一个红包怎么发两次这个关键点，我们采用这样的配置变更策略：使用抢同一个红包怎么发两次倒计时配置到点后自动开始抢同一个红包怎么发两次时段，经过预设的时间后又自动结束。另外 由於春晚节目的口播时间点具有不确定性，我们制定了变更策略在节目过程中可以逐步校正倒计时。于是这一关键配置就只与时间相关機器时间相对容易保障， 通过NTP就可以达到足够精度的时间同步我们还对机器时间进行集中监控，可以发现并处理机器时间出现异常的机器

至此，V0.1原型系统前边提到的三个问题均已解决1000万/秒的海量请求可以扛住。但是1000万/秒是预估的，如果最终来了2000万怎么办4000万呢？看起来数字有点不可思议但真有1亿甚至几亿用户在不停的摇，也还是有可能出现的

对于2000万/秒，我们其实并不担心接入服务经过不断的優化，可以在提供容灾冗余的基础上仍有2500万/秒的吞吐能力。

但是4000万/秒大大超出了后台服务能力怎么办？

海量服务之道有个过载保护洳果没法硬扛，可以做到自我保护简单的说就是前端保护后端，后端拒绝前端

客户端在服务访问不了、服务访问超时和服务限速时主動减少请求。

接入服务可以在发现某个客户端请求过于频繁时会自动延迟回包，间接达到拉大请求间隔的效果最终实现在后台把客户端请求频率限制在合理范围内；另 外，接入服务会计算机器的CPU使用情况CPU使用率到达不同预设阈值时，会自动返回不同档次的限速给客户端通过客户端配合完成限速。

通过这些措施在请求量超预期时，系统会自动降级从而实现自保。

综上可以得到V0.5测试版的架构，信惢指数50

为什么V0.5测试版的信心指数只有50？还有哪些没做到位

反思一下，可以发现：V0.5测试版主要聚焦于如何处理海量的摇一摇请求让用戶可以愉快的摇出同一个红包怎么发两次，那摇出同一个红包怎么发两次之后呢V0.5测试版并未对这个问题作进一步的思考。

先看一下摇一搖的核心体验——摇同一个红包怎么发两次摇同一个红包怎么发两次涉及摇到同一个红包怎么发两次、拆同一个红包怎么发两次、分享哃一个红包怎么发两次、好友抢同一个红包怎么发两次等等步骤。

稍加分析即可发现前三步是本人操作，后续是好友操作从本人操作箌好友操作之间是有一定时延的，这也就意味着这里其实可以接受一定程度的有损体验——延时

V0.5测试版已经解决摇同一个红包怎么发两佽的问题，剩下就看拆同一个红包怎么发两次和分享同一个红包怎么发两次了

5.2.  如何确保拆同一个红包怎么发两次和分享同一个红包怎么發两次的用户体验？

可以把拆同一个红包怎么发两次和分享同一个红包怎么发两次抽象一下它们都是由两个部分组成：用户操作（信息鋶）和后台的同一个红包怎么发两次处理逻辑（业务流）。对用户来说他关心的是操作是否成功，而不是后台的同一个红包怎么发两次處理逻辑因此这个问题可以进一步简化为：如何确保拆同一个红包怎么发两次和分享同一个红包怎么发两次的用户操作能成功？

我们在鼡户操作和同一个红包怎么发两次处理逻辑之间加入了一个中间层这个中间层包括同一个红包怎么发两次简化逻辑和同一个红包怎么发兩次异步队列，实现了信息流和业务流的异步化和解耦

通过一些算法设计，同一个红包怎么发两次简化逻辑可以通过本地计算完成对同┅个红包怎么发两次请求是否合法的初步判断合法请求放入异步队列，然后就可以返回客户端处理成功；

同一个红包怎么发两次异步队列存储来自简化逻辑的请求在存储上，异步队列使用3机方案3机写2份成功即算入队成功。异步队列的处理逻辑会从队列取出请求继续发起对同一个红包怎么发两次系统的调用完成后续的同一个红包怎么发两次逻辑。在同一个红包怎么发两次系统故障时会有妥善的重试筞略，确保在系统恢复后重试成功

接入服务、同一个红包怎么发两次简化逻辑服务、同一个红包怎么发两次异步队列构成了所谓的“铁彡角”，可以在同一个红包怎么发两次系统出现严重问题时保护用户体验在较长时间内基本不受损，争取到修复故障的宝贵时间

其实洅仔细思考一下，“铁三角”还可以做得更强：把同一个红包怎么发两次简化逻辑再次拆分为基本的业务逻辑和本地透传队列业务逻辑唍成同一个红包怎么发两次合法性校验后，把请求写 入本地文件队列本地文件队列再透传给同一个红包怎么发两次异步队列完成后续处悝。这样即使同一个红包怎么发两次异步队列出现意外抖动也不会影响到用户操作结果。

V0.8预览版已经基本成型信心指数达到70。

大家知噵设计≠实现为保证最终实现和线上系统运作符合设计预期，我们还做了：

未经压测的系统是很危险的无法真正了解系统在压力下的表现是否符合预期？系统的极限在哪为此，我们建立一个压测环境对系统进行不间断的压测。系统部署后在现网环境也进行了多轮嫃实压测。

多部门联合做了专题CODE REVIEW在代码层面对关键路径做了仔细的评估。

客户端发布流程较长全面铺开版本需要更长的时间，做不到潒服务器一样可以迅速上线fix问题因此在发布客户端前，除了测试外一次次的真实演练是非常必要的。

在和最终争取到了两次预热的機会，对系统进行了实战验证

因为预热规模的原因，摇一摇峰值并未达到预估值但发放同一个红包怎么发两次的速率一直维持在5万/秒的预设值，对后端“铁三角”和其后的同一个红包怎么发两次系统进行了充分的检验

每次演练和预熱都是难得的机会，不仅那些出异常的模块那些看起来表现正常的模块，也可以通过复盘和推演确认是否完全符合预期，挖掘出可能嘚隐患点进而解决。

最终我们发布了V1.0正式版。

V1.0正式版架构上与V0.8预览版并无不同但是信心指数加到了80。

我们认为剩下的20%里有10%体现在對突发状况的预案与现场处置。系统如此庞大与复杂是不是还有没想到、未暴露出来、还做得不够或者在有限资 源内无法解决的问题？這些问题一旦如果出现了是不是有可能最终左右了整个局面？所以最后的10%就是靠运气别出现这些问题。

 羊年春晚摇一摇