【Java每日面试题】大厂是如何设计秒杀系统的？，2024年最新java开发工程师面试问题汇总_程序员面试 系统设计题

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

使用各种手段，将流量分担到更大宽度的时间点。比如验证码，加入购物车。

限流、熔断、降级

---

前端限流+后端限流 限制次数，限制总量，快速失败降级运行， 熔断隔离防止雪崩。

队列削峰

---

1万个商品，每个1000件秒杀。双11 所有秒杀成功的请求，进入队列，慢慢创建 订单，扣减库存即可。

高并发系统设计的三个目标：性能、可用性和可扩展性。

在提升系统性能方面我们一直关注的是系统的查询性能，比如数据库的分布式改造，各类缓存。因为大部分场景都是读多写少。

比如一个社区系统初期一定是只有少量的种子用户在生产内容，而大部分的用户都在“围观”别人在说什么。此时，整体流量较小，而写流量可能只占整体流量的百分之一，那么即使整体的QPS到了1w，写请求QPS也只是到了100，如果要对写请求做性能优化，性价比不高。

但随着业务发展，可能遇到一些存在高并发写请求场景，比如秒杀。假设你的商城策划了一期秒杀活动，活动在第五天的00:00开始，仅限前200名，那么秒杀即将开始时，后台会显示用户正在疯狂地刷新APP或者浏览器来保证自己能够尽量早的看到商品。

这时，你面对的依旧是读请求过高，那么应对的措施有哪些呢？

优化方案

---

丢弃订单

最早期，量太大扛不住，直接前端随机reject一些，返回抢单失败，简

单粗暴，但是有效，比如10万人抢100个iPhone，只要能提前预测有大概1万以上的人参与(通过资格确认、报名等方式收集信息)，那么直接请求进来以后随机挡回去

99%的流量都没有啥问题。

优化吞吐

中间有段时间，提前准备一大批机器，服务化、分库分表搞定后端性能，让前端业务可以加一定量的机器，然后搞稳定性，依赖关系，容量规划，做弹性，提升吞吐量。

异步队列

使用可堆积的消息队列或内存消息队列。若抢单具有强顺序，则先都进队列，然后拿前N (就是库存数)个出来平滑处理，剩下都可作为失败进行批处理，甚至还可以做一个定长队列，再往里写直接提示失败。队列把并发变成串行，从而去掉了分布式锁。

内存分配

某些业务可以考虑预热，提前在每个机器节点内存分配好库存数，然后直接在内存处理库存数。

拆分扩展

对于不同类型、不同商家、不同来源的商品，部署不同的前端促销集群，

分散压力。比如，按每个整点发起秒杀，具体到每个商家，其实量就不大了。

服务降级

越重要的抢单，大家越关心自己有没有抢到，而不是特别在意订单立即处

理完，也就是说，下单占到位置比处理完成订单要更有价值。比如12306春运抢票，只要告诉用户你抢到了票，但预计1个小时后订单才会处理完，用户有这个明确预期即可。用户不会立马使用这张票，也不会在意1min还是1h内处理完。

部分方案会导致销售不足或超卖：

• 销售不足可以从抢购里加一些名单补发，也可以加一轮秒杀

• 超卖比较麻烦，所以一般会多备一点货，比如抢100个iPhone，提前准备110 个

因为用户查询的是少量的商品数据，属查询热点数据，可采用缓存将请求尽量挡在上层缓存，能被静态化的数据（比如商城里的图片和视频数据）尽量做到静态化，这就可命中CDN节点缓存，减少Web服务器的查询量和带宽负担。Web服务器比如Nginx可以直接访问分布式缓存节点，从而避免请求到达Tomcat等业务服务器。

当然，你可以加上一些限流的策略，比如对短时间之内来自某一个用户、某一个IP或者某一台设备的重复请求做丢弃处理。

通过这几种方式，请求就可以尽量挡在数据库之外了。

稍微缓解了读请求之后，00:00分秒杀活动准时开始，用户瞬间向电商系统请求生成订单，扣减库存，用户的这些写操作都是不经过缓存直达数据库的。1秒钟之内，有1万个数据库连接同时达到，系统的数据库濒临崩溃，寻找能够应对如此高并发的写请求方案迫在眉睫。这时你想到了消息队列。

理解消息队列

把消息队列看作暂时存储数据的一个容器，它是一个平衡低速系统和高速系统处理任务时间差的工具。

比如古代臣子朝见皇上陈述国家大事，等皇上决策。但大臣很多，如果同时去找皇上，皇上肯定会崩溃。后来变成臣子到午门后要原地等皇上将他们一个一个地召见进大殿商议，这就缓解皇上处理事情的压力。

可以把午门看作一个暂时容纳臣子的容器，即消息队列：

• 在Java线程池中我们就会使用一个队列来暂时存储提交的任务，等待有空闲的线程处理这些任务

• os中断的下半部分也会使用工作队列来实现延后执行

• 实现一个RPC框架时，也会将从网络上接收到的请求写到队列里，再启动若干个工作线程来处理

那如何用消息队列解决秒杀场景下的问题呢？

削去秒杀场景下的峰值写流量

在秒杀场景下短时间之内数据库的写流量很高，按以前思路，应该分库分表。若已做了分库分表，则需要扩展更多数据库应对更高写流量。

但无论是分库分表还是扩充更多数据库都会很复杂，因为你需要迁移数据库中的数据，这个时间就要按天甚至周计算。

而在秒杀场景下高并发的写请求并不是持续的，也不是经常发生，而只有在秒杀活动开始后的几s或十几s时间内才存在。

为了应对这十几s瞬间写高峰，而去花费几天甚至几周扩容DB，再在秒杀之后花费几天做缩容，得不偿失！

所以思路是：将秒杀请求暂存在MQ，然后业务服务器会响应用户“秒杀结果正在计算”，释放了系统资源之后再处理其它用户请求。

在后台启动若干个队列处理程序消费MQ中的消息，再执行校验库存、下单等逻辑。因为只有有限个队列处理线程在执行，所以落入后端DB上的并发请求有限。而请求是可以在MQ被短暂堆积，当库存被消耗完后，消息队列中堆积的请求就可以被丢弃了。

这就是MQ在秒杀系统中主要作用：削峰填谷，可以削平短暂流量高峰，虽说堆积会造成请求被短暂延迟处理，但只要我们时刻监控MQ中的堆积长度，在堆积量超过一定量时，增加队列处理机数量来提升消息处理能力即可，而且秒杀用户对于短暂延迟知晓秒杀的结果也有一定容忍度。

注意是“短暂”延迟，若长时间没有给用户公示秒杀结果，则用户会怀疑秒杀活动有黑幕。所以在使用MQ应对流量峰值时，需要对队列处理的时间、前端写入流量的大小、数据库处理能力做好评估，然后根据不同的量级来决定部署多少台队列处理程序。

比如你的秒杀商品有1000件，处理一次购买请求的时间是500ms，那么总共就需要500s的时间。这时你部署10个队列处理程序，那么秒杀请求的处理时间就是50s，也就是说用户需要等待50s才可以看到秒杀的结果，这是可以接受的。这时会并发10个请求到达数据库，并不会对数据库造成很大的压力。

通过异步处理简化秒杀请求中的业务流程

最后，附一张自己面试前准备的脑图：

面试前一定少不了刷题，为了方便大家复习，我分享一波个人整理的面试大全宝典

• Java核心知识整理

• Spring全家桶（实战系列）

Step3：刷题

既然是要面试，那么就少不了刷题，实际上春节回家后，哪儿也去不了，我自己是刷了不少面试题的，所以在面试过程中才能够做到心中有数，基本上会清楚面试过程中会问到哪些知识点，高频题又有哪些，所以刷题是面试前期准备过程中非常重要的一点。

以下是我私藏的面试题库：

很多人感叹“学习无用”，实际上之所以产生无用论，是因为自己想要的与自己所学的匹配不上，这也就意味着自己学得远远不够。无论是学习还是工作，都应该有主动性，所以如果拥有大厂梦，那么就要自己努力去实现它。

最后祝愿各位身体健康，顺利拿到心仪的offer！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）
[外链图片转存中…(img-hRQ0Ox6w-1713286290431)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！