本文以抽奖系统为例，探讨如何应对瞬时超高并发流量。通过在负载均衡层防止用户重复抽奖和拦截无效流量，以及优化Tomcat线程数量，来确保系统稳定运行。在负载均衡设备中设置1分钟内同一用户抽奖限制，全部开奖后通过共享状态（如Redis或ZooKeeper）拦截后续请求，减少后台压力。对于Tomcat，适当调整线程数以平衡资源利用和处理能力。
比如抽奖，有一种场景：某个网站或者APP规定好了在某个时间点，所有人都可以参与抽奖，那么可能百万级的用户会蹲守在那个时间点，到时间大家一起参与这个抽奖。
抢红包，可能是某个电视节目上，突然说扫码可以抢红包，那么电视机前可能千万级的用户会瞬间一起打开手机扫码抢红包。
秒杀更是如此，所谓秒杀，意思是让大家都在电脑前等着，在某个时间突然就可以抢购某个限量的商品
比如某个手机平时卖5999，现在限量100台价格才2999，50%的折扣，可能百万级的用户就会蹲守在电脑前在比如凌晨12点一起点击按钮抢购这款手机。
类似的场景其实现在是很多的，那么本文就用一个抽奖系统举例，说说应对这种瞬时超高并发的流量，应该如何设计流量削峰的架构来应对，才能保证系统不会突然跨掉？
2、结合具体业务需求分析抽奖系统
假设现在有一个抽奖的业务场景，用户在某个时间可以参与抽奖，比如一共有1万个奖，奖品就是某个礼物。
然后参与抽奖的用户可能有几十万，一瞬间可能几十万请求涌入过来，接着瞬间其中1万人中奖了，剩余的人都是没中奖的。然后中奖的1万人的请求会联动调用礼品服务，完成这1万中奖人的礼品发放。
简单来说，需求场景就是如此，然而这里就有很多的地方值得优化了。
3、一个未经过优化的系统架构
先来看一个未经过任何优化的系统架构，简单来说就是有一个负载均衡的设备会把瞬间涌入的超高并发的流量转发到后台的抽奖服务上。
这个抽奖服务就是用普通的Tomcat来部署的，里面实现了具体的抽奖逻辑，假设刚开始最常规的抽奖逻辑是基于MySQL来实
最低0.47元/天 解锁文章
扫一扫
714
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
