下载掌阅APP，畅读海量书库
立即打开
本章首先分析了高性能、高可用、高并发、并发与并行几个概念的含义，然后分别从单台机器和分布式两个角度分析高并发场景的相关应对策略，以便帮助读者对高并发系统的设计有一个初步的认识和理解。
随着移动互联网的兴起，人们对互联网应用的依赖性越来越重，从生活到工作的方方面面都需要通过互联网应用来完成，如购物通过淘宝、聊天通过微信、出行通过滴滴、吃饭通过美团等。对于互联网应用而言，需要能够支撑海量用户同时在线和高效、快速地处理用户的高并发请求流量，保证应用系统在高并发场景中依然能够保持高性能和高可用。
在进行高并发应用系统设计时，首先需要对系统的并发处理能力有个清晰的认识，即该系统能够支撑多少用户同时在线，以及在大量用户同时在线、发送大量请求时，系统是否能够快速响应用户的请求等。应用系统开发人员需要关注高并发系统的相关衡量指标，具体包括：请求的响应时间、系统的吞吐量、系统每秒完成的请求数（Query Per Second, QPS）和并发在线用户数量等。
不过单纯分析以上指标是没有意义的，需要进一步结合业务特点来确定当前系统相关指标的大小是否符合要求。因为不同系统的并发用户数量和并发请求数量是不一样的，如美团外卖系统、天猫“双十一”这些都是存在海量并发用户和高并发请求的业务场景，而企业内部OA（办公自动化）系统则是并发用户量和请求数都比较少的业务场景，所以不同的系统对于以上指标的要求是不一样的。
当确定好以上相关指标后，则需要进行系统设计与开发来达到这些指标。在实现层面，由于应用系统需要运行在服务器机器上，所以首先需要保证应用系统能够充分利用服务器的硬件资源来处理用户请求，如充分利用服务器的CPU（中央处理器）、内存等硬件资源。当并发用户量和请求量太大，导致超出了单台服务器的最大处理能力时，则需要使用多台服务器来处理请求，此时对于系统设计而言就需要进行分布式系统设计来应对高并发的在线用户和高并发请求。
在软件开发领域，特别是互联网应用，通常会根据对应的软件系统并发量的大小来衡量该系统能够支撑多少用户同时在线和对应用的正常使用。并发是指在同一个时间点，多个在线用户同时发送请求给应用系统，应用系统需要同时处理多个请求，并且需要在用户预期的时间内返回处理结果给用户。而应用系统在处理请求时，又分为并行处理和并发处理，这两个概念的含义后面会详细分析。
一个系统是否为高并发系统需要从高并发场景和应用系统的高并发处理能力两个方面来定义。首先，需要根据应用系统的业务特点和需要处理的并发请求的数量来判断该系统是否属于高并发场景，如数据库系统可能单机每秒几千并发量就已经属于高并发场景了，而对于Web应用而言则是比较低的并发量。
其次，对于高并发场景，应用系统自身是否具有高并发处理能力，即在高并发场景中，能否保证用户在预期的时间内正常获取请求的结果。如果一个应用系统既存在高并发场景，又具备高并发处理能力，则该系统属于高并发系统。
在现代互联网应用的设计当中，通常会提到应用系统需要达到高性能、高可用和高并发这“三高”目标，其中这三个概念既有联系又有区别。
高性能是指应用系统对用户请求的处理速度快、响应时间短，对于用户来说就是该应用的操作流畅，拥有良好的用户体验，所以高性能是应用系统需要具备的基本条件。不过不同业务的高性能的定义会有所差别，如在线网络游戏需要保证在毫秒级别的响应时间，否则会让用户感觉非常卡顿，而银行转账系统则可以是秒级别，如10秒内，用户也是可以接受的。
高可用是指在任何时候用户都可以正常使用应用系统，不能出现应用系统无法提供服务的情况。我们经常听到的需要保证系统的7×24可用或者需要有多少个9的可用性保证，如99.9%、99.99%、99.999%等，这些就是高可用方面的要求。高可用是关于应用系统稳定性方面的一个定义，不同系统对于可用性方面的要求也会不一样，如股票交易系统在交易时间段内不能出现任何不可用的情况，而企业内部OA系统则可以容忍某些时间点的不可用。
高性能和高可用是应用系统设计需要达到的目标，只有系统保证高性能和高可用才能让用户用得开心与放心，才能吸引更多的用户来使用该应用系统。在用户流量就是价值的今天，这两个方面的目标对企业发展具有重要意义。
不过实现高性能与高可用的难点是，在高并发场景中，应用系统如何才能做到使这两个指标持续得到保证。因为如果应用系统所需处理的并发请求流量不大时，应用系统所在机器拥有充足的硬件资源来快速处理每个请求，故不会出现系统过载导致机器宕机的问题，性能和可用性方面是很容易得到保证的。但是在高并发场景中，每秒会有成千上万，甚至更多的并发请求发送给应用系统，应用系统可能会无法同时快速处理所有请求而导致响应慢，甚至会导致机器资源耗尽而宕机，出现服务不可用的情况。
所以高并发是原因，高性能和高可用是结果。高并发编程的目的就是结合相关技术手段，如多线程设计、缓存加速、异步处理、基于分布式系统架构、集群部署等技术来实现在高并发场景中，应用系统依然可以正常处理每一个用户请求，使每个用户的请求都可以得到快速响应，从而获得良好的用户体验与系统稳定性。关于这些技术的相关原理与用法在本书后面章节会详细讲解。
在进行高并发系统设计时，通常会提到并行和并发两个概念，这也是我们容易混淆的两个概念。这两个概念反映了操作系统利用自身的CPU资源来处理运行于其上的应用系统的请求的两种不同方式，同时也影响着应用系统性能的高低。现代的操作系统通常是多核CPU架构，多个核心可以同时执行各自的任务，其中对每个请求的处理可以看作是一个任务，而在单个核心上的多个任务则需要轮流调度执行。
由于CPU的核心可以快速处理每个任务，所以即便是单个核心上的轮流执行，在应用系统看来还是同时执行的。所以对应到并发与并行两个概念的理解是：在CPU的多个核心同时执行的多个任务就是并行任务，而在同一个CPU核心中轮流调度执行的任务则是并发任务。
关于任务并发、并行与CPU的核心的关系如图1.1所示。任务1和任务2是在同一个核心排队轮流调度执行，属于并发任务；而任务1、任务3、任务4是在多个核并行执行，属于并行任务。
图1.1 并发、并行与CPU核心的关系
在应用系统的设计层面，主要是基于多线程设计来实现请求的并发或并行处理，充分利用服务器CPU的多个核心来处理用户的并发请求，从而达到加快请求处理速度的目的。从多线程与CPU核心的角度来理解并发和并行是，在处理用户的并发请求时，应用系统的多个处理线程是在CPU的单核还是多核执行，需要根据当前服务器的CPU的核心数量来决定。
如果服务器的硬件资源较好，CPU拥有多个核心，则多个处理线程可以在各个核同时执行，实现并行处理，此时应用性能是最好的。如果服务器的CPU只有单个核心或者CPU核心的数量少于应用系统的处理线程数量，则多个处理线程的全部或者部分就需要在某个CPU核心轮流调度执行，此时属于并发处理。
并发处理对应的请求处理速度一般会低于并行处理，但是相对于单进程单线程应用，性能方面还是有很大的提升。因为即使是并发处理，由于CPU处理速度很快，在应用系统看来，多个并发请求也是同时执行的。
高并发应用系统需要应对高并发场景，同时需要具备高并发处理能力。一个应用系统的高并发处理能力通常从该系统处理请求时的响应时间、系统的吞吐量、QPS以及支持的并发在线用户数这几个方面来衡量。
应用系统的响应时间反映的是一个请求从发起到获得处理结果所需的时间，如从用户在浏览器输入某个图片的地址到该图片完全显示出来的这段时间，称为此次请求的响应时间。响应时间越短，用户需要等待的时间越短，用户体验越好，给用户的感觉就是应用系统的性能越好。
不过在衡量一个高并发应用系统的响应时间时，不能根据某次请求的响应时间来衡量，而是需要根据该应用系统的业务特点，基于该应用系统在最大并发请求下的平均响应时间和最大响应时间来衡量。其中最大并发请求下的平均响应时间反映的是在极端情况下，用户平均需要等待多长时间才能收到请求的处理结果；最大响应时间则是反映用户最长需要等待多久才能收到请求的处理结果。
在系统上线之前，需要根据系统可能会出现的最大并发量进行压力测试，然后结合业务特点来判断对应的平均响应时间和最大响应时间是否可以被用户接受，从而确定是否需要进行相关的优化来进一步提高应用系统的性能。例如，在线网络游戏系统可能要保证毫秒级别的响应时间，否则会使玩家感觉很不流畅而没有兴趣继续玩下去；而对于银行转账系统则允许秒级别的响应时间，因为这种场景让用户等待几秒是可以接受的。
在进行高并发应用系统设计时，对于响应时间主要需要关注的是应用系统从应用服务器接收到该请求，然后进行相关处理的过程，如从数据库读取或者写入数据、通过RPC（Remote Procedure Call）调用其他服务获取数据等，最终返回结果给应用服务器的这个过程。如果该过程存在性能问题导致请求响应慢，则需要对该过程涉及的相关操作进行性能优化。
吞吐量是指系统在单位时间内完成请求的数量。QPS与吞吐量类似，不过吞吐量反映的是应用系统的整体处理能力，即系统在单位时间内平均完成请求的数量；而QPS则是单位时间精确到秒，反映的是系统的最大吞吐量。
除此之外，还有一个与QPS类似的概念TPS，即Transaction Per Second。TPS是指应用系统每秒完成的事务数。QPS与TPS的差别是，QPS通常是在接口层面来衡量某个接口每秒完成的请求数，而TPS则是在系统层面来衡量该系统每秒能够完成的事务数量。一个事务的完成通常会涉及对多个接口的请求调用，如银行转账系统的一次转账过程可以看作是一个事务，该事务涉及转出银行的金额扣减和转入银行的金额递增两个过程对应的接口调用。
以上几个概念都反映了应用系统在某个时间范围内可以正常完成的请求数量，而不是指接收到的请求数量。正常完成是指应用系统可以在预期的时间内，对这个请求处理完成和返回响应结果给用户。
另外吞吐量与响应时间的关系是，响应时间越短，吞吐量越大；响应时间越长，吞吐量越小。如果并发请求量的大小是在应用系统的处理能力之内，则随着并发请求量的增加，请求的响应时间不会有较大的变化，系统的吞吐量在增加。
所以在进行应用系统设计与压力测试时，需要重点关注随着并发请求量的增加，响应时间显著变长的临界点所对应的吞吐量大小，此值是该应用系统所能处理的并发请求量的峰值，即最大值，超过则会导致应用系统的整体性能显著下降。
应用系统的吞吐量指的是应用系统在单位时间内能够完成的并发请求数量。因为每个请求都是系统当前的在线用户发起的，所以应用系统可能会接收到的并发请求量跟并发用户数有直接关系，故并发用户数的大小也是衡量一个应用系统是否为高并发应用的一个重要指标。
应用系统的并发用户数是指应用系统最多支持多少用户同时在线，并且每个用户的请求都可以正常得到响应。例如，在商品的秒杀抢购、抢红包等场景中，会存在大量用户同时在线并发送大量并发请求的情况。
所以在进行系统设计时，需要根据业务特点来预估可能出现的并发用户数的最大值，然后在进行压力测试时，检测当并发用户的数量达到这个峰值时，每个用户的请求是否可以正常得到响应并且需要统计无法正常响应的用户请求的数量。之后可以根据这些测试数据来决定是否需要对系统进行进一步的优化来增加应用系统所能支持的并发用户的数量。
在服务器硬件资源层面，由于每个并发用户需要与应用系统建立一个TCP连接，每个TCP连接都会消耗操作系统的一个文件描述符，而操作系统所能提供的文件描述符的数量是有限的，所以当系统的并发用户太多，导致所建立的TCP连接的数量超出单台服务器的可用文件描述符数量时，则需要对应用系统进行集群拓展，通过在多个机器节点部署该应用系统的更多实例来加大应用系统可支持的并发用户数。