关于春晚红包活动自己的思考

概述

2019年春晚，百度的抢红包活动和观众互动的总次数为208亿次。春晚红包的互动为四轮，也就是说每轮大概为40亿次到60亿次之间。每次如果是持续半小时的话，平均每秒钟要承受的要超过300万次。峰值肯定要超过千万。整体体验完美完成任务。
从抢红包来到世界后，2015年微信与春晚首次合作发红包，综合数据显示，央视春晚摇一摇次数达110亿次，峰值每秒是千万次，送出微信红包1.2亿个。不过春晚开始后不久，微信红包功能就在较短时间内不能使用，不少网友反映发红包卡顿，甚至有网友遭遇了红包发出后消失的糟心事。2016年情况继续。2018年，阿里的红包系统在度出现部分崩溃。解释是新增用户过多，导致出现注册系统出现了限制流量的情况。如果这个辩解是真的，那么阿里的核心系统应该是扛住了抢红包的流量。

抢红包是类似一个抢购系统。也有如下特点：

• 允许在有库存时抢购失败
• 必须快速将结果返回给用户

第一点允许我们在设计这个系统时在很多地方偷懒。
第二点决定了我们不等采用异步队列解决这个问题。例如网页端的抢购，我们可以采用一个队列来排队请求，然后采用反向ajax的技术将结果推送给客户端。这里肯定是不行的。
关于如何在实现无锁的排队，请参考
https://blog.csdn.net/define_us/article/details/82800675
关于如何实现普通的商品抢购系统
https://www.jianshu.com/p/aaa12e90e9b9

流量分割

调整参数后，业界一般认可的单台服务器最大TCP连接数为几十万。当然优化以下上百万并不是不行。但是几十万的数目应该已经是够用。
https://blog.csdn.net/pyxllq/article/details/80347923
全中国几亿个设备参与的话，也至少需要上千台服务器。应该将用户分到离自己最近的服务器上来减小网络耗时。这就是我们用来扛住用户流量的第一层。

我们绝不会让所有流量都涌入第二层，比如说我们的中奖概率（所有红包）的概率是1/5，那么我们就应该只允许1/5的流量进入第二层。其他直接返回失败或者提前准备好的不限数量的优惠券即可。这些流量我们应该根据中奖的红包大小对应的概率分配到不同的第二层服务器上。

前端保险

高并发的情况下响应必然会变慢。系统越是相应不及时，用户的请求往往越频繁。这是一个恐怖的循环。所以，我们需要在系统的最前面加上再系统一定负载条件下拒绝服务的保护。

抢购的实现

我在百度抢红包服务器上收获了的红包大概是8分前到一毛六。也就是百度至少需要准备十几种被抢购商品（SKU）。请允许我怜悯一下全站都是抢购商品的12306…第二层服务器大概需要十几种。每种服务器又至少需要上百台。这上百台服务器可以共享一个库存数字，也可以用几个分区的库存数字。
抢购就是对库存数字的修改，无非是分布式锁，也无非是乐观锁和悲观锁。
库存数字合理的做法应该是放在缓存中。缓存这里应该是高可用的而且可以持久化的。不然缓存崩溃会立刻造成数据丢失和服务崩溃。开启高可用和持久化好无疑问都会降低缓存的写性能。考虑到缓存预热过程，在抢红包的系统中重启缓存几乎是不可能的。所以高可用才是核心。

Redis是抢购系统常使用的方案。

事后校验

百度抢红包活动结束后，并不能立刻查阅金额。这里，应该是一个很聪明的产品设计来加保险的模式。这段时间应该是给予百度后台工作人员一个事后核验的机制。如果发现不正常的数据，可以及时予以修正。