高并发是什么(高并发是什么和如何解决)

 2021-11-17 17:21    77  

如果你是一个工作刚不久的巨婴高并发是什么,那么首先,不要急于学习大型网站的架构设计,此时此刻做任何项目都可以学到很多东西,并发量不高的项目你可以多学习学习代码设计,要是工作不那么忙你还可以在公司学习母親別無選擇。任何产品不可能一开始的时候就是高并发架构。但是我们要时刻准备好迎接大流量。如果你确实希望能够直接接触高并发项目,那也不是不可以。我给你一个实际操作的思路。首先你需要了解jmeter工具,高并发的项目通常会用它来进行并发测试。并发我们通常会分为两种,一种是读并发,一种是写并发。

模拟读并发第一阶段:正常情况下,我们编写一个接口都是直接访问数据库获取数据,那这样肯定是占用数据库连接的,所以并发数不会很高。第二阶段:我们为数据添加缓存,访问时我们先访问缓存,比如redis,如果缓存中没有数据我们再从数据库中读取,这里就会涉及到缓存雪崩和穿透的问题。这些问题咱们可以忽略不计,因为解决办法很简单,而且有很多种。添加缓存就减少了数据库压力,更重要的是我们增加了请求的IOPS(吞吐量),也就意味着我们的服务器一秒钟可以处理更多的请求,也就提高了并发量。第三阶段:当我们的缓存处理的IOPS比我们的服务器最高支持的并发数还高,比如Tomcat优化的好的话可以有1.5k左右(有人说可以达到6k),不过我觉得这个跟你机器的内存和tomcat的配置有关,咱们暂且假定是1.5k。如果你要超过1.5k的并发,那么此时你就需要增加服务器或者换一种并发量更高的服务器。我们以增加服务器为例,你可以添加1台服务器来支持更高的并发,然后通过nginx进行负载均衡,将流量分配到两台tomcat中。我们知道nginx的最高并发可以达到3W,也就是意味着你可以添加20台tomcat。第四阶段:当nginx成为了我们的并发瓶颈,我们就要做nginx集群了。这也意味着我们需要将一个地区划分成多个小地区,每个地区配置一个公网nginx。而这种做法有两种,一种是通过网络路由层增加控制来实现分发,一种是通过硬件来实现,硬件的我没操作过,自己实践也不实际,因为很贵高并发是什么!当然,我们并不能直接通过增加最高并发量就能处理并发,比如数据库层面中途我们就需要改成主从机制,采用分库分表或者使用mongodb这种高吞吐量的数据库来做。比如我们的机器配置也需要增加等。

模拟写并发写并发跟读并发的区别主要在于写的时间往往比较长高并发是什么,读的时间我们通过缓存来提高,但写库这个动作我们并不能通过缓存来处理,此时就需要我们增加消息队列MQ,最终走向MQ的集群。增加MQ以后我们的请求只是把写库这项任务添加到队列中,然后一条一条地执行,但是用户发起的请求我们立即返回成功标志。这样可以不占用服务线程。也就提高了并发量,同时也需要修改我们的业务,比如正常下单是订单入库后返回成功,并发量上来后我们就需要调整为订单加入队列后成功,并没有入库,那么此时不能告诉用户下单成功,而是提醒用户正在下单,然后前端每1秒钟去查询订单看是否存在,如果存在再提示下单成功。

最后总的来说,我们知道了一套高并发的常见处理方式和原理,我们就可以自己去模拟一下。讲真的在公司基本学不到啥东西,一般都是靠自己做项目来完成一些自己想要的效果或者自己想实践的技术和经验。我自己就开发了一个代码开发平台,你也可以了解一下,叫懒猴子CG。前端用的nuxt,后端用的springboot,基本都不怎么架构,但是从前端到后端基本都是我一个人开发的,所以还是会学到很多东西。即使流量大了,我也有办法撑起来,这就是自己做项目去实践的一个好处,可以经历一下从无到有的整个过程。

祝你顺利!

什么是系统架构的高可用?需要从哪些方面去提高系统的高可用?

高可用性(HA),顾名思义,就是尽可能地减少系统不能提供服务的时间;如果一个系统能够一直保持工作状态,可以对外提供服务,那么我们就说系统的可用性是100%;大部分公司不会把话说这么满,所以经常会提出三个9、四个9的目标,也就是全年系统可用性为99.9%、99.99%。

高并发是什么(高并发是什么和如何解决)

那么如何保证系统的高可用呢?我认为核心的思想就是【防止单点,增加冗余】,先让我们看看传统的架构是什么样的,哪里会有风险。

高并发是什么(高并发是什么和如何解决)

高并发是什么(高并发是什么和如何解决)

高并发是什么(高并发是什么和如何解决)

可以看到,架构的每一个部分都是单点的话,简直是风险重重,任何一个环节出现了问题,可能会造成整个系统垮掉(缓存部分可能不会直接影响系统,但往往缓存失去效果之后,会拖垮数据库),解决方法也很容易,其实就是把系统的每个部分都增加冗余:

客户端到Web应用:要增加Web应用,首先要增加反向代理层,也就是负载均衡,比如Nginx;不过如果只部署一个Nginx的话,它又是一个单点了,通常我们会部署多台,一台提供服务,另外的相当于“备胎”,通过keepalived的方式监控工作中的Nginx是否存活,当主服务器发生故障无法对外提供服务时,动态将virtual IP(虚IP)切换到备用机,继续提供服务。

负载均衡到Web应用:搭建多个Web应用,在负载均衡如Nginx中配置多个Web端的地址,并且可以监控多个Web端的存活性,当监控到某台应用挂掉,那么Nginx不在将请求分发到这台机器上。

Web应用到服务层:这里有很多种实现方式,比如服务层前端也挂负载均衡,或者走客户端内的负载均衡(这里Web应用就是客户端,相当于配置多个服务层的地址,每次请求按照一定规则,选取连接来访问下游服务,并使用service-connection-pool监控服务层应用的存活性);也可以使用服务注册发现的方式(可提供服务的应用才会出现在注册中心)。

服务层到缓存:缓存的存在,本身就是一种冗余;缓存层也可以通过集群来解决缓存层的高可用问题。以Redis为例,支持主从同步,而且有sentinel哨兵机制,来做Redis的存活性检测。

服务层到数据库:数据库一般会采用主从架构;数据库【读】的高可用,通常使用db-connection-pool来保证自动故障转移;而【写】操作,通常需要keepalived+virtual IP(虚IP)自动切换。

以上都是保证系统高可用的方案,尽量做到客户端所有的请求都可以响应,但是系统资源不可能无限投入,所以需要一些方案保证系统的高可用,不过需要【牺牲】部分用户:

限流:我们接口只能支持200的并发,我们的页面只能支持一万人同时访问,那么多余的部分,对不起,我需要限制你们进入;常见的限流算法有:漏桶、令牌桶;

降级:牺牲非核心的业务功能,保证核心功能的稳定运行;

熔断:当服务链路中(A调B,B调C,C调D),某个服务响应时间过长或失败,会进行服务的降级,进而熔断该节点服务的调用,快速返回错误信息;不过嘛,我从来没有见过谁敢用熔断...

灰度发布:将部分流量导到新上线的应用上,来验证新的功能修改,如果上线后有BUG,也可以快速回滚,尽可能降低发布的风险。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解,希望能得到你的关注。

本文标签:架构系统可用

原文链接:https://www.xgfox.com/dmfx/34237.html

本文版权:如无特别标注,本站文章均为原创。