对于初级工程师来说，最基本的要求是实现功能，但是对于高级工程师和专家级工程师来说，更应该关注架构和性能。今天，我们来说说红包。你可能会疑惑：春晚的微信红包是如何处理百亿请求的？那么，让我们一起来看看今天的分享吧。今天和大家分享的话题是如何实现“确定”的春晚摇系统。回顾春节联欢晚会的活动，有哪些活动？当时我们直接复用了客户端的摇一摇入口，专门定制了一个春晚摇一摇的页面，可以摇出“现金拜年”和“红包”。下面这个红包想必大家也很感兴趣，也是今天下午要重点介绍的内容。更精彩的活动背后一定有更独特设计的系统。V0.1原型系统让我们来看看这个系统。我们当时做了一个原型系统，比较简单。它已经实现了所有的功能。摇动服务来判断水平。判断后将结果发送给后台。它可能会被摇到拜年或红包。假设摇晃红包，上面有LOGO和背景图。客户端拉回LOGO和背景图，用户及时打开。拆红包的请求会来到红包系统。红包系统处理后，会进入支付系统，再进入财富通的转账系统，最终用户拿到红包。拿到钱后，只能分一份，还有几份可以分。我们称之为“分红包”，通过信息系统转发给好友或群，好友和群内的人可以再抢一轮。整个过程归为一类，称为资源流、信息流、业务流、资金流。今天我们主要讲的是资源流和信息流。原来的系统看起来比较简单，可不可以修改一下直接在春晚使用？当然不是。它有什么样的问题，为什么我们不能使用它？在回答这个问题之前，我想请大家先看看我们面临的挑战。1.我们面临哪些挑战？第一个挑战比较容易想到。有很多用户请求。当时估计有7亿观众，微信用户也不少。当时估计那个时候的峰值能达到1000万/秒。对比一下图片，左边是春运。抢火车票时，峰值请求每秒12万。二是微信系统。微信系统发送消息出现小高峰。当时峰值是33万/秒，更高的估计是1000。10000/秒，右边春晚期间达到的峰值请求是1400万/秒。本次活动与春晚互动紧密，不确定因素较多，体现在几个方面。一是在发展过程中，我们的活动如何与春晚协调，还没有定下来。很可能会持续到春节联欢晚会开播。显然，我们的客户端和我们的系统在那之前不会发布。这时候我们的开发就会遇到很多问题，这是第一个。第二个挑战是春晚期间，因为春晚是直播节目，节目可能会变，时长会变，顺序会变。活动流程紧扣春晚节目。不确定因素。而且我们的系统是专门为春晚定制的，只能运行一次。这是一个相当大的挑战。系统运行一次需要很长时间，而且很难检查出有什么问题。发出去之后那个时候不是成功就是失败。第三个挑战，因为春晚的观众很多，全国人民都在看，都在关注。一定要确保成功，如果搞砸了，就会在全国人民面前搞砸。如此大型的活动在业内实属罕见，缺乏经验，无从借鉴。还有就是我们需要做什么样的准备，才能保证没有问题，保证大部分的用户体验是OK的。有很多问题需要我们不断探索和思考。原型系统不能再用了，再用可能就挂了。2、原型系统存在哪些问题？原型系统存在哪些问题？第一个是流量带宽。大量的用户请求会产生大量的带宽。峰值带宽估计为每秒3000pb。假设我们的资源是无限的，无法满足带宽需求，我们也会遇到一个问题。有进程等待下载。第二个问题，在接入质量上，我们估计大约有3.5亿用户同时在线，尤其是在外网波动的情况下，如何保证用户体验不受损，系统正常运行。第三个挑战是请求量非常大，1000万/秒。如何切换到改组服务。改组服务还面临1000万个请求。我们的系统要同时面对两个1000万的请求。它不是基于机器。每个人都有分布式经验。这么大的请求量，任何波动都会出问题。这是一个很大的挑战。3.我们如何解决这些问题？针对以上几点，下面我们来详细看看我们是如何做到每一点的。我们先看信心指数，这个系统跑春晚有多大的信心，这里的指数是10，如果这个系统用在春晚上，成功的概率是10%。我们的制度当然不能靠运气，怎么办？第一个是客户端在带宽方面可以获得多种结果。大多数结果是静态资源。我们可以提前做好静态资源发送给客户端，后台提供资源推送服务。客户端拿到列表后，可以先下载，客户端利用空闲时间把资源拉过来。遇到了几个问题，资源下发的问题需要增量发送；二是资源更新；三是资源下载失败，失败怎么办；第四是资源覆盖，依赖这个系统下载资源的用户，比如覆盖率只有20%或者30%，这两个东西是没有意义的，覆盖率应该达到90%左右；五是下载线下资源。如果有人修改里面的内容，可能会出现意想不到的结果，如何保证线下资源的安全。这里有一个数据，从2月9日到2月18日，发布了65个资源，累计流量3.7PB，峰值流量1Tb/s。这样就解决了下载资源的问题。然后是外网访问的质量。上海、深圳已建成18个接入集群。每个城市都涉及三个网络。共部署接入服务器638台，可同时支持14.6亿个在线连接。所有的用户请求都会进入访问服务器。我们建立了18个访问集群，保证其中一个用户出现问题，该用户可以通过另一个访问，但是我们如何在内部将请求传递给Shake服务呢？摇一摇后转到后台怎么解决？解决这个问题非常昂贵，需要大量资源。最终我们选择去掉摇一摇服务，秒杀1000万请求，将此服务移入访问服务。除了处理摇一摇请求外，所有的微信消息都需要中继接收和发送消息，因为接入服务本身，摇一摇的逻辑，因为时间比较短，如果消息也受到影响，得不偿失获得。只有一个优点。我们接入服务的架构有助于我们解决这个问题。这个访问节点被分成几个部分。一个负责网络IO，提供长链接。用户可以通过长链接发送消息。对于消息，后面可以将请求转发到另一个模块，即访问逻辑模块，通常提供转发的功能，现在可以插入访问逻辑。这还不够。比如我们现在稍微修改一下，就需要在线更新。摇一摇活动的形式还没有确定，中途需要修改，但是模块上线不对。一块再拆分，逻辑比较固定，比较轻量级可以在本地完成，不需要做网络交互的东西放到接入服务中。另一种涉及网络交互，需要经常更改，处理起来比较复杂。我做了一个代理人。这样就基本实现了接入内置的摇一摇逻辑，接入服务本身的逻辑也不会受到太大的破坏。解决了这个问题之后，访问稳定性的问题也就迎刃而解了。接下来的问题就是摇一摇怎么玩，摇一摇怎么玩就是红包怎么玩，红包过程中如何保证红包安全，红包涉及到钱，钱可不是闹着玩的。第三个问题就是怎么和春晚保持互动，春晚的直播，我们怎么和直播对接。我们先来看看红包是怎么发的。上面说的摇一摇请求其实是在接入服务中完成的，红包也是在接入服务中发出的。为了在发红包的过程中不依赖这个系统，我们在红包系统中生成红包种子文件，切分，分到各个接入服务器，每个接入服务器都部署了一个专门的红包文件。一个红包不能发两次。需要考虑红包发放率。红包必须由用户拆除，必须再次抢夺。我们需要精确的控制，保证所有的请求都在红包系统可接受的范围内。在这个过程中还会有另一个风险。用户摇红包后，可以分发一些拆分的红包。他也不能分享。他不分享，就不会浪费。它可以在当地回收和拉回。一方面是因为比较少，所以问题不大，因为所有的红包都已经发完了，只是补充而已。到这里我们就完成了红包的发放。二是如何保证红包不被过度、恶意索取。每个顾客收到三个红包。这是要限制的，但是这样做是有代价的，就是存储的成本。在我们的协议中，我们在连接后台服务的摇一摇文件中写了一个用户领取红包。当客户端再次发送摇一摇请求时，我们再提出来。我们可以检查一下。这是一个小技巧，这个方法解决了用户最多只能获得三个，企业只能获得一个的问题。这只能解决真正客户端的问题。恶意用户可能无法使用正版并绕过您的限制。这个有可能。怎么做？一种方式是在Agent中查看本机的数据来达到一个目的。通过摇一摇获得638个服务实例。另一台服务器可以连接到不同的地方。另一个问题是人群策略。有的人抢了几万、几十万账号，都是你的，怎么办？没有好的方法可以做到这一点。用大数据分析看用户行为。你平时会开户吗？你平时会开户吗？它将被注册。如何保持与春晚的互动？有两个问题需要解决。一是要快，不要拖太久。比如现在刘德华在唱歌，如果给定的星抖还是不适合之前的节目，我们就需要赶紧更改配置。二是靠谱。我们该怎么做呢？春晚的时候，我们特地让学生去，在他们的电脑上安装了系统，可以和我们的后台进行互动。当程序发生变化时，会向后台发送更改请求。我们部署了两套，一套在深圳，一套在上海。在此配置中，准备了一个三步服务。可以使用任何步骤。同时可以同步数据。这个数据也可以发到所有接入的机器上，同步。一种方法，不过三种方法，通过这种方法可以在上千台服务器上快速成功，是否可以实现配置必须能用？不一定，春晚场面不可控，不下令怎么办？如果六个配置服务都宕机了怎么办？从上一个节目切换到下一个节目问题不大，但是如果10:30主持人摇了红包什么都没有，这就是我生气了，嘴打不出来就挂了。你怎么做呢？主持人肯定有口播，我们大概知道口播的时间。虽然我们不知道具体时间，比如排练的时候告诉我们一个时间，但是后来就变了。我们大致知道时间范围，我们可以配置倒计时，比如10:30，不管你有没有发言，我们都会发红包。如果节目延迟时间太长，你的红包十分钟就发完了，后面摇不出来，那不行。在这种情况下，我们已经进行了更正。演出期间，我们不断修正倒计时时间，制定攻略。设置了一个流程，半小时后通知我这个时间，因为是估计的，越晚的程序越能确定时间范围。提前告诉我们，我们可以调整。当时的场景是在春晚的小会议室里。我看不到小会议室里发生了什么。我是通过电视看的。结果电视没信号，把我弄瞎了。我不知道发生了什么，也不知道它在校准中的位置。是的，我当时很着急，幸好后来什么事都没有，后面的程序都改正回来了。最后，我们似乎正好在那个时候抢红包。我讲了如何解决系统中的流量和请求量的问题。最重要的一点，我们估计是每秒1000万，但是如果春晚出来的人数是2000万、3000万、4000万呢？这样做，整个系统都会挂掉。我们只是采用过载保护，过载保护的中心点是两点，前端保护后端，后端拒绝前端。一种是在客户端嵌入一个逻辑，每次变成一个请求，每隔十几五秒发送一个请求，这样可以大大减轻服务器的压力。这种情况只会出现在少数几个点，a是服务无法访问，服务访问超时，服务速度受限。实时计算访问负载，看CPU负载，在连接点给这个服务器的用户返回一些东西，就是你要限速，你用哪个限速？这样一来，4000万的用户就算在抖，我们也能搞定。V0.5beta这是我们的0.5beta，我们对此的信心指数是50，为什么只有50%的把握？我们之前解决的问题都是解决用户可以摇红包的问题，??服务器不会坏，但是摇红包那是第一步，后面还有好几步，还有红包一定要拿出来分享。分享后，其他人可以抢购。必须保证这种体验。简单分析一下，前面是自己操作的，后面是朋友操作的。这里有一个机会。你可以提供一些服务。一旦有问题，可以用点，可以做延时。剩下的问题就是保证我的操作更好。如果后面有问题，可以延迟。拖延就是处理那个事情有时间差。1、核心体验是什么？这里要保证成功，保证体验完全OK，保证成功，前面提到的原型系统解决了摇红包的问题，??剩下的就是开红包分享红包了。如何保证用户开通和分享红包的体验？2、如何保证开通/分享红包的用户体验？拆包分享红包分为两部分，一是用户操作，点击分享红包按钮，然后进行转账。对我们来说，保证第一点就够了，核心体验设计再把范围缩小，保证用户操作能在这一步成功。如何保证？我们所说的“铁三角”，拆解/分享红包=用户运营+后台掌务逻辑。这是我们能做的最好的。3、能不能做得更极端一点？但我们可以做得更好。之前的用户貌似成功了，但是账号录入晚了一点，用户感觉不到。如果我们的异步队列在这里挂了，或者网络不可用，概率比较低。我们三个数据中心，挂一个问题不大。万一真的不能用，我们又做了异步，分为两部分：一个是业务逻辑，检查红包是否属于用户，还有一个透传队列，抛出数据到后面。其实相信这台机器一般都能加工成功，只要做好性能测试就可以了。这是可靠的。后面出现问题的时候，我们的用户体验不会受到损害，保证大部分用户的体验是OK的。对于V0.8预览版，我们做了一个0.8版本。预览版的信心指数是70，我们相信这个东西有70%的把握可以成功。我们都知道设计与实施不同。设计得再好，在实践中出现问题也会崩溃。确保设计，第一，全压测试，第二，专项CODEREVIEW，第三，内部演练，第四，在线预热，第五，ReviewDisc和调整。审查包括两个部分。出现问题时，可以看到异常问题。第二是这是正常的。运行时是否如预期？您需要重新评估正常情况下的估计数据，看看它是否正确。符合预期。两次预热，一次摇晃3.1亿次，峰值为每分钟5000万次，每秒100万次，与我们估计的每秒1000万次相去甚远。当时，它仅适用于iPhone用户。放开一个小红点。看到就抢，红包是5万每秒，春晚也是5万每秒。稍后再发一次，之前的题再发一遍。完成这两个连接后，V1.0正式版将迎接2月18日春晚的真正考验。这是1.0正式版，信心指数达到了80，我们认为80%可以做到。剩下的20%在哪里？10%在现场，现场不能一帆风顺，有可能现场抖动很大，但后面到处灭火，10%是处理时有更好的方案和解决方案场景，另外10%是人不如天啊，有可能一个小点出现问题，就会被放大，影响到所有用户，我们很难控制。想要做到完美基本不可能，剩下的10%就靠运气了。这是2月18日运行的结果。当时摇动110亿次，峰值为每分钟8.1亿次，每秒1400万次。
