阿里P8面试官：如何设计一个扛住千万级并发的架构？( 二 ) _架构

计算方法上面说的这些指标，怎么计算呢？举个例子。
假设在10点到11点这一个小时内，有200W个用户访问我们的系统，假设平均每个用户请求的耗时是3秒，那么计算的结果如下：

QPS=2000000/60*60 = 556 （表示每秒钟会有556个请求发送到服务端）
RT=3s（每个请求的平均响应时间是3秒）
并发数=556*3=1668

从这个计算过程中发现，随着RT的值越大，那么并发数就越多，而并发数代表着服务器端同时处理的连接请求数量，也就意味服务端占用的连接数越多，这些链接会消耗内存资源以及CPU资源等。所以RT值越大系统资源占用越大，同时也意味着服务端的请求处理耗时较长。
但实际情况是，RT值越小越好，比如在游戏中，至少做到100ms左右的响应才能达到最好的体验，对于电商系统来说，3s左右的时间是能接受的，那么如何缩短RT的值呢？
按照2/8法则来推算1000w用户的访问量继续回到最开始的问题，假设没有历史数据供我们参考，我们可以使用2/8法则来进行预估。

1000W用户，每天来访问这个网站的用户占到20%，也就是每天有200W用户来访问。
假设平均每个用户过来点击50次，那么总共的PV=1亿。
一天是24小时，根据2/8法则，每天大部分用户活跃的时间点集中在(24*0.2) 约等于5个小时以内，而大部分用户指的是（1亿点击 * 80%）约等于8000W（PV），意味着在5个小时以内，大概会有8000W点击进来，也就是每秒大约有4500(8000W/5小时)个请求。
4500只是一个平均数字。在这5个小时中，不可能请求是非常平均的，有可能会存在大量的用户集中访问（比如像淘宝这样的网站，日访问峰值的时间点集中在下午14：00、以及晚上21：00，其中21：00是一天中活跃的峰值），一般情况下访问峰值是平均访问请求的3倍到4倍左右（这个是经验值），我们按照4倍来计算。那么在这5个小时内有可能会出现每秒18000个请求的情况。也就是说，问题由原本的支撑1000W用户，变成了一个具体的问题，就是服务器端需要能够支撑每秒18000个请求（QPS=18000）

文章插图

文章插图

服务器压力预估大概预估出了后端服务器需要支撑的最高并发的峰值之后，就需要从整个系统架构层面进行压力预估，然后配置合理的服务器数量和架构。既然是这样，那么首先需要知道一台服务器能够扛做多少的并发，那这个问题怎么去分析呢？我们的应用是部署在Tomcat上，所以需要从Tomcat本身的性能下手。
下面这个图表示Tomcat的工作原理，该图的说明如下。

LimitLatch是连接控制器，它负责控制Tomcat能够同时处理的最大连接数，在NIO/NIO2的模式中，默认是10000，如果是APR/native，默认是8192
Acceptor是一个独立的线程，在run方法中，在while循环中调用socket.accept方法中接收客户端的连接请求，一旦有新的请求过来，accept会返回一个Channel对象，接着把这个Channel对象交给Poller去处理。Poller 的本质是一个 Selector，它同样也实现了线程，Poller 在内部维护一个 Channel 数组，它在一个死循环里不断检测 Channel 的数据就绪状态，一旦有 Channel 可读，就生成一个 SocketProcessor 任务对象扔给 Executor 去处理
SocketProcessor 实现了 Runnable 接口，当线程池在执行SocketProcessor这个任务时，会通过Http11Processor去处理当前这个请求，Http11Processor 读取 Channel 的数据来生成 ServletRequest 对象。
Executor 就是线程池，负责运行 SocketProcessor 任务类，SocketProcessor 的 run 方法会调用 Http11Processor 来读取和解析请求数据。我们知道，Http11Processor 是应用层协议的封装，它会调用容器获得响应，再把响应通过 Channel 写出。

文章插图

从这个图中可以得出，限制Tomcat请求数量的因素四个方面。
当前服务器系统资源我想可能大家遇到过类似“Socket/File：Can't open so many files”的异常，这个就是表示linux系统中的文件句柄限制。
在Linux中，每一个TCP连接会占用一个文件描述符（fd），一旦文件描述符超过Linux系统当前的限制，就会提示这个错误。