浅谈高并发、高性能、高可用

浅谈高并发、高性能、高可用

摘要：大型网站的技术挑战主要来自于庞大的用户，高并发的访问和海量的数据，任何简单的业务一旦需要处理数以Р计的数据和面对数以亿计的用户，问题就会变得很棘手。大型网站架构主要就是解决这类问题。中国铁道部官方售票网站在春节运行期间大量用户访问导致网站瘫痪，京东图书促销，用户访问量过大导致用户无法购买图书等等一系列的问题。对平台化的架构演进以及系统设计提出了更多的挑战和更高的要求。随着用户的访问量增大，架构师在进行系统设计时需兼顾业务功能的实现以及同时保证系统的高并发、高可用。

   

 关键词：高并发、高性能、高可用、异步、分布式

 

引言：随着各互联网大厂业务需求的井喷式增长，业务架构早已不是个新词。企业业务的高速发展、业务体量的不断增长，业务场景的日益复杂化与差异化，以及不断持续变化的业务需求，都对平台化的架构演进以及系统设计提出了更多的挑战和更高的要求。架构师在进行系统设计时需兼顾业务功能的实现以及同时保证系统的高并发、高可用。

1.”三高”的引出与简介

1.1 ”三高”的引出

随着各互联网大厂业务需求的井喷式增长，业务架构早已不是个新词。企业业务的高速发展、业务体量的不断增长，业务场景的日益复杂化与差异化，以及不断持续变化的业务需求，诸如中国铁道部官方售票网站在春节运行期间大量用户访问导致网站瘫痪，京东图书促销，用户访问量过大导致用户无法购买图书等等一系列的问题。对平台化的架构演进以及系统设计提出了更多的挑战和更高的要求。随着用户的访问量增大，架构师在进行系统设计时需兼顾业务功能的实现以及同时保证系统的高并发、高可用

1.2.“三高”的简及其特点

1.2.1 高并发

高并发是现在互联网分布式框架设计必须要考虑的因素之一，它是可以保证系统能被同时并行处理很多请求，对于高并发来说，它的指标有：

响应时间：系统对进来的请求反应的时间，比如你打开一个页面需要1秒，那么这1秒就是响应时间。

吞吐量：吞吐量是指每秒能处理多少请求数量，好比你吃饭，每秒能吃下多少颗米饭。

秒查询率：秒查询率是指每秒响应请求数，和吞吐量差不多。

并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。

1.2.2高性能

什么是高性能呢？高性能是指程序处理速度非常快，所占内存少，cpu占用率低。高性能的指标经常和高并发的指标紧密相关，想要提高性能，那么就要提高系统发并发能力，两者互相捆绑在一起。应用性能优化的时候，对于计算密集型和IO密集型还是有很大差别，需要分开来考虑。还有可以增加服务器的数量，内存，IO等参数提升系统的并发能力和性能，但不要浪费资源，要考虑硬件的使用率最高才能发挥到极致。

那么怎么样提高性能呢？

①　避免因为IO阻塞让CPU闲置，导致CPU的浪费

②　避免多线程间增加锁来保证同步，导致并行系统串行化

③　免创建、销毁、维护太多进程、线程，导致操作系统浪费资源在调度上

1.2.3. 高可用

高可用通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。高可用注意如果使用单机，一旦挂机将导致服务不可用，可以使用集群来代替单机，一台服务器挂了，还有其他后备服务器能够顶上。或者使用分布式部署项。比如现在redis的高可用的集群方案有： Redis单副本，Redis多副本（主从），Redis Sentinel（哨兵），Redis Cluster，Redis自研。

2.“三高”的特点

前面介绍了为什么要引入高性能、高并发、高可用，以及他们各自的详细介绍，下面将会介绍到这三种大型软件项目构造要求的特点。总的来说我将其总结为九大特点。分别是分层、冗余、分隔、异步、分布式、安全、自动化、集群、缓存等。下面将会具体的介绍一下这些特点。

2.1分层

分层是企业应用系统中最常见的一种架构模式，将系统在横向维度上切分成几个部分，每个部分负责一部分相对简单并比较单一的职责，然后通过上层对下层的依赖和调度组成一个完整的系统。在网站的分层架构中，常见的为3层，即应用层、服务层、数据层。应用层具体负责业务和视图的展示;服务层为应用层提供服务支持;数据库提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等。

分层架构是逻辑上的，在物理部署上，三层架构可以部署在同一个物理机器上，但是随着网站业务的发展，必然需要对已经分层的模块分离部署，即三层结构分别部署在不同的服务器上，是网站拥有更多的计算资源以应对越来越多的用户访问。

所以虽然分层架构模式最初的目的是规划软件清晰的逻辑结构以便于开发维护，但在网站的发展过程中，分层结构对网站支持高并发向分布式方向的发展至关重要。

2.2、冗余

网站需要7×24小时连续运行，那么就得有相应的冗余机制，以防某台机器宕掉时无法访问，而冗余则可以通过部署至少两台服务器构成一个集群实现服务高可用。数据库除了定期备份还需要实现冷热备份。甚至可以在全球范围内部署灾备数据中心。

2.3分隔

如果说分层是将软件在横向方面进行切分，那么分隔就是在纵向方面对软件进行切分。网站越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分隔开来，包装成高内聚低耦合的模块单元，不仅有助于软件的开发维护也便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。

大型网站分隔的粒度可能会很小。比如在应用层，将不同业务进行分隔，例如将购物、论坛、搜索、广告分隔成不同的应用，有对立的团队负责，部署在不同的服务器上。

2.4异步

使用异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方法异步执行进行协作。具体实现则在单一服务器内部可用通过多线程共享内存对了的方式处理;在分布式系统中可用通过分布式消息队列来实现异步。异步架构的典型就是生产者消费者方式，两者不存在直接调用。

2.5分布式

对于大型网站，分层和分隔的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。分布式意味着可以使用更多的计算机完同样的工作，计算机越多，CPU、内存、存储资源就越多，能过处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。

在网站应用中，常用的分布式方案有一下几种.分布式应用和服务：将分层和分隔后的应用和服务模块分布式部署，可以改善网站性能和并发性、加快开发和发布速度、减少数据库连接资源消耗。

分布式静态资源：网站的静态资源如JS、CSS、Logo图片等资源对立分布式部署，并采用独立的域名，即人们常说的动静分离。静态资源分布式部署可以减轻应用服务器的负载压力;通过使用独立域名加快浏览器并发加载的速度。

分布式数据和存储：大型网站需要处理以P为单位的海量数据，单台计算机无法提供如此大的存储空间，这些数据库需要分布式存储。

分布式计算：目前网站普遍使用Hadoop和MapReduce分布式计算框架进行此类批处理计算，其特点是移动计算而不是移动数据，将计算程序分发到数据所在的位置以加速计算和分布式计算。

2.6安全

网站在安全架构方面有许多模式：通过密码和手机校验码进行身份认证;登录、交易需要对网络通信进行加密;为了防止机器人程序滥用资源，需要使用验证码进行识别;对常见的XSS攻击、SQL注入需要编码转换;垃圾信息需要过滤等。

2.7自动化

具体有自动化发布过程，自动化代码管理、自动化测试、自动化安全检测、自动化部署、自动化监控、自动化报警、自动化失效转移、自动化失效恢复等。

2.8集群

对于用户访问集中的模块需要将独立部署的服务器集群化，即多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务。

服务器集群能够为相同的服务提供更多的并发支持，因此当有更多的用户访问时，只需要向集群中加入新的机器即可;另外可以实现当其中的某台服务器发生故障时，可以通过负载均衡的失效转移机制将请求转移至集群中其他的服务器上，因此可以提高系统的可用性。

2.9缓存

缓存目的就是减轻服务器的计算，使数据直接返回给用户。在现在的软件设计中，缓存已经无处不在。具体实现有CDN、反向代理、本地缓存、分布式缓存等。

使用缓存有两个条件：访问数据热点不均衡，即某些频繁访问的数据需要放在缓存中;数据在某个时间段内有效，不过很快过期，否在会因为数据过期而脏读，影响数据的正确性。

3.三高实际设计方案简介

通过上面的介绍我们已经基本上了解高并发高可用高性能的一些具体的实践方案，那么高性能高并发以及高可用在实际的环境中是如何部署的的呢？我们在实际程序架构中有用到了哪些具体的手段呢？总体如下图所示，下面我们将详细绍每一种解决方案。

 

3.1高并发

 3.1.1负载均衡

正所谓双拳难敌四手，高并发撑场面的首选方案就是集群化部署，一台服务器承载的QPS有限，多台服务器叠加效果就不一样了。如何将流量转发到服务器集群，这里面就要用到负载均衡，比如：LVS 和 Nginx。

常用的负载算法有轮询法、随机法、源地址哈希法、加权轮询法、加权随机法、最小连接数法等业务实战：对于千万级流量的秒杀业务，一台LVS扛不住流量洪峰，通常需要 10 台左右，其上面用DDNS（Dynamic DNS）做域名解析负载均衡。搭配高性能网卡，单台LVS能够提供百万以上并发能力。

注意， LVS 负责网络四层协议转发，无法按 HTTP 协议中的请求路径做负载均衡，所以还需要 Nginx。

 

3.1.2池化技术

复用单个连接无法承载高并发，如果每次请求都新建连接、关闭连接，考虑到TCP的三次握手、四次挥手，有时间开销浪费。池化技术的核心是资源的“预分配”和“循环使用”，常用的池化技术有线程池、进程池、对象池、内存池、连接池、协程池。

连接池的几个重要参数：最小连接数、空闲连接数、最大连接数

Linux 内核中是以进程为单元来调度资源的，线程也是轻量级进程。所以说，进程、线程都是由内核来创建并调度。协程是由应用程序创建出来的任务执行单元，比如 Go 语言中的协程“goroutine”。协程本身是运行在线程上，由应用程序自己调度，它是比线程更轻量的执行单元。

 3.1.3流量漏斗

上面讲的是正向方式提升系统QPS，我们也可以逆向思维，做减法，拦截非法请求，将核心能力留给正常业务！

互联网高并发流量并不都是纯净的，也有很多恶意流量（比如黑客攻击、恶意爬虫、黄牛、秒杀器等），我们需要设计流量拦截器，将那些非法的、无资格的、优先级低的流量过滤掉，减轻系统的并发压力。

拦截器分层：

网关和 WAF（Web Application Firewall，Web 应用防火墙）

采用封禁攻击者来源 IP、拒绝带有非法参数的请求、按来源 IP 限流、按用户 ID 限流等方法

风控分析。借助大数据能力分析订单等历史业务数据，对同ip多个账号下单、或者下单后支付时间过快等行为有效识别，并给账号打标记，提供给业务团队使用。

下游的每个tomcat实例应用本地内存缓存化，将一些库存存储在本地一份，做前置校验。当然，为了尽量保持数据的一致性，有定时任务，从 Redis 中定时拉取最新的库存数据，并更新到本地内存缓存中。

3.2高性能

性能直接影响用户的感官体验，访问一个系统，如果超过5秒没有响应，绝大数用户会选择离开。

 

那么有哪些因素会影响系统的性能呢

①　用户网络环境

②　请求/响应的数据包大小

③　业务系统 CPU、内存、磁盘等性能

④　业务链路的长度

⑤　下游系统的性能

⑥　算法实现是否高效

当然，随着并发数的提升，系统压力增大，平均请求延迟也会增大。

  3.2.1高性能缓存

   对一些热点数据每次都从 DB 中读取，会给 DB 带来较大的压力，导致性能大幅下降。所以，我们需要用缓存来提升热点数据的访问性能，比如将活动信息数据在浏览器的缓存中保存一段时间。

缓存根据性能由高到低分为：寄存器、L1缓存、L2缓存、L3缓存、本地内存、分布式缓存

上层的寄存器、L1 缓存、L2 缓存是位于 CPU 核内的高速缓存，访问延迟通常在 10 纳秒以下。L3 缓存是位于 CPU 核外部但在芯片内部的共享高速缓存，访问延迟通常在十纳秒左右。高速缓存具有成本高、容量小的特点，容量最大的 L3 缓存通常也只有几十MB。

本地内存是计算机内的主存储器，相比 CPU 芯片内部的高速缓存，内存的成本要低很多，容量通常是 GB 级别，访问延迟通常在几十到几百纳秒。

内存和高速缓存都属于掉电易失的存储器，如果机器断电了，这类存储器中的数据就丢失了。

 3.2.2日志优化，避免IO瓶颈

当系统处理大量磁盘 IO 操作的时候，由于 CPU 和内存的速度远高于磁盘，可能导致 CPU 耗费太多时间等待磁盘返回处理的结果。对于这部分 CPU 在 IO 上的开销，我们称为 “iowait”。

 

在IO中断过程中，如果此时有其他任务线程可调度，系统会直接调度其他线程，这样 CPU 就相应显示为 Usr 或 Sys；但是如果此时系统较空闲，无其他任务可以调度，CPU 就会显示为 iowait（实际上与 idle 无本质区别）。

磁盘有个性能指标：IOPS，即每秒读写次数，性能较好的固态硬盘，IOPS 大概在 3 万左右。对于秒杀系统，如果单节点QPS在10万，每次请求产生3条日志，那么日志的写入QPS在 30W/s，磁盘根本扛不住。

Linux 有一种特殊的文件系统：tmpfs（临时文件系统），它是一种基于内存的文件系统，由操作系统管理。当我们写磁盘的时候实际是写到内存中，当日志文件达到我们的设置阈值，操作系统会将日志写到磁盘中，并将tmpfs中的日志文件删除。

3.3高可用

高可用指标是指用来衡量一个系统可用性有多高。MTBF（Mean Time Between Failure），系统可用时长。MTTR（Mean Time To Repair），系统从故障后到恢复正常所耗费的时间SLA（Service-Level Agreement），服务等级协议，用于评估服务可用性等级。计算公式是 MTBF/(MTBF+MTTR)。一般我们所说的可用性高于 99.99%，是指 SLA 高于 99.99%。

技术架构，高可用有哪些策略？

①多云架构、异地多活、异地备份

②主备切换，如redis缓存、mysql数据库，主备节点会实时数据同步、备份。如果主节点不可用，自动切换到备用节点

③微服务，无状态化架构，业务集群化部署，有心跳检测，能最短时间检测到不可用的服务。

④通过熔断、限流，解决流量过载问题，提供过载保护

⑤重视web安全，解决攻击和XSS问题

3.3.1主备切换，缩减故障时间

当系统出现故障时，首要任务不是立马查找原因，考虑到故障的复杂样，定位排查要花些时间，等问题修复好，SLA也降了好几个档。有没有更快的方式解决这个问题？那就是故障转移。

 

当发现故障节点的时候，不是尝试修复它，而是立即把它隔离，同时将流量转移到正常节点上。这样通过故障转移，不仅减少了 MTTR 提升了 SLA，还为修复故障节点赢得了足够的时间。

 

主备切换大致分为三步：

 

第一步故障自动侦测（Auto-detect），采用健康检查、心跳等技术手段自动侦测故障节点；

第二步自动转移（FailOver），当侦测到故障节点后，采用摘除流量、脱离集群等方式隔离故障节点，将流量转移到正常节点；

第三步自动恢复（FailBack），当故障节点恢复正常后，自动将其加入集群中，确保集群资源与故障前一致。

3.3.2熔断，提供过载保护

所谓过载保护，是指负载超过系统的承载能力时，系统会自动采取保护措施，确保自身不被压垮。

熔断就是在系统濒临崩溃的时候，立即中断服务，从而保障系统稳定避免崩溃。它类似于电器中的“保险丝”，当电流过大的时候，“保险丝”会先被烧掉，断开电流，以免电路过热烧毁电器引起火灾。

例子：熔断触发条件往往跟系统节点的承载能力和服务质量有关，比如 CPU 的使用率超过 90%，请求错误率超过 5%，请求延迟超过 500ms， 它们中的任意一个满足条件就会出现熔断。

3.2.3限流，提供过载保护

限流的原理跟熔断有点类似，都是通过判断某个条件来确定是否执行某个策略。但是又有所区别，熔断触发过载保护，该节点会暂停服务，直到恢复。限流，则是只处理自己能力范围之内的请求，超量的请求会被限流。

限流算法主要有：计数器限流、滑动窗口限流、令牌桶限流、漏桶限流。网上的资料很多，这里就不多赘述。

3.3.4、降级

 

比如电商大促，业务在峰值时刻，系统抵挡不住全部的流量时，系统的负载、CPU 的使用率都超过了预警水位，可以对一些非核心的功能进行降级，降低系统压力，比如把商品评价、成交记录等功能临时关掉。弃车保帅，保证 创建订单、支付 等核心功能的正常使用。

当然不同业务、不同公司处理方式也各不相同，需要结合实际场景，和业务方一块讨论，最后达成一个统一认可的降级方案。

 

 

结语：高并发确实是一个复杂且系统性的问题，由于篇幅有限，诸如分布式Trace、全链路压测、柔性事务都是要考虑的技术点。另外，如果业务场景不同，高并发的落地方案也会存在差异，但是总体的设计思路和可借鉴的方案基本类似。高并发设计同样要秉承架构设计的3个原则：简单、合适和演进。“过早的优化是万恶之源”，不能脱离业务的实际情况，更不要过度设计，合适的方案就是最完美的。

 

参考文献：

[1] :高并发系统拥有高并发、高性能、高可用，分布式、集群化，安全性等特性

https://cloud.tencent.com/developer/article/1881865

[2] :程序员们的三高：高并发、高性能、高可用

https://blog.csdn.net/weixin_45336946/article/details/118074013

[3] :什么是高并发、高性能、高可用？

https://www.xinnet.com/knowledge/2142345827.html

[4] :全面认识高并发：高性能、高可用、高扩展

https://blog.csdn.net/Rong_Toa/article/details/108834940

[5] :“软件系统三高问题”高并发、高性能、高可用系统设计经验

https://blog.csdn.net/citywu123/article/details/123208680

标签：缓存,浅谈,系统,业务,并发,高性能,CPU,分布式
来源： https://www.cnblogs.com/wfswf/p/16367016.html