共计 5852 个字符，预计需要花费 15 分钟才能阅读完成。
对于高级工程师而言，最根本的要求是要实现性能，但对于高级工程师和专家工程师而言，更多是要关注架构和性能。
明天，来聊聊红包问题，你可能纳闷：春晚微信红包，是如何扛住 100 亿次申请的？那么，明天就一起来看看这篇分享。
明天跟大家分享的主题是如何实现“有把握”的春晚摇一摇零碎。回顾一下春晚的流动，有什么样的流动模式呢？
过后咱们是间接复用客户端摇一摇入口，专门给春晚摇一摇定制了一个页面，能够摇出“现金拜年”、“红包”。底下的红包必定是大家比拟感兴趣的，也是今天下午重点介绍的内容。比拟精彩的流动背地肯定会有一个设计比拟独到的零碎。
V0.1 原型零碎
咱们看一下这个零碎，咱们过后做了一个原型零碎，比较简单，它曾经实现了所有的性能，摇那个手机的时候会通过客户端收回一个申请，接入服务器，而后摇一摇服务，进行等级判断，判断当前把后果给到后端，可能摇到拜年或红包，假如摇到红包，下面有 LOGO 和背景图，客户端把这个 LOGO 和背景图拉回去，用户及时拆开红包，拆的申请会来到红包零碎，红包零碎进行解决之后会到领取零碎，到财产通的转帐零碎，最终用户拿到红包。拿到钱当前，只是其中一份，还有好几份是能够分享进来，咱们称之为“决裂红包”，通过信息系统转发给好友或群里，好友跟群里的人能够再抢一轮。
整个过程归一下类，叫资源流、信息流、业务流、资金流，明天讲的次要是资源流跟信息流。
原始零碎看起来比较简单，是不是批改一下间接拿到春早晨用就能够了？必定不行的。到底它有什么样的问题呢，为什么咱们不能用，在答复这个问题之前想请大家看一下咱们面临的挑战。
1、咱们面临怎么的挑战？
第一个挑战是比拟容易想到的，用户申请量很大，过后预计 7 亿观众，微信用户也挺多的，过后预估一下过后峰值达到一千万每秒，通过图比照一下，右边是春运抢火车票，一秒钟申请的峰值是 12 万，第二个是微信零碎，微信零碎发消息有个小顶峰，那时候峰值每秒钟是 33 万，比拟高一点的是预估值一千万每秒，左边是春晚时达到的申请峰值是 1400 万每秒。
这个流动跟春晚是严密互动的，有很多不确定因素，体现在几个方面。一个是在开发过程中，咱们的流动怎么配合春晚，始终没有定下来，很可能继续到春晚开始前，显然咱们的客户端跟咱们的零碎到那时候才公布进来，这时候咱们的开发就会碰到比拟多的问题了，这是第一个。
第二个挑战，在春晚过程中，因为春晚是直播型节目，节目有可能会变，时长会变，程序会变，流动过程跟春晚节目严密连接在一起，本人也是会有挑战的，这也是不确定的因素。再就是咱们零碎是定制的，专门为春晚定制，只能运行这么一次，这是挺大的挑战，运行一次的零碎不能通过很长的工夫，查看它其中有什么问题很难，收回去了当前那一次要么就胜利了，要么就失败了。
第三个挑战，因为春晚观众很多，全国人民都在看，高度关注，咱们必须保障胜利，万一搞砸了就搞砸在全国人民背后了。这么大型的流动在业界少见，短少教训，没有参考的货色。还有就是咱们须要做怎么的筹备能力保障十拿九稳或者万有一失，保障绝大部分用的体验是 OK 的，有很多问题须要咱们一直地摸索思考。原型零碎不能再用的，再用可能就挂了。
2、原型零碎存在哪些问题？
原型零碎有哪些问题呢？第一个是在流量带宽上，大量的用户申请会产生大量的带宽，预估带宽峰值是 3000pb 每秒，假如咱们资源是有限的可能满足带宽需要，也会碰到一个问题，用户摇到当前有一个期待下载的过程。第二个问题，在接入品质这一块，咱们预估同时在线 3.5 亿左右，特地是在外网一旦产生稳定的时候怎么保障用户体验不受损而零碎失常运作。第三个挑战，申请量很大，1000 万每秒，如何转到摇一摇服务，摇一摇服务也面临一千万申请量，咱们零碎要同时面对两个一千万申请量，这不是靠机器的，大家都有分布式的教训，这么大申请量的时候任何一点稳定都会带来问题，这是一个很大的挑战。
3、咱们是如何解决这些问题的？
针对以上几点，咱们具体看一下每一点咱们是怎么做到的。咱们首先看一下信念指数，把这个零碎拿到春晚去跑有多少信念，这里的指数是 10，如果这个零碎拿到春晚去用，而且还胜利了，这个概率是 10%。当然咱们的零碎不能建设在运气的根底上，应该怎么做？第一个，在带宽这一块客户端能够摇到多种多样的后果，后果大部分都是动态资源，动态资源咱们能够提前制作进去下发到客户端，在后盾做了资源推送的服务，客户端拿到列表当前能够后行下载，客户端利用闲时把资源拉过来。碰到几个问题，资源交付状况的问题，须要增量的发下去；二是资源更新；三是资源下载失败，失败的话怎么办呢；四是资源覆盖率，依附这个零碎下载资源的用户，比方覆盖率只有 20%、30%，两个货色就没有意义了，覆盖率要达到 90% 左右；五是离线资源下载，万一有些人把外面的货色批改了，可能会产生意想不到的后果，怎么保障离线资源的平安。
这里有个数据，2 月 9 号到 2 月 18 号下发资源 65 个，累积流量 3.7PB，峰值流量 1Tb/s。通过这种形式解决了下载资源的问题。
再就是外网接入品质，在上海跟深圳两地建设了十八个接入集群，每个城市有三网的染指，总共部署了 638 台接入服务器，能够反对同时 14.6 亿的在线。
所有用户的申请都会进入到接入服务器，咱们建设了 18 个接入集群，保障如果一个呈现问题的时候用户能够通过其它的接入，然而在咱们外部怎么把申请转给摇一摇服务，摇一摇解决完还要转到后端，怎么解决呢？解决这个问题代价十分大，须要很多资源，最终咱们抉择把摇一摇服务去掉，把一千万每秒的申请干掉了，把这个服务挪入到接入服务。除了解决摇一摇申请之外，所有微信收音讯和发消息都须要直达，因为这个接入服务自身，摇一摇的逻辑，因为工夫比拟短，如果发消息也受影响就得失相当了。
恰好有一个益处，咱们的接入服务的架构是有利于咱们解决这个问题的，在这个接入节点里分为几个局部，一个是负责网络 IO 的，提供长链接，用户能够通过长链接发消息，回头能够把申请直达到另外一个模块，就是接入到逻辑模块，平时提供转发这样的性能，当初能够把接入逻辑插入。这样做还不够，比方说当初做一点批改，还须要上线更新，摇一摇的流动模式没有怎么确定下来，两头还须要批改，然而上线这个模块也不大对，咱们就把接入的逻辑这一块再做一次拆分，把逻辑比拟固定、比拟轻量能够在本地实现的货色，不须要做网络交互的货色放到了接入服务里。
另外一个波及到网络交互的，须要常常变更的，解决起来也比较复杂的，做了个 Agent，通过这种形式基本上实现了让接入可能内置摇一摇的逻辑，而且接入服务自身的逻辑性不会受到太大的伤害。解决这个问题之后就解决了接入的稳定性问题，前面的问题是摇一摇怎么玩，摇一摇怎么玩是红包怎么玩，在红包过程中怎么保障红包是平安的呢，红包波及到钱，钱是不能开玩笑的。第三个问题是怎么跟春晚放弃互动，春晚现场直播，咱们怎么跟现场直播挂钩衔接起来。
先看红包如何发放。
后面说道摇一摇申请，其实是在接入服务做的，红包也是在接入服务里收回去的，为了在发红包过程中不依赖这个零碎，咱们把红包的种子文件在红包零碎里生成进去，切分，分到每个接入服务器里，每个接入服务器里都部署了专门的红包文件。一个红包不能发两次，红包的发放速率须要思考，发放红包肯定有用户拆，拆了还要再抢，咱们须要准确管制，确保所有申请量都是在红包零碎可能承受的范畴内。在这个过程中还会有另外一个危险，用户摇到红包之后还能够有一些决裂红包分进来，他也能够不分享，不分享的也不会节约，能够回收过去，会通过本地拉回去。这部分因为是比拟大量的，问题不大，因为所有红包曾经收回去了，只是补充的。这里咱们就搞定了红包发放。
二是怎么样保障红包不被多领或歹意支付，每个客户领三个红包，这是要做限度的，但这是有代价的，就是存储的代价。
咱们在咱们的协定里后盾服务接入的摇一摇文件里下发红包的时候写一个用户支付的状况，客户端发再次摇一摇申请的时候带上来，咱们查看就行了，这是一个小技巧，这种形式解决用户最多只能领三个、企业只能领一个限度的问题。这个只能解决正版客户端的问题，歹意用户可能不必正版，绕过你的限度，这是有可能的。怎么办呢？一个方法是在 Agent 外面，通过查看本机的数据可能达到一个目标，摇一摇接入服务例有 638 台，如果迫到不同的机器，咱们是长连，还能够短连，还能够连到另一台服务器，能够连到不同的中央去。还有一个问题是人海战术，有些人拿着几万、几十万的号抢，抢到都是你的，那怎么办呢？这个没有太好的方法，用大数据分析看用户的行为，你平时养号的吗，失常养号吗，都会注销进去。
怎么跟春晚现场放弃互动？须要解决的问题有两个，一个是要迅速，不能拖太长时间，比方当初是刘德华唱歌，如果给出的明星摇一摇还是上一个节目不太适合，要求咱们配置变更须要迅速，二是牢靠。咱们怎么做的呢？
春晚现场咱们是专门有同学过来的，在他们电脑装了零碎，能够跟咱们后盾进行交互的，节目变了节切一下，变动的申请会发到后盾，咱们部署两套，一套在深圳、一套在上海，在这个配置里还筹备了三步服务，哪一步都能够，同时还能够同步这个数据，这个数据还能够下发到所有的接入机器，会把它同步过来，不是用一种形式，而是用三种形式，通过这种形式能够迅速的在一千台服务器胜利，是不是可能达到配置肯定可能用？不肯定，春晚现场是不可控的，万一指令没有收回怎么办？如果六个配置服务都挂了怎么办，从上一个节目切到下一个节目的时候产生这种问题不是太大，然而主持人在十点三十的时候如果摇红包一摇啥都没有，这就怒了，口播出不来也就挂了。
怎么做的呢？主持人必定有口播，口播的工夫点咱们大抵晓得，尽管不晓得准确的工夫点，比方彩排的时候通知咱们一个工夫，起初变了，咱们大抵晓得工夫范畴，能够做倒计时的配置，比方十点半不论你有没有口播咱们都要发红包了。如果节目延时太长了，你的红包十分钟发完了，之后摇不到，那也不行，这种状况下咱们做了校对，在节目过程中咱们一直校对倒计时的工夫，设了一个策略，定了一个流程，半小时的时候要告诉一下我这个工夫，因为它是预估的，节目越到前面能定下来的工夫范畴越准确，提前通知咱们，咱们就能够调整。那时候现场是在春晚的小会议室，在小会议室看不到现场什么状况，也是通过电视看，后果电视没信号了，就蒙了，校准就不晓得当初怎么回事，进行到哪一步了，过后很着急，还好起初没事，后续的几个节目还是校对回来了，最终咱们是准确的在那个工夫点呈现了抢红包。后面讲了怎么在零碎解决流量的问题、申请量的问题，最重要的一点是咱们预估是一千万每秒，但如果春晚现场进去的是两千万、三千万或四千万怎么办，是不是整个零碎就挂掉了。
咱们就是采纳过载爱护，过载爱护中心点是两点，前端爱护后端，后端回绝前端。一个是在客户端埋入一个逻辑，每次摇变成一个申请，摇每十秒钟或五秒钟发送一个申请，这样能够大幅度降低服务器的压力，这只会产生到几个点，一个是服务拜访不了、服务拜访超时和服务限速。实时计算接入负载，看 CPU 的负载，在连接点给这台服务器的用户返回一个货色，就是你要限速了，你应用哪一档的限速，通过这种形式，过后有四千万用户在摇咱们也能扛得住。
V0.5 测试版
这是咱们的 0.5 测试版，对这个咱们的信念指数是 50，为什么只有 50% 的把握？
咱们后面解决的问题都是解决用户能摇到红包，服务器还不会坏掉，然而对摇红包来说那是第一步，前面还有好几步，还要把红包拆出来，还要分享，分享完当前其它人能够抢，这个体验是要保障的，简略剖析一下能够发现后面是自己操作，前面是好友操作，这里就存在一个契机，你能够做一些服务，一旦呈现问题是能够利用的点，能够做延时。剩下的问题是保障自己操作比拟好，前面出点问题能够提早，有提早示意有时间差解决那个货色。
1、外围体验是什么？
这外面咱们须要确保胜利，确保体验是齐全 OK 的，确保胜利的时候后面提到原型的零碎里解决了摇到红包的问题，剩下的就是拆红包和分享红包。怎么样确保拆红包和分享红包的用户体验？
2、如何确保拆 / 分享红包的用户体验？
拆红包和分享红包能够做一下切割，能够切割成两个局部，一个是用户的操作，点了分享红包按纽，之后是转帐，对咱们来说确保后面一点就能够了，外围体验设计的货色再次放大范畴，确保用户操作这一步可能胜利。怎么确保呢？咱们称之为“铁三角”的货色，拆 / 分享红包 = 用户操作 + 后盾彰武逻辑。这是咱们能做到的最高水平了。
3、还能做得更极致吗？
但咱们还能够做的更好一点，后面这个用户看起来还是胜利的，只是入帐入的略微迟一点点，用户感觉不到。如果咱们异步队列这里挂了，或者网络不可用了，概率比拟低，咱们有三个数据中心，挂掉一个问题不大，万一真的不能用呢，咱们又做了一次异步，分两局部：一个是业务逻辑，校验这个红包是不是这个用户的，还有一个透传队列，把这个数据再丢到后边，其实能够置信本机的解决个别是能够胜利的，只有做好性能测试基本上是靠谱的。在前面呈现问题的时候咱们用户的体验根本不受损，保障绝大多数用户的体验是 OK 的。
V0.8 预览版
咱们又做了 0.8 的版本，预览版，信念指数 70，咱们认为这个货色有七成把握是能够胜利的。
大家晓得设计并不等于实现，设计的再好，实际有问题也很解体，要保障设计一是全程压测，二是专题 CODE REVIEW，三是外部演练，四是线上预热，五是复盘与调整。
复盘包含两局部，有问题的时候能够把异样问题看进去，二是很失常，跑的时候是不是跟设想的一样，须要对失常状况下的数据做预估的从新评估，看看是不是合乎预期。两次预热，一次是摇了 3.1 亿次，峰值 5000 万一分钟，100 万每秒，跟咱们估算的一千万每秒差很远，过后只是针对 iPhone 用户，放开一个小红点，你看到的时候能够抢，发放红包 5 万每秒，春晚当晚也是五万每秒。前面又发了一次，针对后面几个问题再做一次。
V1.0 正式版
做完这两次连贯前面就迎接 2 月 18 号春晚的真正考验。这是 1.0 正式版，信念指数达到 80，咱们认为 80% 是能够搞定的。
剩下 20% 在哪里？有 10% 是在现场，现场不可能一帆风顺，有可能现场摇的很 High，但前面到处灭火，10% 是在现场处理的时候有比拟好的预案和计划可能解决，另外 10% 是人算不如天算，一个很小的点呈现问题导致被放大所有用户受影响也是有可能的，咱们很难管制了。要做出白璧无瑕的根本不太可能，剩下 10% 就是留运气。
2 月 18 号跑进去的后果是这样的，过后摇了 110 亿次，峰值是 8.1 亿每分钟，1400 万每秒。
