高并发架构设计

互联网服务相比传统软件的最大的挑战是它需要应对来自网络的无限流量。因此在对互联网应用做架构设计时，高并发是必须考虑的因素。那什么是高并发呢？百度百科的描述如下：

高并发（High Concurrency）通常是指通过设计保证系统能够同时并行处理很多请求。通俗来讲，高并发是指在同一个时间点，有很多用户同时的访问同一 API 接口或者 Url 地址。它经常会发生在有大活跃用户量，用户高聚集的业务场景中。

百度百科

这个描述过于简单，虽然说明了高并发的主要特征，但是对架构设计没有指导意义。同时并行处理很多请求，对于现代计算机来说太容易了，用多线程就能实现，还有必要上升到架构的高度吗？所以有必要深入理解一下高并发核心技术挑战究竟是什么？

边界

传统软件也要解决并发问题，但之所以不提高并发，一方面，相比互联网应用，确实并发量小很多，但最主要的是它的并发量是有清晰且稳定的边界。嵌入式应用受硬件限制，桌面应用面向个人，企业应用上限是组织人数。这些应用的边界清晰可见，并在很长时间内保持不变。

但是互联网应用呢？很难找到一条确定的边界。也许你会说，可以把全球总人口数划为边界啊？可以，但是这条边界没有意义。之所以要划边界，是因为所有的工程问题都是在有限资源条件下做的最优化设计。以全球人口为边界，做出的工程方案成本太高，一般企业无法承受，而且完全没有必要，因为至今为止都没有一个互联网应用能覆盖全球人口。那互联网应用就真的划不出合理的边界了吗？当然不是，只不过需要加上一个条件：时间。

互联网应用的用户规模是不确定的，但在一段时间内是相对稳定的。加上时间维度，这条边界就可以确定了，比如上线3个月内10万用户，半年100万用户。互联网应用在不同业务场景，不同发展阶段，这条边界都是不同的。高并发的架构设计必须具备弹性，支撑应用在互联网生态环境中不断进化。

 

计算

边界只是一个形象的比喻，在工程实现时，我们需要可量化的指标来做技术决策。对于并发量，业内通常用 QPS 这个指标来定义。

QPS（Queries Per Second）是指服务每秒处理的查询请求次数。通常根据一天的服务访问量（PV，Page Views）来计算QPS。考虑到一天内用户的访问并非均匀分布，而是会集中在某几个时间段内，所以 QPS 只需要针对峰值时段计算即可。从统计学上看，大致符合二八原则：一天 80% 的访问集中在 20% 的时间里。由此得到如下QPS的计算公式：

公式中86400是一天的总秒数。用此公式，代以不同量级的PV可以得到如下QPS的数量级表。

也许你会觉得这样算出的数据真的很准确吗，难道所有应用的访问都符合二八原则吗？没关系，参数可以调，数据也不用非常精准。关键是它能帮我们估算出QPS的量级，进而作出技术决策。下面做几道小学应用题体验一下。

 

问：每天300万PV的服务部署在单机上，这台机器的QPS需要达到多少？

答：需要达到 (300万 * 80%) / (86400 * 20%) = 139 QPS

 

问：如果单台机器的QPS是50，需要几台机器部署？ 

答：需要 ⌈139 / 50⌉ = 3台机器部署

 

问：经测试服务单次请求需要100ms，要达到50QPS，至少要开多少个线程来处理请求？ 

答：至少要开 50 * 0.1 = 5个线程。

 

高并发架构，多高才算高？面对这种模糊无边界的技术目标，是无法做出工程设计的。只有确定好边界，才能对更细节的技术指标做量化计算，从而让整个技术决策变得清晰明确。否则，要么设计不足，服务扛不住并发量；要么过度设计，存在大量的资源浪费。

QPS 是表示读数据的请求，对于写数据的请求用 TPS 这个指标。TPS 是Transactions Per Second 的缩写，表示每秒处理的事务数。TPS 的计算用每天数据的增长量来计算，计算方式与QPS 类似。

 

经验

高并发架构是一个系统性工程问题，除了跟服务本身性能有关外，还与服务所处的网络环境有密切关系，比如网络带宽、机房部署、机器配置等。对架构师的技术宽度要求比较高。下表是网上流传的对网站并发量级的分类表。不同级别的技术瓶颈不同，做架构设计时可以参考一下。 

 

架构

从终端（PC、手机以及其他智能设备）到互联网服务后端虽然速度快，但需要经历的网络节点是不少的（如下图所示）。其中每个环节都会影响服务的体验，这就是为什么说高并发架构是一个系统工程，而不只是单点设计。在进行架构设计时需要综合考虑。

大部分做业务开发的架构师只需要考虑业务逻辑层、缓存层和存储层的架构设计。但需要对完整的网络链路有清晰的认识，在极端情况下可以帮你快速定位问题。业务逻辑层是核心要考虑的，主要的开发都集中这一层。目前主流采用微服务架构方案，根据实际业务场景也可以选择SOA架构甚至单体架构方案。业务层尽量不存储数据，以CPU计算为主，以便支持快速弹性伸缩。缓存层和存储层现在都有成熟的开源中间件可供选择，非特殊场景，不要自主研发。在部署方式上，这两层对数据空间要求比较高，建议用物理机部署。

整个网络各环节面对的高并发量数量级并不是一样的。上层环节尽可能过滤非法和攻击请求，降低后续环节的并发量。特别是业务逻辑层，有些过滤条件跟业务属性有关，比如用户角色。并且，业务逻辑层需要对后续环节的并发量做有效控制，比如限流、熔断、流量削峰等。缓存层主要提高读数据并发量，但需要注意缓存击穿对存储层造成的并发压力，业务层需要有应对方案。存储层按写数据并发量进行架构决策，由于持久化数据量大且扩容比较满，所以对存储层的边界计算，至少以6个月时间来估算。

下表是各个环节数据处理速度的量级，可以帮助大家对整个网络链路环节的速度有一个数量级概念。避免设计上出现明显的链路短板或资源浪费。

总结

互联网应用一旦上线，就需要面对可能来自网络的海量请求。高并发是架构设计必须考虑的因素。但是多高的并发量算高呢？面对模糊不清的目标工程上无法做出最优设计。因此高并发架构首先需要明确边界，量化目标。

另外，互联网应用从发起请求到收到相应要经历网络的层层节点，每个环节都会影响并发性能。因此高并发架构并不是单点设计问题，而是一个系统性设计问题。架构师需要了解整个网络链路，并对各环节的处理速度有量级概念，避免设计上出现明显的链路短板或资源浪费。

 

延伸阅读

• 高可用架构设计