指标+数据告诉你高并发的瓶颈

单机并发连接数

并发连接数英文缩写是SBC。

nginx在内核优化后可同时容纳10万并发连接数。注意这里面提到了内核优化后，因为nginx处理任务占用资源极少，它的性能瓶颈主要在linux的文件句柄限制。

Tomcat 默认配置的最大请求并发数为150。可以改大，但是有一定限制。瓶颈在于操作系统中对于进程中的线程数有限制：Windows 每个进程中的线程数不允许超过 2000，Linux 每个进程中的线程数不允许超过 1000。在 Java 中每开启一个线程需要耗用 1MB 的 JVM 内存空间用于作为线程栈之用。

Jetty的并发量一般来说要优于Tomcat。但是只是在BIO、NIO上处理的区别。资源占用上区别不大，所以Jetty较Tomcat的性能有提升，但提升并不是量级上的。目前流行的组合是SpringBoot里将默认的Tomcat替换成Jetty做容器。

每秒处理事务数

从用户角度来看，其实用户并不关心后端服务器是否真正同时处理多少并发。用户关心的是我等多久能得到自己关心的结果，即响应时间(RT)。一般小key小value的缓存，请求响应时间平均在几百纳秒。一次数据库访问在两三毫秒。简单数据库访问的用户请求算上网络延时是十几毫秒。一般复杂度逻辑计算一般响应时长在几十到几百毫秒。

而开发人员关心的是怎么在一个时间段内处理更多的请求。如果非要给这段时间加一个期限，那就是1s。从用户角度一个事务可分为用户请求服务器、服务器处理请求、最后返回用户。每秒能处理用户事务的数量就是TPS。

并发连接数是有限的，但是TPS的角度，可以通过队列技术，复用已有连接来处理请求。这时候想要在达到SBC极限时优化，就要化简请求，让单个请求响应时间更短。这个主要取决于事务复杂度。

集群QPS

后来人们发现，查询速度是更重要的一个指标。因为一个网站99%的请求都是查询操作。如果真正需要插入和更新操作，比如支付、注册会员，几秒的时间能忍。如果实在耗时很长，可以分为两阶段提交。一个阶段查询确认是否可以提交成功，返回用户结果。耗时长的真正执行阶段的结果可用户稍后调用查询结果链接查看。

每秒处理查询请求的次数是QPS。由于用户根本不关心单机可处理的QPS是多少，可以将单机只能处理几百个并发请求的Tomcat或者Jetty这样的Web服务器连成一个集群，前面用nginx之类的做负载均衡。这就可以承受很大的并发量了。前提是Web服务器只有内存计算。

像刚刚说的Web服务器，业务通常会把它设计为无状态的。就是用户一个请求打到哪台机器都可以。但是如果用户需要一些获取自己独特的数据，比如自己的名字、生日。这些数据要存储在固定的地方比如数据库。这就是不是访问哪台机器都可以了。必须访问含有自己状态的地方。这些就是有状态服务。

在机器资源充足的情况下，有状态的服务通常才是瓶颈的根源。比如mysql。mysql5.7单机TPS可达到5千TPS。

服务拆分

当mysql这样的有状态服务达到性能瓶颈。聪明的软件工程师想到了从另外的维度来解决问题。读写分离，写请求为了数据一致性完整性不好分开。但是可以拷贝几个副本专门来承接读流量。如上文所说，一个网站99%的请求都是查询操作。专门用来读的数据库因为避免了排他锁，几万QPS是没有问题的。

那写请求想解决瓶颈怎么处理好呢？就可以把数据按照一定规则拆分到不同服务器上。这就是数据分片。比较常见的是Elasticsearch的数据分片。mysql的分片一般是软件工程师自己来设计开发。这就是常说的分库分表。

水平拆分的主要瓶颈是预算，就是说资源不是无限的。那需要定期做容量评估，把机器数维持在一个合理的范围。

除了上面提到的从单机到集群这种流量的水平切分、分库分表水平切分。聪明的软件工程师还想到了从业务上做拆分。让每个子系统的职责更单一，数据库拆出子表，这就是垂直拆分。

垂直拆分的瓶颈除了资源之外，还在人员。人就那么多，拆分太多，每个人负责太多的模块，精力会分散。如果一个需求，需要一个开发人员修改多个子模块。他就需要更多的发布上线。

总结

本文从并发连接数的概念引入，由于并发连接数存在硬件上的瓶颈。所以引入QPS、TPS等用户视角概念，从指标中提炼出通过减少响应时间提高并发的方法。我们通常使用缓存等用空间换时间的方法，主要目的就是减少响应时长。

当单机不能解决问题，就产生了多机来分担流量的方法，常见的有水平拆分（x轴拆分）和垂直拆分（y轴拆分）。实际上在数据库层还有z轴拆分。瓶颈也从物理资源逐渐转移到人力资源上。随着行业发展，如大家所相信的一样，人才的作用也会更加重要。