高并发服务器逻辑处理瓶颈,如何解决?首先我们先了解什么是并发!
并发,在操作系统中,是指一个时间段中有几个程序都处于已启动运行到运行完毕之间,且这几个程序都是在同一个处理机上运行,但任一个时刻点上只有一个程序在处理机上运行。———来源《百科》
顾名思义,高并发就是在指定时间内,系统同时能够处理大量的请求(连接数)。
那么如何衡量高并发呢?
高并发衡量指标
根据上面衡量指标可以看到,提高并发能力必须解决如下几个问题:
别着急,这么多问题我们一个一个来分析解决!
如下图所示,常规的单一网络连接模型只能1个连接对应1个线程,压力都集中在内存,导致内存开销非常大,肯定支撑的连接数有限!(直接挂掉)
单一网络连接模型
有道是业务写的再好不如一台高性能服务器,这个锅不一定要开发人员背的哦!!!服务器的连接入口就那么大(比如Tomcat只有几千的连接数),那么处理的能力也只局限于几千。
怎么解决呢?选用合适的网络IO模型或者selector,通过使用一个线程轮询或者事件触发的方式,能支持几万甚至更多的连接数,再配合上Nginx做负载就更完美了。
大家都知道nginx只是具有反向代理和负载均衡的功能,并不能处理具体的业务逻辑,不能担当应用服务器来使用。例如webSphere 、tomcat和jetty等,但是我们可以利用nginx将接受到的大量连接通过均衡的方式(轮询,权重,hash)分配到不同的应用服务器中进行业务处理!
nginx负载
要提高应用服务器的处理水平就要了解自己的应用服务器的瓶颈在哪里,一般有两个:
数据库本身:建立有效索引、读写分离、双主互备、分库分表(sharding-jdbc等实现)等策略,提高数据库处理能力,减少压力!
结合内存数据库:例如redid、memcached等,根据业务需要缓存一些数据字典、枚举变量和频繁使用数据等减少数据库访问次数,提升数据库处理能力。
web集群架构图
如上图web集群架构图所示:
组成了经典的web高并发集群架构。
先看一下非常火的这张微服务架构图:
微服务架构图
主要包含11大核心组件,分别是:
核心支撑组件
数据总线Kafka
出来上述几点解决高并发服务器逻辑处理瓶颈外,还要考虑网络因素,例如采用CDN加速,将不同地点的请求分发到不同的服务集群上,避免网络对速度的影响!
总之,根据自身实际业务在合理范围内尽可能的拆分,拆分以后同类服务可以通过水平扩展达到整体的高性能高并发,同时将越脆弱的资源放置在链路的越末端,访问的时候尽量将访问链接缩短,降低每次访问的资源消耗。服务之间直接restful模型使用http调用,或者redis,kafka类的消息中间件通信。单个服务直接使用nginx做负载集群,同时前后端分离,数据库分库分表等一整套分布式服务系统!
前后端分离