写在前面

面试的时候经常会被问到如何设计一个高并发系统，很多人都只能说出缓存、读写分离、异步等几个常见方法，今天就系统全面总结一下这个问题，希望能帮助到大家。

什么是高并发系统

简单说就是你的系统要能支持瞬间大量的请求。比如淘宝双11、过年抢红包等。那如何量化的定义一个系统是不是高并发呢？有一些名称需要了解一下。

名词解释

QPS

QPS 全称是 Query Per Second ，含义是每秒查询数，即服务每秒处理完成的请求数。

TPS

TPS 全称是 Transaction Per Second ，含义是每秒事务数，即服务每秒处理完成的事务数。

RT

RT 全称是 Response Time ，含义是响应时间，即服务处理一次请求的平均响应时间。

并发量

并发量指的是客户端同时发起的请求数。注意，这里并不是服务处理的请求数。

服务并发处理数

服务端同时处理的请求数。这里要注意和并发量作区分。

用户数

用户数可以分为并发用户数、注册用户数和在线用户数。

并发用户数在真实线上环境下，指的是同时发起请求的用户数。在压测环境下，指的是压测工具中的虚拟用户数（Virutal User）。注意，并发用户数是一定会对系统产生压力的用户数。

注册用户数一般指的是数据库中存在的用户数，对系统不产生压力。

在线用户数指的是当前使用系统的，“挂” 在系统上的用户数，一般不对系统造成压力。

吞吐量

吞吐量，指的是系统服务在网络上传输的数据总和。

吞吐量不能作为衡量系统能力的指标，因为随着时间的拉长，吞吐量自然就上去了。比如滴水一天可能比全量开 1 分钟水龙头的自来水的流量还多，而我们的感受肯定是全量开水龙头的水流量大。因此，衡量系统吞吐能力，一般用单位时间内的吞吐量来衡量。即吞吐率。

衡量吞吐能力的指标一般有 QPS 、 TPS 、字节数/秒 和 页面数/秒等。

用户思考时间

在真实场景中，用户要完成某个业务（如支付）需要多个步骤，而每个步骤用户都需要一定的思考时间，这里每步操作之间的停顿的时间，即用户思考时间。

TP99

TP 的全称是 Top Percentile，即 Top 百分位数，此指标衡量的是某百分位处的请求响应时间，主要用于衡量对响应时间敏感的服务。比如：

• TP90：按响应时间从小到大排列，位于 90% 处的响应时间；
• TP99：按响应时间从小到大排列，位于 99% 处的响应时间；
• TP999：按响应时间从小到大排列，位于 999% 处的响应时间。

TP 百分位数要求越高，则表示对性能要求越高。

PV

PV 的全称是 Page View，即页面访问量。

UV

UV 的全称是 Unique Visitor ，独立访客量，即去重后的访问用户数。

DAU

DAU 的全称是 Daily Active User，即日活跃用户数。

MAU

MAU 的全称是 Month Active User，即月活跃用户数。

名词概念之间的关系

了解了基本的名称概念后，还需要了解一些重要概念之间的关系，要知道有些指标概念之间是有一定的关系的，甚至是可以相互影响的。

下面介绍一些重要概念之间的关系。

QPS vs TPS

复杂场景下，用户要完成某个事务，可能需要访问多个或多次接口，此时：1TPS = nQPS。

对于简单场景，如完成一个事务，只需要访问一次一个接口，此时：1TPS = 1QPS。

并发用户数 vs 并发量

在多接口的复杂场景下，一个用户可能同时访问多个接口，此时对于系统来说，并发用户数 < 并发请求数。

在简单串行场景下，一个用户逐个访问单接口，此时对于系统来说，并发用户数 = 并发请求数。

并发量 vs 系统并发处理数

当并发量 > 系统并发处理能力时，并发量 > 系统并发处理数。

当并发量 <= 系统并发处理能力时，并发量 = 系统并发处理数。

TPS & RT & 系统并发处理数 & 用户思考时间

TPS = 系统并发处理数 / ( RT + 用户思考时间)。

系统并发处理数，是服务端同时处理的请求数。

RT 为系统平均响应时间，它的大小是网络传输时间总和、服务处理时间总和、数据库响应时间总和、缓存响应时间总和、磁盘IO时间总和以及其他时间的总和。

用户思考时间，对于单接口来说，是零；对于复杂接口（如完成支付事务）来说：用户思考时间 = 用户各操作步骤间隔时间。

TPS & RT & 并发数

系统 TPS 、RT 和并发数是相互影响的。其三者之间的影响关系，可以根据并发数的提升分为系统低负荷阶段、系统满负荷阶段和系统超负荷阶段。如下图所示。

在系统低负荷阶段（轻压力区），并发数很低，CPU 工作不饱和，随着并发数的增长， TPS 跟着增长， RT 几乎是平稳的。

随着并发数的增大，系统进入满负荷状态（重压力区），CPU 工作进入饱和状态，这时系统资源利用率达到最大值，TPS 达到最大值，RT 开始明显增长。

进一步增大并发数，系统就会进入超负荷状态（拐点区），这时系统开始处理大量请求，线程频繁切换，CPU load 超负荷，而此时真正处理的请求数反而会降低，最终导致 TPS 下降，RT指数级增长。

核心目标

要实现高并发系统，必须满足以下三个目标：

• 高性能

高性能，即系统的并行处理能力，其主要的衡量指标是 RT 和并发处理数。根据系统的 TPS 计算公式，TPS = 并发处理数 / RT ，要想提高系统的性能，一是要提高系统并发处理能力，二是要降低系统处理的 RT 。

显而易见，高性能是高并发系统最主要的目标之一。比如你的系统响应时间是 10S ，别人的系统响应时间是 0.1S ，那用户体验是截然不同的。再比如你的系统只能支持 100 人来抢购，别人的系统能支持 10000 人来抢购，很可能用户来一次就不想再来了。

• 高可用

高可用，即系统的稳定性。简单来讲，当秒杀活动的用户流量来临时，你的系统能不能稳定的处理这些流量，别流量一来，你的系统就崩掉了。

显而易见，系统的可用性也是高并发系统的最主要的目标之一。比如秒杀活动期间，流量一来，你的系统崩掉了，这时想必用户要崩溃了，不仅买不到自己想要的商品，也会影响平台口碑：招商招不来，用户不来买等等。

可用性的衡量指标一般用可用率来表示，可用率 = 正常运行时间 / 总运行时间。

业内一般用几个 9 来表示系统的可用性，比如可用性是 4 个 9 ，则表示可用率 = 99.99% ，总运行时间按一年时间来算的化，每年的不可用时间要小于 51.264m（356 * 24 * 60 * (1-99.99%)）

• 高伸缩性

高伸缩性，指的是系统能不能通过增减硬件配置，来扩容和缩容集群吞吐能力。

在实际线上场景中，平时流量一般不会特别大，而秒杀活动期间的流量可能是平时流量的数十倍，甚至是上百倍。从成本上考虑，假如一直用秒杀活动的硬件配置，显然太过浪费了。最好的效果是可以在平时用少量的硬件配置，在活动期间增加到大流量的配置。以此来充分有效的节约机器成本。

衡量高伸缩性的方式，就是要看系统的吞吐能力是不是能随着机器的扩容而增强，随着机器的缩容而降低。比如增加一倍的机器，能不能增加一倍的吞吐能力。

如何设计高并发系统

系统拆分

就是把单体系统拆分成多个微服务，一个微服务挂了不会影响其他微服务，通过兼容、容错等方法忽略当前微服务宕机带来的影响。

集群部署

一个服务部署多个实例，通过负载均衡、服务发现做调度

缓存

一般用redis缓存、内存缓存，将那些经常需要查询并且变动较小的缓存起来，可以做长时间缓存，也可以做短暂的缓存，当前请求有效。

CDN

加速静态资源访问

异步排队

使用消息队列，将请求或者耗时的操作放到消息队列中慢慢处理，实现削峰填谷。

分库分表

按照某个业务关键字分库分表，比如按租户分库，按月份分表等

池子化技术

很多耗时耗资源的第三方链接可以通过连接池实现服用。比如http连接、rpc连接、db连接、redis连接、线程等，通过池化技术先初始化好连接，待到要使用的时候直接用，用完放回去，下次接着用。

读写分离

一般是主从分离，一主多从，写主读从。

ES

Elasticsearch 分布式、高扩展、高实时的搜索与数据分析引擎，简称为ES。一般耗时的查询、统计、全文搜索可以用ES

熔断

当访问量突增或者某个机房遇到突发情况时，需要做一些降级措施，防止影响其他服务。比如通过开关，关闭某些请求或者服务，切换流量

限流

可以在接口上增加一些限流器来限制访问频率。

总结

参考

[1]架构系列：高并发架构的CDN知识介绍 [2]如何设计一个高并发系统？ [3]高并发系统，你真理解了吗？ [4]高并发系统设计 40 问 [5]高并发系统是如何设计的？ [6]字节三面：如何设计一个高并发系统