高并发服务器的逻辑处理瓶颈，该如何解决？

我经历的几家公司里，或多或少用到了高并发技术，下面结合自己的经验，姑且说下。。。

首先，需要不得不提下并发的概念！

并发(量):指定时间段内，系统同时处理的请求数！所以高并发是指指定时间内，系统同时处理大量的连接(请求)！

衡量并发量通常有一些特定的指标:

①，TPS(QPS):每秒的处理事务数量或者请求数量。

②，响应时间:完成一个请求需要的平均时间！

从这两个指标可以看到，提高并发能力落在了下面几个问题上:

1，如何提高并发连接数？你业务写的再好，如果服务器只允许几千的最大连接数（比如tomcat），那么你的并发能力就只能被限制在几千，为什么最大连接数被限制呢？早期的网络连接模型使用的是一个连接对应一个线程，这样内存开销很大，支撑不了大量的连接！

可以根据需要选择selector或者epoll网络IO模型，通过使用一个线程轮询或者事件触发的方式，能支持几万甚至更多的连接数，使用基于netty框架开发的nginx是一个不错的选择！

2，怎么将那么多连接数进行业务处理？

nginx不具有应用服务器的功能，也就是说具体的业务处理还是需要应用服务器来处理，比如tomcat，jetty等，因为nginx具有反向代理和负载均衡功能，可以将接受到的大量连接通过均衡的方式（轮询，权重，hash）分配到不同的应用服务器中进行业务处理！

3，怎么提高应用服务器的处理水平？

应用服务器的瓶颈有两个:

①，自身逻辑处理:在代码中尽量少创建对象，少创建线程，避免阻塞IO，尽量少用多层循环，少加锁，防止死锁等等策略，提高代码性能！

应用服务器还可以采用前后端分离(node.js＋restful后端接口)让动态数据和静态数据松耦合，提升前端处理能力和后端的专一性！

②，数据库压力:一般来说，系统高并发压力主要是来自于数据库，可以根据业务需要，使用读写分离，双主互备，mycat，sharding-jdbc等实现分库分表(注意全局唯一ID，统计，连接查询等问题)等策略，提高数据库处理能力！

数据库还可以借助内存型缓存(redis等)，缓存一些定义表，枚举等相对静态的数据提供快速的查询，可以搭建高可用的缓存集群！

上面的服务系统就是一个web服务集群，由nginx负载均衡加上几台应用服务器，使用缓存，再加上数据库集群算是一个比较常见的高并发集群！

但是如果业务需要解耦，那么需要进行业务拆分，根据业务提供不同的服务分布在不同的服务器上，这样就可以使用微服务框架，将业务服务隔离开来，避免单一服务对别的服务的影响！

4，如何使用微服务呢？

1，框架选择:springcloud或者dubbo！

2，服务注册与发现中心:zookeeper或者eureka，

3，微服务其他:客户端的负载均衡使用feign，网关zuul，统一的配置中心，断路器hystrix！

当然，微服务之间需要进行通信，通信方式可以有以下几种:

①，上面说的服务注册与发现！

②，直接restful模型使用http调用！

③，使用诸如redis，kafka类的消息中间件！

上面就组成了一个使用微服务框架搭建的，服务之间使用消息中间件通信，单个服务又可以使用nginx组成服务集群，同时进行前后端分离，缓存集群，数据库分库分表等的一整套分布式服务系统！

当然，还有网络因素，可以使用CDN技术，将不同地点的请求分发到不同的服务集群上，避免网络对速度的影响！

上面零散的说到了很多高并发的点，更多的是这些技术的落地，和具体问题的解决！如果你有技术实现上的问题，可发出来大家一块解决，更多的技术分享，敬请关注。。