当前位置：首页 > news >正文

字节二面：10Wqps超高流量系统，如何设计？

news 2025/8/7 5:58:35

超高流量系统设计思路

前言

在40岁老架构师尼恩的**读者交流群(50+)**中，大流量、高并发的面试题是一个非常、非常高频的交流话题。最近，有小伙伴面试字节时，遇到一个面试题：

10Wqps超高流量系统，该如何设计？

这是一道很常见的面试题，但是大多数人并不知道怎么回答，这种问题其实可以有很多形式的提问方式，你一定见过而且感觉无从下手：

面对业务急剧增长你怎么处理？

业务量增长10倍、100倍怎么处理？

你们系统怎么支撑高并发的？

怎么设计一个高并发系统？

高并发系统都有什么特点？

… …

诸如此类，问法很多，但是面试这种类型的问题，看着很难无处下手，但是我们可以有一个常规的思路去回答，就是围绕支撑高并发的业务场景怎么设计系统才合理？

如果你能想到这一点，那接下来我们就可以围绕硬件和软件层面怎么支撑高并发这个话题去阐述了。

本质上，这个问题就是综合考验你对各个细节是否知道怎么处理，是否有经验处理过而已。

面对超高的并发，宏观的处理思路大致如下：

首先硬件层面机器要能扛得住，
其次架构设计做好微服务的拆分，
代码层面各种缓存、削峰、解耦等等问题要处理好，
数据库层面做好读写分离、分库分表，
稳定性方面要保证有监控，熔断限流降级该有的必须要有，发生问题能及时发现处理。

介绍了这个几个方面，这样从整个系统设计方面就会有一个比较全面的答案。至少不会因为这个题目，被挂。

这里尼恩给大家做一下系统化、体系化的梳理，使得大家可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”。

也一并把这个题目以及参考答案，收入咱们的《尼恩Java面试宝典》V49版本，供后面的小伙伴参考，提升大家的 3高架构、设计、开发水平。

注：本文以 PDF 持续更新，最新尼恩架构笔记、面试题的PDF文件，请从这里获取：码云

硬件的扩展+微服务的拆分

在互联网早期的时候，单体架构就足以支撑起日常的业务需求，大家的所有业务服务都在一个项目里，部署在一台物理机器上。

所有的业务包括你的交易系统、会员信息、库存、商品等等都夹杂在一起，当流量一旦起来之后，单体架构的问题就暴露出来了，机器挂了所有的业务全部无法使用了。

于是，集群架构的架构开始出现，单机无法抗住的压力，最简单的办法就是水平拓展横向扩容了，

这样，通过负载均衡把压力流量分摊到不同的机器上，暂时是解决了单点导致服务不可用的问题。

但是随着业务的发展，在一个项目里维护所有的业务场景使开发和代码维护变得越来越困难，

一个简单的需求改动都需要发布整个服务，代码的合并冲突也会变得越来越频繁，同时线上故障出现的可能性越大。微服务的架构模式就诞生了。

把每个独立的业务拆分开独立部署，开发和维护的成本降低，集群能承受的压力也提高了，再也不会出现一个小小的改动点需要牵一发而动全身了。

以上的点从高并发的角度而言，似乎都可以归类为通过服务拆分和集群物理机器的扩展提高了整体的系统抗压能力，那么，随之拆分而带来的问题也就是高并发系统需要解决的问题。

高性能 RPC

微服务化的拆分带来的好处和便利性是显而易见的，但是与此同时各个微服务之间的通信就需要考虑了。

传统HTTP的通信方式性能首先并不太好，大量的请求头之类无效的信息是对性能的浪费，这时候就需要引入诸如Dubbo类的RPC框架。

之前尼恩的社群中，有小伙伴进行对比测试，Dubbo RPC的性能，是Feign RPC的性能10倍。

尼恩最近也进行了对比验证， Dubbo RPC 的性能，确实是 Feign RPC 10倍。具体的实操过程和数据，请参见尼恩的全链路实操

我们假设原来来自客户端的QPS是9000的话，那么通过负载均衡策略分散到每台机器就是3000，而Feign HTTP RPC 改为 Dubbo RPC 之后，接口的耗时缩短了，单体服务和整体的QPS就提升了。

而RPC框架本身一般都自带负载均衡、熔断降级的机制，可以更好的维护整个系统的高可用性。

那么说完RPC，作为基本上国内普遍的选择Dubbo的一些基本原理就是接下来的问题。

这个时候，大家要做好Dubbo 面试题的回答准备。有关Dubbo的面试题，请参考《尼恩Java面试宝典》的 Dubbo 面试专题。

消息队列消峰解耦

对于MQ的作用大家都应该很了解了，主要功能：

削峰填谷、解耦。
同步转异步的方式，可以降低微服务之间的耦合。

对于一些不需要同步执行的接口，可以通过引入消息队列的方式异步执行以提高接口响应时间。在交易完成之后需要扣库存，然后可能需要给会员发放积分，本质上，发积分的动作应该属于履约服务，对实时性的要求也不高，我们只要保证最终一致性也就是能履约成功就行了。

对于这种同类性质的请求就可以走MQ异步，也就提高了系统抗压能力了。

这个时候，大家要做好RocketMq面试题的回答准备。

比如：对于消息队列而言，怎么在使用的时候保证消息的可靠性、不丢失？有关RocketMq的面试题，请参考《尼恩Java面试宝典》的消息队列面试专题。

三级缓存架构

缓存作为高性能的代表，在某些特殊业务可能承担90%以上的热点流量。

对于一些活动比如秒杀这种并发QPS可能几十万的场景，引入缓存事先预热可以大幅降低对数据库的压力，10万的QPS对于单机的数据库来说可能就挂了，但是对于如redis这样的缓存来说就完全不是问题。

以秒杀系统举例，活动预热商品信息可以提前缓存提供查询服务，库存数据可以提前缓存，下单流程可以完全走缓存扣减，秒杀结束后再异步写入数据库，数据库承担的压力就小的太多了。

这个时候，大家要做好缓存面试题的回答准备。

比如：引入缓存之后就还要考虑缓存击穿、雪崩、热点一系列的问题了。有关redis的面试题，请参考《尼恩Java面试宝典》的 redis面试专题。

如果避免缓存击穿和缓存雪崩，需要引入三级缓存架构，更进一步优秀的方案：是结合热点预热子系统+热点探测系统。具体请参见尼恩3高笔记《100Wqps三级缓存组件实操》

数据库分库分表

对于整个系统而言，最终所有的流量的查询和写入都落在数据库上，数据库是支撑系统高并发能力的核心。

怎么降低数据库的压力，提升数据库的性能是支撑高并发的基石。主要的方式就是通过读写分离和分库分表来解决这个问题。

对于整个系统而言，流量应该是一个漏斗的形式。比如我们的日活用户DAU有20万，实际可能每天来到提单页的用户只有3万QPS，最终转化到下单支付成功的QPS只有1万。

那么对于系统来说读是大于写的，这时候可以通过读写分离的方式来降低数据库的压力。

读写分离也就相当于数据库集群的方式降低了单节点的压力。而面对数据的急剧增长，原来的单库单表的存储方式已经无法支撑整个业务的发展，这时候就需要对数据库进行分库分表了。

针对微服务而言垂直的分库本身已经是做过的，剩下大部分都是分表的方案了。

这个时候，大家要做好分库分表的面试题的回答准备。请参考《尼恩Java面试宝典》的 mysql面试专题，光这个专题的最新版，就有300多页。够大家刷几个月了。

高可用

熔断

比如营销服务挂了或者接口大量超时的异常情况，不能影响下单的主链路，涉及到积分的扣减一些操作可以在事后做补救。

限流

对突发如大促秒杀类的高并发，如果一些接口不做限流处理，可能直接就把服务打挂了，针对每个接口的压测性能的评估做出合适的限流尤为重要。

降级

熔断之后实际上可以说就是降级的一种，以熔断的举例来说营销接口熔断之后降级方案就是短时间内不再调用营销的服务，等到营销恢复之后再调用。

预案

一般来说，就算是有统一配置中心，在业务的高峰期也是不允许做出任何的变更的，但是通过配置合理的预案可以在紧急的时候做一些修改。

核对

针对各种分布式系统产生的分布式事务一致性或者受到攻击导致的数据异常，非常需要核对平台来做最后的兜底的数据验证。比如下游支付系统和订单系统的金额做核对是否正确，如果收到中间人攻击落库的数据是否保证正确性。

总结

其实可以看到，怎么设计高并发系统这个问题本身他是不难的，无非是基于你知道的知识点，从物理硬件层面到软件的架构、代码层面的优化，使用什么中间件来不断提高系统的抗压能力。

但是这个问题本身会带来更多的问题，微服务本身的拆分带来了分布式事务的问题，http、RPC框架的使用带来了通信效率、路由、容错的问题，MQ的引入带来了消息丢失、积压、事务消息、顺序消息的问题，

缓存的引入又会带来一致性、雪崩、击穿的问题，

数据库的读写分离、分库分表又会带来主从同步延迟、分布式ID、事务一致性的问题，

而为了解决这些问题我们又要不断的加入各种措施熔断、限流、降级、离线核对、预案处理等等来防止和追溯这些问题。