从事软件开发多年本机网络限速软件，我更喜欢架构设计。无论是电商系统、社交系统还是金融系统，我基本上都涉足过。
对于初级工程师来说，最基本的要求是实现功能，但对于高级工程师和专家工程师来说，更多的是架构和性能。
今天我们就来说说红包。你可能会好奇：春晚的微信红包是如何支撑100亿请求的？那么，我们就来看看今天的分享吧。
今天我要跟大家分享的话题是如何实行“自信”的春晚摇一摇制度。回忆一下春晚的活动，都有哪些活动呢？
当时我们直接复用了客户端摇一摇入口，专门为春晚摇一摇定制了一个页面，可以摇出“现金拜年”和“红包”。最下面的红包肯定是大家感兴趣的，也是今天下午介绍的重点。更精彩的活动背后，一定有更独特设计的系统。
V0.1原型系统
我们来看看这个系统。当时我们做了一个原型系统。这相对简单。已经实现了所有的功能。当你摇动手机时，它会通过客户端发送请求，访问服务器，然后摇动服务执行关卡。判断。判断后，将结果交给后端。可能是新年祝福，也可能是红包。假设你收到一个红包，上面有LOGO和背景图片。客户端会将这个LOGO与背景图一起拉回来，用户及时打开红包。开红包请求会进入红包系统。红包系统处理后，会转到财富通的支付系统和转账系统，最终用户获得红包。拿到钱后只能分享其中一份，还有其他几份可以分享。我们称之为“分红包”，通过信息系统转发给好友或者群里的人。朋友和群里的人可以再抢一轮。
整个流程可以归为一类：资源流、信息流、业务流、资金流。今天我们主要讲资源流和信息流。
原来的系统看起来比较简单。可以直接修改一下，直接用在春晚上吗？绝对不是。它有什么样的问题？为什么我们不能使用它？在回答这个问题之前，我想请大家看一下我们面临的挑战。
1. 我们面临哪些挑战？
第一个挑战相对容易想到。用户请求数量巨大。当时估计有7亿观众，微信用户也相当多。当时预计峰值将达到每秒1000万。与图片进行比较。左边是春运高峰。抢火车票时，每秒请求峰值为12万次。第二个是微信系统。微信系统发送消息存在一个小高峰。当时峰值为每秒33万。较高者为估计值 1,000。每秒百万，右侧春晚期间达到的峰值请求为每秒140万。
本次活动与春晚互动密切，不确定性较多，体现在几个方面。一是在发展过程中，我们的活动如何与春晚合作，目前还没有确定。很可能会持续到春晚开始前。显然我们的客户端和我们的系统在那之前不会发布。这个时候我们的开发就会遇到很多问题，这是第一个。
第二个挑战是在春晚期间。因为春晚是直播节目，节目可能会变，时长可能会变，顺序也可能会变。活动过程与春晚节目紧密相连，我也会有挑战。这也是不确定因素。而且我们的系统是定制的，专门为春晚定制的，只能运行一次。这是一个很大的挑战。运行一次的系统就无法长期运行。很难检查其中是否存在问题。发出去之后，那次要么成功，要么失败。
第三个挑战是，因为春晚观众众多，全国人民都在观看、关注，所以一定要确保成功。如果我们搞砸了，我们就会在全国人民面前搞砸。如此大规模的活动在行业内并不多见，缺乏经验和借鉴。还有就是我们需要做什么样的准备，才能保证一切都是万无一失或者万无一失的，保证大部分的用户体验是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 个 Shake 访问服务示例。如果我们强制不同的机器，我们有长连接，短连接，并且另一台服务器可以连接到不同的地方。另一个问题是人群策略。有的人抢了几万、几十万的账号，抢到的都是你的。那么你应该做什么呢？没有什么好的方法可以做到这一点。使用大数据分析来查看用户行为。您通常维护帐户吗？您平时维护账户吗？它将被注册。
如何与春晚保持互动？有两个问题需要解决。一是要快，不要花太长时间。例如，刘德华现在正在唱歌，如果给定的星摇不适合之前的节目，我们就需要快速更改配置。第二是可靠。我们是怎么做到的？
我们特地有学生去参加春节联欢晚会。他们已经在自己的电脑上安装了该系统，并且可以与我们的后端进行交互。当程序发生变更时，变更请求将被发送到后端。我们部署了两套，一套在深圳，一套在深圳。一套在上海。在此配置中，还准备了三步服务。哪一个步骤你都可以做这个，也可以同步这个数据。这个数据也可以发送到所有接入机，并且会同步，不是用一种方式，而是用三种方式。这样的话，你很快就可以在1000台服务器上成功的话，是不是能够实现配置并能够使用呢？未必。春晚现场一发不可收拾。如果订单没有发出怎么办？如果六个配置服务全部关闭怎么办？如果从上一个程序切换到下一个程序时发生这种情况，问题不大。但如果主持人在10点30分摇动红包，没有任何反应，那就什么也没有发生。他生气了，口播发不出来，就死了。
如何？主持人必须有语音广播。我们一般都知道语音广播的时间，尽管我们不知道确切的时间。例如，排练时告诉我们一个时间，但后来就改变了。我们一般都知道时间范围，可以配置倒计时，比如10点30分，不管你有没有发言，我们都会发红包。如果节目延迟太长，你的红包在十分钟内就发完，之后无法摇动，那就不行了。针对这种情况，我们进行了修正。节目过程中，我们不断修正倒计时时间，制定策略。流程已经定了，需要半小时后通知我时间，因为是预估的。程序进行得越晚，时间范围就可以越精确。如果您提前告诉我们，我们可以调整。当时的场景是春晚期间的一个小会议室。我看不到小会议室里发生了什么。我也是通过电视看到的。结果电视没信号，看的很模糊。我不知道现在发生了什么以及校准过程中进行到哪一步了。当时心里很着急，不过幸运的是一切都没有问题，后续的程序也都修正回来了。结果我们正好在那个时间出现去抢红包。我讲了如何解决系统中的流量问题和请求量问题。最重要的一点是，我们估计是每秒1000万，但是如果春晚出来的人数是2000万、3000万、4000万呢？好的，整个系统都瘫痪了吗？
我们只是使用过载保护。过载保护的中心点是两点。前端保护后端，后端排斥前端。一种是在客户端埋一个逻辑，让每次摇动都变成一个请求，每隔十秒或者五秒发送一次请求。这样可以大大减轻服务器的压力。这种情况只会发生在几点，一是服务无法访问、服务访问超时、服务速度受限。实时计算访问负载，看看CPU负载，在连接点返回一个东西给这个服务器的用户，就是你想限速，你用哪个限速。这样一来，当时的用户就有了4000万。即使用户动摇我们，我们也能应对。
V0.5测试版
这是我们的 0.5 测试版。我们对此的信心指数是 50。为什么我们只有 50% 确定？
我们之前解决的问题都是用户能够在服务器不宕机的情况下摇红包。但对于摇红包来说，那是第一步。还有几个步骤需要遵循，包括拿出红包并分享。 ，分享后其他人也可以抢到。这种体验必须得到保证。简单分析一下就可以知道，第一个操作是我自己操作的，后面一个操作是朋友操作的。这里有一个机会。您可以提供一些服务，如果出现问题您可以利用它们。点击，可以做延迟。剩下的问题就是保证我操作好，以后如果有什么问题，我可以拖延一下。如果有延迟，就说明处理那件事有时间差。
1、核心体验是什么？
这里我们需要保证成功，保证体验完全OK。在保证成功的情况下，前面提到的原型系统解决了摇红包的问题，剩下的就是开红包和分享红包了。如何保证开红包、分享红包的用户体验？
2、如何保证开红包/分享红包的用户体验？
开红包和分享红包可以分为两部分。一种是用户的操作，点击分享红包按钮，然后进行转账。对于我们来说，保证第一点就足够了，这就是核心体验设计。再次缩小范围，保证这一步用户操作能够成功。如何确保这一点？我们称之为“铁三角”，分割/分享红包=用户操作+后台逻辑。这是我们能做到的最高水平。
3. 还能做得更好吗？
但我们可以做得更好。前面的用户看起来是成功了，但是进入的有点晚了，用户感受不到。如果我们的异步队列挂在这里，或者网络不可用，概率是比较低的。我们有三个数据中心，其中一个挂了问题也不是很大。如果实在用不了，我们就再做一次异步，分为两部分：一是业务逻辑，验证红包是否属于这个用户。还有一个透传队列，将数据抛到后面。其实可以相信，本地处理一般都能成功。只要做了性能测试，基本上是可靠的。后期出现问题的时候，我们用户的体验基本不会受到影响，保证绝大多数用户的体验是可以的。
V0.8预览版
我们做了0.8版本，预览版，信心指数70。我们认为这个东西有70%的把握会成功。
图像
大家都知道，设计不等于实现。设计再好，实践中出现问题也会崩溃。我们要保证设计首先是充分的压力测试，其次是专门的CODE REVIEW，第三是内部演练，第四是在线热身，第五是回顾。磁盘和调整。
审查由两部分组成。当出现问题时，可以发现异常问题。第二部分是这是正常的。运行时是否按预期运行？正常情况下需要重新评估数据，看是否正常。正如预期的那样。两次预热，一次摇晃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万次。
超过
我的新书《深入理解Java核心技术》已经上线了。自上市以来一直位居京东畅销榜。目前它正在以 40% 的折扣出售。想要购买的朋友一定不要错过~长按二维码即可购买~
长按扫码即可享受40%折扣
过去推荐的
有方法无技巧，有技巧就能成功；有方法，无技巧，就可以成功。如果你有技术而没有办法，那就止步于技术。
