手机支付普及带来的便利改变了中国人的春节传统。过去我们习惯拿一个写好祝福的红包，塞钱进去在过年时送给我们的父母、亲人、长辈晚辈。手机支付普及后，我们只需要掏出手机，就可以完成所有步骤。过去，红包代表着喜庆、祝福。现在，红包还多了一层娱乐的意味，有事儿没事儿发个红包玩玩儿。
移动支付唯一的问题在于，如果发红包的并发流量太高，服务器分分钟陷入宕机状态，想撒钱都没辙。罗振宇在 2019 年的跨年演讲中提到：得到原本打算在春晚投放广告，但是被劝住了，因为春晚红包有一条不成文的规定——要想春晚打广告，产品日活先过亿。原因很简单，用户量过低，技术很难支撑起春晚级别的高并发流量。
今天我们就带您盘点一下春晚红包的宕机史，看看再强的高并发能力在 13 亿人的春节传统面前都是怎样狼狈不堪的。
微信红包宕机史微信红包推出于 2014 年 1 月 27 日，从上线时间看，很明显微信团队瞄准的就是春节。于是，首次上线的微信红包火了。
2014 年除夕开始，至大年初一 16 时，参与抢微信红包的用户超过 500 万，总共抢红包 7500 万次以上。领取到的红包总计超过 2000 万个，平均每分钟领取的红包达到 9412 个红包活动最高峰是除夕夜，最高峰期间的 1 分钟有 2.5 万个红包被领取，平均每个红包在 10 元内。首战告捷背后，是部分服务功能的宕机，除夕当晚总有那么几分钟红包发不出去，查看红包金额也总是出错。
经过一年的积累沉淀、技术升级，2015 年，微信拿下了当年春晚的广告互动权。2015 年除夕当日中国微信红包收发总量达 10.1 亿次，春晚微信摇一摇总量达 110 亿次。微信红包成为年夜饭的主菜单。大家不再忙着发短信，不再忙着看春晚，都在忙着抢红包。春节联欢晚会摇一摇互动出现峰值 8.1 亿次每分钟。不难看出，2015 年的红包流量比起前一年的增长幅度可谓令人咋舌，有理由相信微信技术团队为了这次春晚互动做了充足的准备，然而即便如此，小规模的宕机依旧出现了数次。
今年的除夕红包数据，目测最少超过 7 亿人参与。大年三十临近跨年的时间段上，微信红包不出意外地再次宕机：群消息收发滞后，微信红包功能出现问题。小编也因此错过了一夜暴富的机会。昨夜公司群抢红包实况：同事们纷纷表示，可以根据抢到红包人的地区分布，得出哪些地方的服务没有宕机……
BTW，如果你年后有换工作的打算，可以在 拉勾网搜索极客邦科技 投递简历，诚挚期待您的加入。
微信红包的技术思路微信红包有两大业务特点，两大业务难点。
特点：
微信红包业务比普通商品“秒杀”有更海量的并发要求。
微信红包业务要求更严格的安全级别。
难点：
事务级操作量级大。
事务性要求严格。
解决方案：
系统垂直 SET 化，分而治之。
逻辑 Server 层将请求排队，解决 DB 并发问题。
双维度库表设计，保障系统性能稳定。
更多技术细节，你可以在文末附录区查看。
支付宝红包宕机史有媒体人说，微信红包宕机是因为没有经历过类似双十一事件的高并发考验，那么阿里系的支付宝在做红包活动时，做到尽善尽美了吗？答案是也没有。
根据支付宝官网数据：2016 年除夕，支付宝互动平台的总参与次数达到 3245 亿次，是 2015 年春晚互动次数的 29.5 倍。在 21 点 09 分达到峰值 210 亿 / 分钟。有着阿里云支撑的支付宝红包，同样宕机了数分钟。
2018 年春晚，淘宝作为合作方再次登上舞台。据悉，淘宝技术团队提前预设了多种极端情况，在 2017 年双十一基础上扩容了 3 倍！但实际流量峰值却是 2017 年双十一但 15 倍！加上超出预料的新用户瞬时登录行文，多年双十一高并发洗礼下的阿里服务器也宕机了。
支付宝红包的技术思路在支付宝团队看来，春晚活动具有 8 大难点，平时看不起眼的一个问题，在超大规模情况下，就可能被放大：
登录问题。
如何应对洪峰。
活动奖品控制系统。
动态技术。
资源管理。
实时数据计算能力。
全链路压测。
超大规模活动弹性计算能力。
为应对春晚流量，支付宝团队做了如下准备：
相对合理的超大规模压力预测模型。
核心链路和非核心链路彻底梳理。
大规模生产系统全链路压测。
高频次灰度内测和线上小规模活动预热。
上千个业务、技术预案和完备的应急响应体系支持。
更多技术细节，你可以在文末附录区查看。
出人意料的百度红包这是百度第一次站上春晚舞台，作为红包活动方出现。许多人此前并不看好百度能把红包活动做好，毕竟 BAT 里的 AT 两家已经连着小范围宕机多次。但昨晚猪年春晚的红包互动却出乎很多人意料之外。
昨晚第一轮摇一摇红包活动结束后，截至 21:00，全球观众参与百度 APP 红包互动就已经达到了 92 亿次。9 亿红包的数额、智能机的进一步普及、互联网加速下沉乡镇、农村，无不让移动支付里的红包热情强烈迸发。
根据知乎答主「maomaobear」的回答：
任何红包类、抽奖类活动还会有一个灰色的影子参与其中，这就是中国互联网的黑产用户，中国薅羊毛党手里掌握大量虚拟资源，它们可以在短时间内产生巨大流量，这部分流量叠加正常流量，也进一步加大了服务器的压力。
另外，因为抢红包这个东西，是有一个流程的，涉及很多外部服务，百度自己的服务器只是其中一个环节。没下载的用户下载百度 APP，没注册的注册，注册的收短信要通过电信运营商，所有网络需求都要通过硬件。APP 市场的服务器，电信运营商的网络，机房、光纤等硬件，有一个环节容量不够，都可能导致宕机。
事实上，春晚当天百度的第一轮红包互动之后，苹果应用商店、华为、小米、三星几大应用商店全部挂掉，其中苹果应用商店长达 12 分钟不能访问，今年的流量显然远超预期。在春晚直播期间，全球观众参与百度 APP 红包互动活动次数达 208 亿次！但是，百度扛住了。
据了解，为了准备这次春晚活动，百度下了大力气做技术储备：
在确定拿下春晚红包互动权后，百度成立了一个近千人的项目组，包括产品、研发、运营、客服以及风控，应对爆发数量的需求。在技术方面，百度很早就落实了服务流量隔离、系统升级、专线新增以及服务器扩容等工作，提前进行了多轮全链路压力测试和多轮的方案预演。在硬件资源上，除了常规的扩容，百度还使用专有硬件计算（特定 CPU，或者 GPU、FPGA 等硬件），处理大规模 AI 计算需求；准备最大规模硬件资源，处理十亿级别并发需求。据说整个系统在内部都是全自动扩容缩容，数万台机器，响应每秒数千万的请求，并支持快速扩展支持更多请求处理。
值得一提的是百度并不只是靠计算能力硬抗，百度有小程序的技术优势。百度这次的摇一摇红包和视频红包等都采用小程序开发，用小程序技术支持更灵活的开发和预加载机制，不仅能够应对更大流量更大并发，降低硬件资源消耗，提升效率，还有更好的用户体验。
—————END—————
喜欢本文的朋友们，欢迎关注公众号 程序员小灰，收看更多精彩内容