字节面试题：抖音大V直播间，200万QPS如何设计？

见字如面，我是军哥！

前几天，我和朋友架构师伦哥去字节面试，遇到如题的面试场景题，他感觉答的一般，我问了一下这个场景面试题的上下文，我来尝试答一答。

下面的文章，采用一问一答形式还原真实面试场景，大家来看看，我这个水平还行吗？

面试官：给你出道超难的场景面试题！我们公司抖音大V直播间，粉丝过亿，500 万人在线，100 万单商品瞬间被抢，下单并发高达 200 万QPS。结果，评论区卡死，商品页白屏，库存服务挂了，订单系统也崩溃了！这是咋回事？

我：面试官，这可不是普通的技术难题！库存服务挂了，订单系统也跟着崩，肯定是服务依赖没处理好，或者压测不到位，引发了连锁反应。

面试官：哈哈，思路不错！但关键问题来了：如果你是这个系统的负责人，你觉得问题的根源到底在哪？

我：面试官，我觉得问题的核心是系统缺乏“防护机制”。一个服务挂了，其他服务也跟着崩，这就像是“多米诺骨牌”效应。

问题可以总结为三点：

1. 流量失控：没有限流、削峰措施，高并发直接把系统压垮了。

2. 强依赖：服务之间耦合太紧，库存挂了，订单也跟着受影响。

3. 隔离不足：资源和逻辑没隔离，单点故障迅速蔓延，整个系统瘫痪。

面试官：如果让你来设计，如何避免这种悲催的局⾯？

我：我会⽤我最厉害的三板斧——拦、缓、隔来解决这个棘手问题：

第一个拦：拦截和限制流量，⽐如限流、熔断，阻挡过量流量冲击系统，通过压测提前 知道库存服务和订单服务的最⼤承载能⼒，⽐如库存服务的极限是50万 QPS。在⾼于这个阈值时，直接限流或降级，保证服务不被压垮。  

第二个缓：缓解系统压⼒，⽐如通过缓存、排队等⽅式削峰填⾕，提升系统吞吐能⼒。 比如，订单太多就先排队，让用户知道“别急，慢慢来”，这样系统压力小多了。

第三个隔：隔离故障域，把问题限制在局部，不影响全局，⽐如服务隔离、线程池隔 离、资源隔离，防⽌故障蔓延。 

这三板斧一出，系统稳如泰山，抗压能力直接拉满！

面试官：说的有那么点道理，但我不确定你是不是ppt架构师，先来深入聊⼀下你的第⼀板斧，假设库存服务挂了，你在订单服务设计了熔断机制，⽤户下单会直接返回‘库存紧张ʼ的提⽰，系统勉强还能运⾏。

但接下来，⽤户疯狂重试，导致订单服务的压⼒暴增，线程池很快被打满，系统依然崩了！你觉得问题出在哪里？除了熔断，还有什么更好的方案么？

我：嗯，这个问题的核⼼其实不在熔断本⾝，⽽在于⽤户⾏为和系统承载能⼒之间的⽭盾。熔断确实能保护库存服务，但它没有考虑到⽤户‘疯狂重试ʼ这种常⻅的⾏为模式，导致订单服务压⼒暴增。

换句话说，熔断只是‘断了依赖ʼ，但没有‘断掉压⼒ʼ，所以系统依然会崩。

 讲真，熔断机制的本质是保护下游服务，但它对⽤户⾏为没有约束，所以此时光靠熔断显然是不够的。还需要结合其他的⼿段，⽐如限流、⽤户反馈优 化、异步排队等，让系统不仅能‘断依赖ʼ，还能‘断冲击ʼ。

面试官：那具体怎么做呀？

我：我从 2 个方面说下我的做法：

首先，在订单服务上增加限流机制，限制单个用户短时间内只能提交一次订单请求，防止“疯狂重试”压垮服务（可通过缓存记录访问频率，即白名单机制）。同时优化给用户提示文案，如返回“系统繁忙，请稍后再试”或排队信息，避免用户反复尝试。

其次，若流量仍大，可以考虑使⽤第⼆板斧， 缓⼀下。

1. 比如对库存扣减做预分配机制；

2. 增加异步排队机制，订单服务将请求放入队列异步处理，并告知用户“已进入排队中，XXX分钟后系统会在XX中通知”，缓解并发压力；

3. 在订单服务前增加预约逻辑和资格缓存，未获得资格的用户无法进入订单服务。

面试官：小伙子，有点东西呀，那对于你的第⼆板斧，如果在⼀次压测中，你发现系统的 QPS 突然在 10 万的时候卡住了，延迟飙升，CPU、内存等资源使⽤率却不⾼，数据库压⼒也正常。这种情况下你会如何排查瓶颈？具体会⽤哪些⼯具和⽅法？

我：嗯，这个问题很有意思，系统卡住但资源未用满，说明瓶颈可能在“隐藏角落”，如线程池、消息队列积压、锁竞争或网络连接问题。我的排查思路是从系统调用链和资源分配入手，逐层分析每个环节的运行情况，找到真正的瓶颈。

面试官：小伙子确实有两把刷子，最后一个难题要是你过了，我就让你过我这一关哈，前面你多次提到三板斧，最后一招”隔”能深入讲讲吗？

我：好的呀，关于这个隔，从系统的上到下分成三个层次来说就是：逻辑层、服务层和基础层。 

逻辑层：梳理业务逻辑，找出关键路径（如订单、支付）和支撑路径（如弹幕评论）。关键路径必须稳定，支撑路径出问题可通过降级或异步化解决，不影响核心链路。

服务层：重点是服务调用和资源隔离。通过线程池隔离（如库存、支付服务独立线程池），防止服务间相互影响；限流控制客户端请求量，防止异常流量拖累服务；高耗资源模块可独立进程运行，减少对主服务的影响。

基础层：隔离底层资源，划分独立资源池（如线程池、数据库连接池），按用户类型（VIP用户和普通用户）或业务模块分开使用，避免普通用户耗尽资源影响VIP用户；通过区域隔离，让不同地域或业务模块使用各自资源组，防止局部问题波及整体。核心是局部问题局部解决，保障系统整体运行。

这个场景面试题结束了，你有什么观点和看法？来评论区留言。

最后，我最近弄了一个架构群，讨论业务架构，基础架构，云原生，安全，支付，AI、区块链，全链路测试测试架构，技术管理等备领域知识，如果你感兴趣，加我微信备注架构，我拉你入群哈～

目前已经有近 500 多人加入。

如果你已经在群里，请忽略～

如果你发现加的人太多加不上的话，请加这个微信（jeff_cheng02）

综上，希望今天这篇文章对你帮助！

全文完，觉得我说的不错的话点个赞或者在看吧！

以往热文推荐：

我身边那些P9，CTO大佬之所以成为大佬的 6 个原因！

---

更多精彩，关注我公号，一起学习、成长